Фраза:
«Резервное копирование настроено»
звучит успокаивающе.
Но с инженерной точки зрения она почти ничего не говорит о способности системы пережить реальную аварию.
Потому что:
backup configured ≠ restore works
Разберём, какие утверждения мы действительно можем подтвердить на разных этапах.
Уровень 1. Механизм резервного копирования настроен
Например, на сервере есть:
backup.timer backup.service
или запись в cron:
0 2 * * * /usr/local/bin/backup.sh
Что это доказывает? Только то, что существует конфигурация, которая должна запускать резервное копирование. Мы пока не знаем:
- — запускалась ли задача вообще;
- — завершалась ли она успешно;
- — создаётся ли результат;
- — куда он сохраняется;
- — пригоден ли он для восстановления.
То есть:
backup configured
≠
backup executed
Уровень 2. Backup job успешно выполняется
Допустим, журнал показывает:
Backup started Backup completed successfully
Теперь evidence сильнее.
Мы можем утверждать:
задача резервного копирования запускалась и завершилась без зафиксированной ошибки.
Но даже SUCCESS ещё не доказывает, что созданная копия действительно пригодна.
Скрипт вполне может завершиться с кодом 0, но сохранить не те данные, неполный набор файлов или пустой результат.
Поэтому:
job successful
≠
valid backup
Уровень 3. Backup artifact существует
Например:
/backup/db01/db01-2026-10-06.tar.zst
или на backup storage присутствует актуальный snapshot. Теперь у нас уже есть физический результат операции. Можно проверить:
- — время создания;
- — размер;
- — checksum;
- — структуру архива;
- — наличие ожидаемых данных;
- — соответствие retention policy.
Это существенно лучше, чем просто статус успешно выполненной задачи. Но главный вопрос всё ещё остаётся открытым: сможем ли мы из этого восстановиться?
Уровень 4. Backup прошёл проверку целостности
Например:
sha256sum backup.tar.zst
или:
tar -tf backup.tar.zst
Такая проверка может подтвердить, что artifact доступен и технически читается. Но читаемый архив ещё не означает работающую систему после восстановления. В backup могут отсутствовать:
- — конфигурационные файлы;
- — ключи и сертификаты;
- — secrets;
- — необходимые права и ownership;
- — данные другого компонента;
- — информация о внешних зависимостях.
Поэтому:
artifact readable
≠
system recoverable
Уровень 5. Выполнено реальное восстановление
Вот здесь появляется значительно более сильное evidence. Например, для базы данных недостаточно знать:
dump completed successfully
Гораздо сильнее выглядит цепочка:
restore backup
↓
start database
↓
connect
↓
check critical objects
↓
verify application access
Теперь мы проверяем уже не создание backup, а recoverability. И это принципиально другое утверждение.
Пять разных состояний
Их полезно не смешивать:
Backup configured
↓
Backup job executed
↓
Backup artifact exists
↓
Artifact integrity verified
↓
Restore successfully tested
Каждый следующий уровень подтверждает больше предыдущего. Но ни один из верхних уровней не заменяет нижний.
Почему это важно
Система может годами показывать:
Backup status: SUCCESS
а во время аварии выяснится, что:
- — часть данных никогда не попадала в backup;
- — архив повреждён;
- — отсутствует encryption key;
- — процедура restore устарела;
- — версии ПО несовместимы;
- — никто не знает порядок восстановления компонентов;
- — recovery занимает значительно больше ожидаемого времени.
Формально backup был. Практически восстановление не было подтверждено.
Какой вопрос полезнее
Вместо: «Backup настроен?» лучше спросить: «Когда последний раз из него успешно восстанавливали систему или данные?» Это уже совсем другой уровень проверки.
Главное
backup configured
≠
backup successful
≠
backup valid
≠
restore works