Re: [sisyphus] 4.19.32-std-def-alt1

["Михаил Новоселов" <mikhailnov@dumalogiya.ru>]

Большое спасибо. Очень интересное решение. 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