From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FUZZY_XPILL autolearn=no autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dumalogiya.ru; s=mail; t=1554211706; bh=SKCgkpoIM5lR0VZCWDGJN1w+1Fs5pc4b4+KeIJmWN24=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=tV+XpysLxHlA0RnzMUoZ+MvHMdaG3H+9Ndl/xkwvokRmUYNss1ZmXBJYpudLVEjxa BuMaclUOKTaHgomBORXBTkfqg/GTFoHyq14NlpEcLxGCX/hXA3Q5yw76dmuHCh6Ocg rOsGiZmKVIm9Lke9f86fJW7MI8QNffzeu8PxfcwU= Authentication-Results: mxback5g.mail.yandex.net; dkim=pass header.i=@dumalogiya.ru To: sisyphus@lists.altlinux.org References: <2338589.lmlsSKpopj@gleb.lls.net.iao.ru> <19935751.4vEsHkLYpc@gleb.lls.net.iao.ru> <2601952.Y30KtdlkS9@gleb.lls.net.iao.ru> From: =?UTF-8?B?0JzQuNGF0LDQuNC7INCd0L7QstC+0YHQtdC70L7Qsg==?= Message-ID: <64c506d7-62a1-8959-19ef-4ac532310c07@dumalogiya.ru> Date: Tue, 2 Apr 2019 16:28:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <2601952.Y30KtdlkS9@gleb.lls.net.iao.ru> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru-RU Subject: Re: [sisyphus] 4.19.32-std-def-alt1 X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 13:28:28 -0000 Archived-At: List-Archive: List-Post: Большое спасибо. Очень интересное решение. git весьма громоздкое решение, вас спасает небольшой размер файлов, а так можно rsync + снапшоты btrfs, как вариант. 01.04.2019 12:42, Gleb Kulikov пишет: > В письме от 2019 марта 31 20:27:27 пользователь Михаил Новоселов написал: >> 31.03.2019 15:02, Gleb Kulikov пишет: >>> overlayfs не держит нагрузку и имеет проблемы с EA/ACL. >>> >>> у меня там объединение томов с разных физических устройств с >>> распределением >>> файлов/слепков файлов на предмет отказоустойчивости и моментального >>> восстановления в случае нечисти по типу "шифровальщиков". Объединённый >>> ресурс отдаётся в самбу и нфс. >> Было бы очень интересно почитать, как такое сделано. > Очень просто: по идиотски, из г... костылей и жвачки. Просто нужно было быстро > решить проблему, как-раз несколько раз подряд (несмотря на драконовские меры) > попали под "шифровальщиков". > Тем не менее, решение уже показало себя весьма эффективным и буквально спасло. > Дополнительно продумывались меры по повышению надёжности, так как если не по- > бедности, то по э.. понятным соображениям, организовать правильно > организованный бэкап сложно: инкрементальный бэкап периодически (сильно реже > разумного) сливается на отдельный, не включенный постоянно, диск и (ещё реже), > делается копия на блюрэй. > > Общая идея: архив разбивается на две (или больше) частей. 1-ая всегда > монтируется r/o и содержит холодные и редко изменяемые данные. Эта часть лежит > на одной группе томов (рейд сконфигурирован так, что несколько групп томов > лежат на своих физических дисках) и с неё достаточно редко делается резервная > копия на блюрэй. > > Для изменяемых данных выделен том, который лежит на другой группе томов > (читай, другом физическом диске и в ещё одном случае, на другой ноде). Для > хранения состояния файлов, сделано весьма идиотское решение, но опять-таки, > практика показала его полезность. Раз в 30 минут ресурс попросту сканируется и > если есть изменения, комитится в гит. База гита лежит перекрёстно, на другом > томе (=> другом физическом устройстве). В основном, люди работают с доковскими > и автокадовскими файлами, но как оказалось, несмотря на очевидную > неатомарность, файлы в гите не бьются. За счёт сжатия, база гита пухнет > умеренно. > Раз в три месяца, изменяемые части ресурса сканируются на предмет не > изменявшихся за это время файлов и таковые переносятся в r/o хранилище. База > гита архивируется и отправляется на хранение. > > За счёт того, что изменяемая часть ресурса относительно маленькая, всё > работает весьма шустро и не жрёт ресурсы. > > Изменяемые и холодные файлы "слиты" в один ресурс через aufs. А поскольку факт > "стирания"/изменения файла в r/o хранилище aufs имитирует созданием спецфайла > / копии изменяемого файла, работа с таким комбинированным хранилищем > прозрачна. В то же время, при работе "шифровальщика" или (не)преднамеренном > удалении, страдает весьма незначительная часть хранилища, инцидент легко > разобрать руками и файлы восстанавливаются моментально. Перекрёстное хранение > на разных физических устройствах r/o, r/w и слепков истории изменений файлов, > делает сон значительно спокойнее: потерять вразу ВСЁ можно, но значительно > менее вероятно, чем при задействовании механизмов перераспределения LVM / > снапшотов btrfs. С последними тоже экспериментирую, но более осторожно. > > Вот как-то так. > Ну и неоднократно приходилось доставать копии файлов с совсем небольшим > временным лагом и/или сравнивать с "историческими". В обычной схеме со сжатым > бэкапом можно было-бы рехнуться. > > PS: грабли, на которые можно наступить: если нужно поменять ACL/права доступа, > это нельзя делать на объединённом ресурсе: aufs тупо скопирует на r/w раздел > файлы из всех слоёв. Но если последовательно применить setacl ко всем слоям, > изменения подхватятся и будут нормально работать. > > PPS: overlayfs в такой схеме работает скверно. > > PPPS: права (любые) в гите не сохраняются. В данном случае это геморрой, но > схема всё равно оказывается спасительной. > -- ------ С уважением, Михаил Новоселов | mikhailnov@dumalogiya.ru | https://nixtux.ru