Бэкап VPS: раз в квартал проверять restore, а не «бэкап есть»

«Бэкап настроен» в чеклисте хостинга часто значит: cron копирует файлы на другой диск, snapshot провайдера включён, плагин шлёт архив в S3. Вопрос «вы когда-нибудь из этого поднимали сайт с нуля?» обычно встречает паузу. Restore drill — это не парanoia: это один контролируемый прогон восстановления, который показывает дыры до того, как их покажет реальный сбой.

Ниже — зачем drill нужен даже на одном VPS, что проверять, и чеклист на полдня без драмы.

к содержанию ↑

Почему «бэкап есть» ≠ «восстановимся»

Иллюзия	Реальность после drill
Архив растёт каждую ночь	Внутри нет wp-config.php, .env, или БД битая
Snapshot «вчерашний»	В snapshot не попали тома Docker / отдельный диск с uploads
S3 bucket полный	Ключ шифрования потерян; restore на другой регион не пробовали
«Плагин сам всё делает»	Восстановление только через их UI на чистом WP, а у вас custom stack
RTO «пара часов»	Первый restore занял 6 часов из-за DNS, mail и cron

Связка с WP-Cron на system cron: после restore cron и очереди плагинов часто ведут себя иначе, чем «живой» прод.

к содержанию ↑

Что такое restore drill

Restore drill — восстановление копии продакшена на изолированное окружение (staging VPS, локальная VM, отдельный контейнер) по тем же процедурам, что используете при аварии.

Цели:

1. Убедиться, что архив читается и версия совместима.
2. Замерить RTO (сколько часов до рабочего сайта) и RPO (сколько данных потеряете между бэкапами).
3. Найти ручные шаги, которые живут только в голове («я всегда так делал»).
4. Обновить runbook одним файлом.

Частота: раз в квартал для активного VPS; раз в полгода, если стек стабилен и мало изменений.

к содержанию ↑

Что включить в scope drill

Минимум для типичного VPS с сайтами:

Слой	Что восстановить	Частая ошибка
Файлы	код, uploads, конфиги nginx	забыли .env вне git
БД	dump MySQL/Postgres	charset, пользователи, grants
Секреты	SMTP, API keys, SSL paths	только на проде в vault
Cron	system crontab, wp cron	после restore задачи не бегут
TLS	certbot paths или CDN mode	drill на HTTP, прод на HTTPS
DNS	не переключать прод; staging на hosts	случайно указали prod A-record

Drill не обязан быть zero-downtime на проде. Нужен отдельный хост или snapshot → новый инстанс.

к содержанию ↑

Пошаговый сценарий (полдня)

1. Подготовка (30 мин)

• Выберите дату и окно — не в пятницу вечером перед релизом.
• Зафиксируйте источник бэкапа: последний nightly + один weekly (проверьте оба).
• Заведите таблицу: шаг | время | OK/FAIL | комментарий.
• Предупредите, если drill трогает shared S3 — не удаляйте prod-префиксы.

2. Поднять чистый стенд (45–90 мин)

• Новый VPS / snapshot restore в новый инстанс / docker compose на другом порту.
• Установите тот же major версии: PHP, MySQL, nginx — или документируйте расхождение.
• Не копируйте prod DNS. Staging по IP + /etc/hosts или отдельный subdomain restore-test.example.

3. Restore файлов и БД (60–120 мин)

• Распакуйте архив так же, как при аварии (не «упрощённо через rsync с прода»).
• Импорт БД: проверьте mysql -e "SELECT COUNT(*) FROM wp_posts" или аналог.
• Положите .env / wp-config.php — из бэкапа секретов, не с живого прода (на drill можно sanitized copy).

4. Smoke test (30–60 мин)

• Главная открывается, админка логинится.
• Одна форма / checkout / webhook (sandbox keys).
• Отложенная задача: wp cron event run --due-now или ваш queue worker.
• Письмо через SMTP на тестовый ящик.
• Если Redis/object cache — убедитесь, что не бьёт в prod instance.

5. Зафиксировать результат (15 мин)

• RTO фактический: от «начали restore» до «smoke OK».
• Список blockers (что чинили руками).
• Обновите RESTORE.md в репо или wiki: команды copy-paste.

Типичные находки на первом drill

1. Бэкап БД без routines/events — ломает триггеры.
2. Исключили node_modules из архива, но не vendor — или наоборот.
3. Docker named volumes не в snapshot — только bind mount в бэкапе.
4. Размер uploads — restore упирается в диск; на проде места «вроде хватит».
5. Права файлов — nginx не читает после распаковки от root.
6. Версия mysqldump на restore старее, чем на prod.

3-2-1 без marketing-слайдов

Практичное правило для одного вебмастера:

• 3 копии данных (prod + backup storage + off-site или другой провайдер)
• 2 разных носителя/аккаунта (диск VPS + S3 / другой VPS)
• 1 копия вне основной площадки (другой регион или провайдер)

Плюс один успешный drill в квартал. Без последнего пункта 3-2-1 — теория.

Связь с WordPress (но не только WP)

На WP drill часто упирается в:

• поиск-replace URL в БД (staging domain);
• WP_HOME / WP_SITEURL;
• permalinks flush;
• плагины backup (Updraft, WPvivid) — восстанавливать тем же способом, которым бэкапите в проде.

На Node/Django/static — те же принципы: env, migrations, media volume, reverse proxy.

Статья про Redis object cache напоминает: после restore кэш-слои нужно сбросить, иначе «старый» контент.

к содержанию ↑

Когда drill считается проваленным (и это хорошо)

Drill удался, если вы честно зафиксировали fail:

• архив не распаковался;
• БД импорт упал на 80%;
• smoke test не прошёл без ручного вмешательства.

Провал на staging — дешёвый урок. Провал на prodе в 3 ночи — дорогой.

Минимальный чеклист (распечатать)

• Источник бэкапа и его дата записаны
• Staging изолирован от prod DNS
• Файлы + БД + секреты восстановлены из бэкапа
• Smoke: фронт, админка, форма, cron, mail
• RTO/RPO записаны
• Runbook обновлён
• Следующий drill в календаре (+3 месяца)

Итог

Бэкап без restore — галочка в панели хостинга. Restore drill превращает её в уверенность: вы знаете время восстановления и слабые места. Раз в квартал, на отдельном стенде, с записью шагов — дешевле любого «мы думали, что S3 спасёт».

Как у вас: когда последний раз поднимали сайт из бэкапа целиком, а не «вытаскивали один файл»? Напишите в комментариях — интересен реальный RTO.

Плагин рейтинга создан автором этого блога. Буду очень признателен, если вы сможете его поддержать (ссылка)