Скорее всего, бакапы хранились на том же самом "битом" сервере, и даже не на отдельном диске. Тогда, конечно, они могут оказаться невосстановимыми, хотя лично я с таким не сталкивался; видимо, серьёзный сбой диска случился.

Вообще замечено, что при авариях в Windows сильнее страдает диск C:, в Linux - корневая файловая система. Получается, дефолты в Cache for Windows способствуют самому небезопасному выбору :(

DAiMor,

Крахи RAID5, насколько знаю, самые тяжёлые. Это ведь был не "штатный крах", типа выхода из строя одного диска из массива, а сбой контроллера? Можно предположить, что какое-то время контроллер уже работал со сбоями (и портил бакапы), а никто ничего не замечал - до полного краха.

Где-то попадалась рекомендация, что бакапы надо восстанавливать на регулярной основе на отдельном сервере, а не только когда всё сломалось. API у DBREST имеется... надо бы такое реализовать.

Это Летограф, если не ошибаюсь?

У нас пока объёмы исчисляются десятками GB, но не за горами сотни.

Есть мнение, и оно согласуется с Backup Strategies
что для больших БД, которые бакапятся больше часа, имеет смысл подумать об интеграции системы корпоративного бакапа с одной из стратегий, либо "External Backup", либо "Legacy Concurrent External Backup".

Лет 7 назад приступал к интеграции CA ARCserve Backup с "Legacy Concurrent External Backup" (тогда он ещё не был legacy, и альтернативы ему не было). К сожалению, весь тот проект был свёрнут из-за отсутствия финансирования. Подробностей уже не помню; порадовала очень качественная поддержка InterSystems.

External Backup я тоже пробовал, правда, в других целях: как способ быстро вытащить CACHE.DAT из экземпляра Cache, не выгоняя пользователей. Использовал я его в сочетании с командой cp в Linux'е. Всё бы нечего, и 10-минутного интервала заморозки (значение по умолчанию, которое легко изменить) с лихвой хватало на копирование 10GB баз, но... иногда Cache вдруг впадала в панику, мол, чего это демон записи не подает признаков жизни, хотя он был явно заморожен мною.

Вот я и перестал использовать этот скрипт, перейдя к более консервативному сценарию с размонтированием БД перед копированием. Операция эта у нас довольно редкая и некритичная, в боевых условиях не применяется, поэтому с саппортом бодаться не стал.

Cache for UNIX (Red Hat Enterprise Linux 5 for x86-64) 2010.1.4 (Build 803) Mon Aug 23 2010 20:40:14 EDT