Практическое руководство · восстановление

Резервные копии сайта: как проверить восстановление

Инструкция по составу резервных копий, целям RPO/RTO, защищённому хранению и тестовому восстановлению сайта.

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

Практический план действий

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

Скачать план восстановления

1. Определите, что требуется сохранить

База данных — лишь один из компонентов цифрового сервиса.

Составьте список баз данных, загруженных файлов, каталогов медиа, конфигураций веб-сервера, DNS, сертификатов и настроек приложения.
Отдельно проверьте источник кода, версии CMS/плагинов, переменные окружения и интеграционные настройки; секреты должны храниться безопасно.
Назначьте ответственного за каждый компонент и отметьте зависимости между хранилищами, почтой, очередями и внешними API.
Определите важность компонентов для бизнеса: без чего невозможны вход, оформление заявки, работа сотрудников и обработка заказов.

2. Согласуйте допустимые потери и простой

RPO и RTO — бизнес-цели, а не обещания самого резервного сервиса.

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

3. Защитите хранилище копий

Копии не должны удаляться вместе с заражённым сервером.

Храните одну или несколько независимых копий в отдельном контуре и проверяйте, кто может читать, изменять и удалять их.
Используйте защищённый доступ, шифрование и отдельные права администрирования; для критичных данных рассмотрите неизменяемое или офлайн-хранилище.
Настройте контроль выполнения задач и уведомления об ошибках, но не считайте зелёный статус задания доказательством восстановления.
Определите сроки хранения и правила очистки с учётом объёма, риска, договорных условий и требований к персональным данным.

4. Проведите пробное восстановление

Тест на выделенном стенде показывает, какие файлы и инструкции действительно отсутствуют.

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

5. Подготовьте действия при инциденте

При взломе важно не восстановить сервис поверх действующей компрометации.

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

6. Закрепите результаты и ответственность

Надёжность процесса измеряется подтверждённым восстановлением.

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

Первоисточники:

Редакционный материал, октябрь 2026 года. Конкретные параметры и применимость рекомендаций определяются риском, договором и требованиями к вашей системе.