[sisyphus] 4.19.32-std-def-alt1

[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: права (любые) в гите не сохраняются. В данном случае это геморрой, но 
схема всё равно оказывается спасительной.

-- 

С уважением, /GL