Backup без проверки restore - не backup

Коротко

Backup нужен не для красивого отчёта и не для зелёной галочки в панели. Его задача - вернуть систему к работе после сбоя, ошибки, удаления данных или атаки.

Пока восстановление не проверено руками, backup остаётся предположением. Архив может создаваться каждый день, задача в cron может завершаться без ошибок, мониторинг может показывать зелёный статус. Но в момент аварии выясняется главное: можно ли из этих копий действительно поднять рабочую систему.

Поэтому я смотрю на backup не как на файл с копией, а как на процесс: что копируется, где хранится, как проверяется, кто знает порядок восстановления и сколько времени займёт возврат к работе.

Исходная проблема

Типовая ситуация выглядит спокойно до первого серьёзного сбоя.

На сервере настроена задача резервного копирования. Архивы создаются. Иногда они даже отправляются на отдельный диск или в облачное хранилище. В панели всё зелёное, ошибок нет.

Но если задать несколько простых вопросов, картина часто становится менее уверенной:

• что именно попадает в backup;
• есть ли там база данных, конфиги, compose-файлы, ключи, cron-задачи и инструкции;
• где лежат копии и переживут ли они потерю основного сервера;
• кто и когда проверял восстановление;
• сколько времени займёт возврат сервиса к работе;
• записан ли порядок восстановления или всё держится в голове одного человека.

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

Почему это важно

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

Если backup есть, но restore не проверялся, риски остаются:

• архив может быть битым;
• база может копироваться в неконсистентном состоянии;
• в backup могут не попадать важные конфиги;
• копии могут храниться на том же сервере, который сломался;
• инструкция восстановления может быть устаревшей;
• время восстановления может оказаться не 15 минут, а несколько часов или дней.

Отдельная неприятность - ложное чувство безопасности. Команда считает, что резервное копирование есть, поэтому всё под контролем. А при аварии оказывается, что копия была, но восстановить из неё сервис быстро нельзя.

Что нужно получить

Хороший backup-процесс должен отвечать хотя бы на пять вопросов.

1. Что именно копируется?
2. Где лежат копии?
3. Как часто они создаются?
4. Когда последний раз проверялось восстановление?
5. Сколько времени займёт возврат к работе?

Если на эти вопросы нет понятных ответов, backup стоит считать не проверенной защитой, а заготовкой, которую нужно довести до рабочего состояния.

Практическое решение

1. Проверить, что именно попадает в backup

Первый шаг - не смотреть на размер архива, а понять его состав.

Для сайта или сервиса часто нужны не только файлы приложения. В резервную копию могут входить:

• база данных;
• загруженные пользователями файлы;
• конфигурации web-сервера;
• docker-compose.yml или другие файлы запуска;
• переменные окружения без раскрытия секретов в публичной документации;
• cron-задачи;
• systemd unit-файлы;
• инструкции восстановления;
• важные версии сервисов и зависимостей.

Частая ошибка - копировать только каталог сайта или только базу. Пока сервер жив, это незаметно. После сбоя приходится вручную вспоминать, как всё было собрано.

Минимальный принцип: backup должен помогать восстановить сервис, а не просто сохранить один кусок данных.

2. Проверить место хранения копий

Копия, которая лежит только на основном сервере, защищает не от всех сценариев.

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

Практический минимум:

• хранить копии отдельно от основного сервера;
• иметь несколько точек восстановления;
• ограничить доступ к хранилищу backup;
• проверять, что копии действительно доезжают до внешнего места;
• понимать, как быстро их можно забрать обратно.

Для маленькой инфраструктуры это не обязательно должна быть сложная enterprise-схема. Но должно быть понятно, что один сбой не уничтожит и данные, и резервные копии одновременно.

3. Проверить восстановление руками

Главная проверка backup - не создание архива, а восстановление.

Минимальный тест можно делать на отдельной машине, временной VM, тестовом каталоге или изолированном окружении. Смысл простой: взять копию и пройти путь восстановления без влияния на production.

Проверить нужно не только то, что архив распаковался. Важно убедиться, что:

• база открывается;
• сервис стартует;
• конфиги на месте;
• права доступа не сломаны;
• данные не повреждены;
• инструкция восстановления понятна не только автору backup-скрипта;
• после восстановления можно выполнить базовую проверку приложения.

Если restore ни разу не проверялся, нельзя уверенно говорить, что backup работает.

4. Зафиксировать RPO и RTO простым языком

В backup часто всплывают два важных вопроса.

Первый - сколько данных можно потерять. Например, если копия делается раз в сутки, при аварии можно потерять изменения за последние часы. Это вопрос RPO.

Второй - сколько времени займёт восстановление. Можно иметь свежую копию, но возвращать сервис к работе полдня, потому что нет инструкции, не хватает конфигов или непонятно, в каком порядке запускать компоненты. Это вопрос RTO.

Для малого бизнеса не всегда нужны сложные термины. Достаточно честно ответить:

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

Эти ответы важнее красивой схемы backup, которую никто не проверял.

5. Завести минимальный restore-runbook

Restore-runbook - это короткая инструкция восстановления. Она не обязана быть огромной. Но она должна быть достаточно понятной, чтобы в аварийной ситуации не собирать процесс по памяти.

Минимальный состав:

1. Где лежат резервные копии.
2. Как выбрать нужную точку восстановления.
3. Как получить доступ к копии.
4. В каком порядке восстанавливать базу, файлы и конфиги.
5. Какие команды или действия выполнить.
6. Как проверить, что сервис работает.
7. Кого уведомить о результате.
8. Где записать время восстановления и найденные проблемы.

После каждой тестовой проверки runbook стоит обновлять. Если инструкция не обновляется, она быстро превращается в документ, который вроде есть, но в аварии не помогает.

6. Записывать результат проверки

Проверка restore должна оставлять след.

Минимально стоит фиксировать:

• дату проверки;
• какую копию восстанавливали;
• где проверяли;
• сколько заняло восстановление;
• что сработало;
• что не сработало;
• какие действия нужно исправить.

Так backup перестаёт быть абстрактной надеждой. Появляется история проверок и понятный список улучшений.

Ограничения и риски

Универсального backup-рецепта нет. Разные системы требуют разного подхода.

Для одного сайта достаточно файлов, базы и конфигов. Для другой системы важны очереди, объектное хранилище, внешние интеграции, секреты, сертификаты, версии сервисов и порядок запуска.

Ещё один риск - слишком подробная публичная инструкция. В статье можно объяснить подход, но конкретные схемы хранения, доступы, внутренние пути, имена серверов и регламенты лучше разбирать внутри конкретной инфраструктуры.

Поэтому хороший первый шаг - не переписать backup с нуля, а провести короткую проверку текущего состояния:

• что уже копируется;
• чего не хватает;
• где лежат копии;
• как давно проверялся restore;
• сколько реально займёт восстановление.

Главный вывод

Backup нужно оценивать не по факту создания копии, а по способности восстановить работу.

Если восстановление не проверялось, backup остаётся предположением. Возможно, он сработает. Возможно, нет. Но узнавать это в день аварии - плохой план.

Минимально полезная проверка проста: взять свежую копию, восстановить её в безопасном месте, запустить сервис, сверить данные и записать результат. После этого разговор о backup становится предметным.

Что проверить дальше

Если резервное копирование уже настроено, но restore давно не проверялся, разумно начать не с полной переделки схемы, а с короткой проверки текущего состояния.

Минимально стоит понять четыре вещи: что копируется, где хранится, как восстанавливается и сколько времени займёт возврат к работе. Часто такая проверка показывает больше, чем кажется.