Резервные копии обладают неприятным свойством: они выглядят исправными ровно до того момента, когда понадобятся. Расписание работает, файлы растут, письма приходят — а при восстановлении выясняется, что дамп базы обрывается на середине, потому что скрипт не дожидался завершения.
Проверяйте восстановление, а не наличие
Единственная проверка, которая что-то доказывает, — это полное восстановление на чистый сервер. Не «файл на месте и весит правдоподобно», а «система поднялась и данные на месте».
Заведите привычку: раз в квартал берите свежий снимок, разворачивайте на отдельной машине и убеждайтесь, что приложение стартует.
Что обычно ломается
- Дамп базы снят без блокировки и содержит несогласованные таблицы.
- Забыли выгрузить то, что лежит вне БД: загруженные файлы, сертификаты, cron.
- Бэкап хранится на том же диске, что и данные. Отказ диска уносит обе копии.
- Права и владельцы файлов не сохранились, приложение не стартует.
Три копии, два носителя, одна вне площадки
Старое правило 3-2-1 остаётся верным. У нас ежесуточные снимки хранятся семь дней и лежат отдельно от рабочего диска — но это только один уровень. Критичные данные стоит выгружать ещё куда-то, где мы не являемся единственной точкой отказа.