Учебное восстановление: проверьте копии заранее

Копия, из которой ни разу не восстанавливали, — это не копия, а надежда. Учебное восстановление занимает час раз в квартал и превращает надежду в проверенный факт.

Что проверяется

Три вопроса, на которые нужен ответ до аварии:

1. Полнота. Есть ли в копии всё, что нужно для запуска: данные, настройки, ключи, сертификаты, расписание.
2. Читаемость. Открывается ли архив, разворачивается ли выгрузка базы без ошибок.
3. Время. Сколько часов займёт полное восстановление. Эту цифру нужно знать заранее, а не выяснять под давлением.

Как провести учение

Самый честный вариант — на отдельной машине, а не на боевой. Возьмите VDS-1 на месяц, восстановитесь на неё с нуля и засеките время.

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

Развернуть базу:

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

Поднять приложение и открыть его в браузере — заключительный шаг. Пока страница не открылась, восстановление не состоялось.

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

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

Что обычно вскрывается

• Забыт файл .env. Данные есть, пароли к ним — нет.
• Забыты сертификаты. Сайт поднимается, но по HTTPS не отвечает.
• Забыто расписание. Всё работает, но копии больше не создаются — и это выясняется через месяц.
• Не записана последовательность запуска. Приложение стартует раньше базы и падает.
• Пароль репозитория лежал только на потерянной машине. Копии есть, доступа к ним нет.
• Восстановление занимает не два часа, а десять. Полоса приёмника или полка диска, см. скорость диска.

Запишите порядок

По итогам учения составьте короткую инструкцию и держите её вне машины:

1. Заказать машину той же или большей ступени — выдача около минуты.
2. Поставить Docker и восстановить /opt/myapp из копии.
3. Развернуть выгрузку базы, проверить количество записей.
4. Восстановить /etc/nginx и сертификаты, поднять веб-сервер.
5. Перенаправить домен на новый адрес.
6. Восстановить расписание из crontab.txt.
7. Проверить: сайт открывается, вход работает, копии создаются снова.

Пункт 5 — самый недооценённый. Записи DNS обновляются не мгновенно, и время жизни записи стоит заранее снизить до 300 секунд, если вы вообще допускаете переезд.

Как часто

Раз в квартал для боевых сервисов, раз в полгода для остального. Плюс обязательно — после любого серьёзного изменения: новая база, новый сервис, переезд каталогов. Внесите учение в календарь, иначе оно не случится никогда.

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