Тестове відновлення: перевірте свої бекапи заздалегідь

Резервна копія, з якої ви жодного разу не відновлювалися, — це не резервна копія, а сподівання. Навчальне відновлення займає годину раз на квартал і перетворює сподівання на перевірений факт.

Що перевірити

Три питання, на які потрібні відповіді до інциденту:

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 оновлюються не миттєво, і заздалегідь знизьте TTL запису до 300 секунд, якщо взагалі допускаєте міграцію.

Як часто

Раз на квартал для робочих сервісів, раз на пів року для всього іншого. Плюс завжди після будь-якої серйозної зміни: нова база даних, новий сервіс, переміщення каталогів. Поставте навчання в календар, інакше воно ніколи не відбудеться.

Що має бути в резервній копії — що саме резервувати. Куди її вивозити — резервні копії поза майданчиком. Якщо інцидент уже стався — дані втрачено.