Как проверить, что бэкап сервера действительно восстановится

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

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

Пять вопросов, которые стоит задать прямо сейчас

1. Где лежит копия?

Если копии хранятся у того же провайдера и в том же аккаунте, что и сервер, они могут пропасть вместе с ним: при сбое в дата-центре, блокировке аккаунта, ошибке или атаке на провайдера. Нужна хотя бы одна копия у независимого провайдера — это правило 3-2-1: три копии данных, на двух разных носителях, одна — вне основной площадки.

2. Когда была последняя удачная копия?

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

3. Что в ней?

Для работающего сайта мало файлов из папки сайта. Проверьте, что в копии есть:

• файлы сайта и загруженные пользователями файлы;
• дамп базы данных, а не только её файлы, скопированные «на ходу», — такие файлы часто оказываются несогласованными;
• настройки веб-сервера, PHP и планировщика задач (cron);
• файлы с настройками приложения и ключами, например .env или wp-config.php;
• почта, если она живёт на этом же сервере.

4. Кто знает, как восстанавливать?

Если порядок восстановления держит в голове один человек, это риск. Нужна записанная инструкция: где копии, чем их открыть, где ключ шифрования, в каком порядке поднимать сервисы.

5. Сколько займёт восстановление?

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

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

1. Возьмите отдельный сервер. Никогда не восстанавливайте на рабочий. Временный VPS с почасовой оплатой обойдётся недорого, после проверки его можно удалить.
2. Восстановите всё только из копии. Ничего не берите с рабочего сервера — иначе проверка теряет смысл.
3. Откройте сайт на тестовом сервере. Пропишите его адрес в файле hosts на своём компьютере или используйте временный домен. Пройдите ключевые сценарии: главная страница, вход в админку, карточка товара, оформление заказа без оплаты.
4. Проверьте свежесть данных. Найдите в базе последние заказы или записи и сравните с тем, когда была сделана копия.
5. Засеките время и запишите шаги. От начала до работающего сайта. Записанные шаги — это и есть ваша инструкция по восстановлению.
6. Удалите тестовый сервер. В копии есть данные ваших клиентов, поэтому тестовый сервер должен быть закрыт от посторонних, а после проверки — удалён.

Несколько команд

Если копии делаются с помощью restic, проверить и восстановить их можно так:

# список копий: дата, сервер, что копировали
restic snapshots

# проверка целостности хранилища (с --read-data — с чтением всех данных, это дольше)
restic check

# восстановление последней копии в отдельную папку
restic restore latest --target /srv/restore-test

Дамп базы восстанавливается в отдельную, пустую базу — не в рабочую:

# MySQL или MariaDB
mysql -e "CREATE DATABASE restore_test"
mysql restore_test < dump.sql

# PostgreSQL (дамп в формате custom, сделанный pg_dump -Fc)
createdb restore_test
pg_restore -d restore_test dump.dump

Что чаще всего находится при проверке

• Копируются файлы, но не база — или наоборот.
• Дамп базы пустой из-за ошибки доступа, а скрипт бэкапа об этом не сообщает.
• Копии лежат на том же диске или у того же провайдера, что и сервер.
• Копии хранятся три дня, а проблему заметили через неделю.
• Пароль от зашифрованных копий никто не знает или он хранится только на самом сервере.
• Восстановление занимает полдня, потому что половину настроек приходится вспоминать заново.

Как часто проверять

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