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

Редакция Romanov Lab · Обновлено 13 октября 2026

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

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

Согласуйте допустимый простой и потерю данных

RPO показывает максимально допустимую потерю последних изменений, выраженную во времени. RTO задаёт максимально допустимый срок восстановления сервиса после остановки. AWS рекомендует определять эти цели с учётом влияния на бизнес и зависимостей системы. Для сайта-визитки и магазина с постоянно поступающими заказами требования могут различаться.

Условный пример: копия сделана до поступления новых заказов. После её восстановления страницы открываются, но этих заказов в базе нет. Частота копирования влияет на возможный разрыв, а фактическая полнота восстановления зависит ещё и от доступных журналов, состояния внешних систем и процедуры сверки. Обещать отсутствие потерь только на основании расписания резервирования нельзя.

Учебный расчёт: что потеряется между двумя копиями

Предположим, резервная копия базы создана в 02:00, а условная авария объявлена в 11:30. Если других пригодных данных нет, восстановление этой копии оставит разрыв в девять с половиной часов. Это не обязательно время потери всех заказов: часть сведений может находиться в CRM или у платёжного провайдера. Но наличие фрагментов в разных системах ещё не означает, что сайт можно автоматически вернуть в согласованное состояние.

Для упражнения возьмите несколько искусственных операций после 02:00: новое обращение, изменение адреса доставки, отмену заказа и уведомление об оплате. Проверьте, где каждая операция оставляет след. Затем ответьте, можно ли восстановить её смысл, последовательность и связь с записью сайта. Письмо «заказ оплачен» без надёжного идентификатора не заменяет полноценную запись заказа. Если данные удаётся только частично сверить вручную, именно это и указывают в результате.

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

Соберите комплект для восстановления

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

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

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

Изолируйте учебную площадку до первого запуска

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

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

Измеряйте весь путь, а не распаковку архива

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

Инструкцию полезно дать специалисту, который не собирал текущий сайт. Любой шаг, требующий устной подсказки, записывают как пробел документации. Отдельно отмечают ручные действия, ожидание провайдера и ошибки прав доступа. Итоговое измерение должно объяснять, где потрачено время и какие этапы ещё нельзя выполнить независимо.

Проверьте данные и пользовательские сценарии

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

1. Откройте несколько типов страниц, изображения и загруженные документы.
2. Проверьте вход, роли пользователей и доступ к закрытым разделам.
3. Создайте тестовую заявку и найдите её в базе или административной панели.
4. Для магазина проверьте состав корзины, расчёт стоимости и смену статуса тестового заказа.
5. Проверьте фоновые задания и обработку тестового ответа интеграции.
6. Сопоставьте контрольные записи и файловые вложения с исходной описью.

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

Проверяйте согласованность, а не только количество записей

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

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

Тестовый платёж проводят только в предусмотренной провайдером тестовой среде. Если безопасного способа нет, эту часть помечают непроверенной и согласуют отдельный сценарий. Отметка «не проверено» ценнее фиктивного зелёного статуса: она показывает оставшийся риск.

Отдельно отработайте сверку заказов

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

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

Шаблон протокола восстановления

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

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

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

Оформите результат и следующий шаг

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