Как проверить резервную копию сайта пробным восстановлением

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

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

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

Что должен подтвердить тест

Заранее определите критерии успеха:

  1. архивы читаются и распаковываются;
  2. дамп базы импортируется без пропущенных таблиц и критичных ошибок;
  3. приложение запускается в совместимой версии PHP, СУБД и веб-сервера;
  4. страницы, стили, изображения и загружаемые файлы доступны;
  5. вход в административную часть и ключевой пользовательский сценарий работают;
  6. тестовая копия не отправляет реальные письма, платежи, вебхуки и заявки;
  7. дата данных соответствует ожидаемой точке восстановления.

Наличие файла или сообщение «backup completed» не выявит повреждённый архив, неполный дамп, забытый каталог с загрузками или конфигурацию, которая не входит в копию.

Подготовьте безопасный стенд

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

До запуска приложения отключите внешние действия:

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

Тест формы, заказа или рассылки не должен создавать настоящие операции и сообщения клиентам.

Проверьте состав копии

Составьте список компонентов сайта. Кроме файлов и SQL-дампа могут понадобиться объектное хранилище, конфигурация веб-сервера, задания планировщика, поисковый индекс или отдельные сервисы.

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

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

1. Выберите один комплект копий

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

2. Проверьте архивы

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

3. Разверните совместимое окружение

Зафиксируйте версии PHP, базы, CMS, расширений и системных библиотек. Среда должна поддерживать формат данных и зависимости приложения. Если её невозможно воспроизвести, одной копии недостаточно: нужен ещё актуальный список версий и настроек.

4. Импортируйте данные и файлы

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

5. Проведите smoke-тест

Проверьте главную и важные внутренние страницы, CSS и JavaScript, изображения, вход под тестовой учётной записью и одну ключевую операцию без внешнего эффекта. Для магазина это может быть добавление тестового товара в корзину без оплаты; для кабинета — вход и чтение доступных данных.

Посмотрите журналы приложения и веб-сервера. Страница может вернуть код 200, но одновременно записать ошибки шаблона, фоновой задачи или хранилища.

6. Сверьте свежесть данных

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

7. Измерьте весь путь

Считайте время с момента, когда ответственный получает задачу: поиск инструкции и копии, подготовка среды, импорт, настройка и проверка. Результат покажет, насколько реалистичен план восстановления, но один тест не гарантирует такой же длительности при аварии.

Зафиксируйте результат

Итогом должен стать короткий протокол. Укажите:

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

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

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

Что может проверить мониторинг

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

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

Чеклист перед завершением

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

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

Проверьте свой сайт прямо сейчас

Введите адрес сайта: Web-Puls покажет HTTP-код, время ответа и базовую диагностику. Для постоянного контроля можно подключить мониторинг.

Нужна помощь с диагностикой ошибки?

Опишите симптомы в короткой заявке: URL, код ответа, время появления и что менялось перед сбоем. Специалист поддержки оценит задачу и предложит формат работ.