gitlab, СУБД, LVM snapshots

[metaclass]

Сегодня я узнал, что делать LVM snapshots (и прочие аналогичные действия на уровне "момент в жизни файловой системы") - валидный способ бэкапа PostgreSQL баз.

Вопрос - а как это согласуется с порядком записи/вызовов сисколлов/ordering файловой системы?
Т.е. можем ли мы быть уверены, то снапшот блочного девайса - гарантированно валиден с точки зрения FS и с точки зрения сидящей выше уровнем БД и кэшей уровня БД и уровня FS?

Потому как, например в случае Firebird - вроде это должно быть валидно, т.к. по словам разработчиков он использует careful writes - режим записи который не нарушает корректности БД, но точной уверенности у меня в этом нет, особенно с учетом написанного тут: https://danluu.com/file-consistency/
Кроме того, повреждения FB в случае аварийного пропадания питания у меня наблюдаются не так уж редко (раз в 3-6 месяцев на ~100 инстансов БД, эксплуатируемых в адских условиях). На каком уровне творится фигня - fb, файловая система или диск - неизвестно, но целостность файла БД нарушается.

Comments

[berezovsky]

Сохранностью снапшота ведает Божий Промысел, а повреждения управляются Божьей Волей.

[kranov]

в общем случае lvm snapshot ничем не отличается от диска после внезапной перезагрузки, но кажись lvm понимает про некоторые файловые системы, по крайней мере бит clean умеет ставить для монтирования снепшота.

Я lvm-м долгое время бекапил/клонировал kvm виртуалки (на ходу)(сотни, винда, линукс, оракл, Cache), никогда проблем не было, изредка fsck, причем в этом случае lvm не видит фс и ничего не знает что там внутри целый мир со своими кешами и уж точно винде не может просигналить.

Админил сотню ораклов установленном на всяком говне (обычных нонейм десктопах (с виндой)), там внезапная перезагрузка была штатной ситуацией, но оракл умеет редо-логи (wal) писать сразу в несколько файлов (я писал на разные диски), раз в пол-года оракл отказывался стартовать потому что копии неодинаковые, решалось простым копированием файлов с одного диска на другой, не заработало, копируем в обратную сторону.