lvm или zfs для частых снапшотов.

Мы перед этим проводили тестирование на очень высокой нагрузке, за 200 снапшотов ни одного сбоя.

А это что было, zfs?

Ну-ну, удачи с таким подходом.

На самом деле, с точки зрения базы возврат к снепшоту равноценен пропаданию питания.

это еще не значит, что данные консистентны и внутри нет мусора вместо важных данных...

Правильно спроектированная база всегда хранит на диске только консистентное состояние, и переходит из одного в другое атомарными обновлениями метаданных записью без буферизации. Если хочет быть ACID, конечно.

Это не про 1С, как мне кажется.

То есть, метод вполне возможен для промежуточных бэкапов, если база спроектирована переживать отключения питания.

На самом деле, с точки зрения базы возврат к снепшоту равноценен пропаданию питания.

Нет, ОС делает сброс буферов на диск перед снапшотом. Проверено, вызывается VSS. Это скорее аналог kill -9

Это не про 1С, как мне кажется.

Вот и у меня такое впечатление сложилось :).

если база спроектирована переживать отключения питания.

Я сам никогда не работал с 1С, но историй про порушенные файловые базы данных по самым разным причинам - от пропадания питания до зависания сервера, слышал предостаточно...

Впрочем, действительно, в худшем случае суточный нормальный бекап у автора темы будет. Так что не все так плохо, как мне показалось вначале...

Нет, ОС делает сброс буферов на диск перед снапшотом.

Нормально спроектированные БД для соответствия ACID подтверждают транзакцию только после гарантированной записи на носитель. Поэтому для такой базы что неожиданное отключение питания, что запуск с «грязного» снепшота — события одного уровня.

Думаете DBF времен win32s это нормальная БД?

Думаете DBF времен win32s это нормальная БД?

Это всего лишь хранилище, которое само по себе ничего не обеспечивает и не гарантирует. Всё зависит от того, как ПО его использует.