Почему резервной копии недостаточно для восстановления сайта
Резервная копия и восстановленный сайт — разные результаты. Копия представляет собой набор файлов или точку данных. Восстановление возвращает работающий сервис: страницы открываются, пользователи входят, заказы сохраняются, фоновые задания выполняются, а внешние системы получают только ожидаемые события. Между этими состояниями находятся инфраструктура, совместимые версии программ, ключи, доступы и последовательность действий. Именно поэтому NIST рассматривает восстановление как часть плана непрерывности с процедурами, ролями и упражнениями, а не как одиночную операцию копирования [1].
Что может отсутствовать в «полном» архиве
Название архива не гарантирует его полноту. Веб-приложение обычно зависит от нескольких слоёв, которые резервируются разными инструментами:
- код и публичные файлы; сюда входят ядро CMS, модули, шаблоны и пользовательские загрузки;
- база данных; её состояние должно соответствовать файлам и моменту создания копии;
- конфигурация среды; версии PHP, расширений, веб-сервера, СУБД и системных библиотек;
- секреты и ключи; переменные окружения, ключи шифрования, доступы к объектному хранилищу и интеграциям;
- служебные процессы; cron, очереди, обработчики почты, воркеры и планировщики;
- внешняя инфраструктура; DNS, TLS-сертификаты, CDN, WAF, файловое хранилище, поиск и сторонние API.
Если часть можно восстановить из репозитория или панели провайдера, это должно быть записано в плане. Фраза «настроим заново» не является процедурой, пока неизвестны источник конфигурации, ответственный и время выполнения.
Почему копия не превращается в работающий сайт
Архив неполный или несогласованный
Копирование каталога во время активной записи не гарантирует согласованное состояние базы и файлов. Пользовательская загрузка могла попасть в архив, а связанная запись в базе — ещё нет, либо наоборот. Для СУБД нужен поддерживаемый механизм дампа или снапшота, а для приложения — понимание, требуется ли временно остановить запись. В документации «1С-Битрикс» полный архив включает публичную часть, ядро и дамп MySQL; для PostgreSQL дамп предлагается создавать внешними средствами [2]. Это хороший пример того, почему способ копирования зависит от фактической платформы.
Все точки находятся в одном контуре
Если рабочий сервер, локальные архивы и панель хостинга доступны одной скомпрометированной учётной записи, атакующий или ошибочный сценарий может удалить всё одновременно. CISA советует хранить критичные копии офлайн, шифровать их и регулярно проверять в сценарии аварийного восстановления [3]. Отдельное хранилище полезно только тогда, когда разделены права и сохранён способ получить ключи после потери основной площадки.
Выбрана неверная точка
Самая свежая копия не всегда самая безопасная. Ошибка, вредоносный код или повреждение данных могли попасть в несколько последних точек до обнаружения проблемы. Поэтому нужна история, журнал изменений и возможность выбрать дату до инцидента. При восстановлении после атаки сначала определяют доверенную точку и чистую целевую среду; иначе вместе с данными можно вернуть причину компрометации.
Среда больше не совместима
Архив может требовать версию PHP, СУБД или модуля, которой нет на новом сервере. Домен может зависеть от старого DNS, а приложение — от закрытого репозитория или лицензии. Сохраняйте паспорт окружения: ОС, версии компонентов, расширения, параметры запуска, список сервисов и способ установки. Для воспроизводимых проектов полезны декларативные конфигурации и сценарий развёртывания, но их также нужно резервировать отдельно от рабочей площадки.
Проверка ограничилась целостностью файла
Хэш, проверка архива или команда верификации базы обнаруживают часть повреждений, но не доказывают работоспособность приложения. Microsoft указывает, что RESTORE VERIFYONLY проверяет полноту и читаемость резервного набора SQL Server, но не структуру данных внутри [4]. Полный ответ даёт только восстановление в отдельную среду с прикладными тестами.
Как построить проверяемый сценарий восстановления
- Определите приоритеты. Составьте список функций, без которых сайт нельзя считать восстановленным: просмотр каталога, авторизация, заказ, оплата в тестовом режиме, обмен или отправка заявки.
- Назначьте точку и владельца. В инструкции должны быть идентификатор копии, место хранения, порядок получения доступа и сотрудник, принимающий решение о восстановлении.
- Подготовьте чистую целевую среду. Не разворачивайте неизвестную копию поверх работающего сайта. Изолируйте исходящую почту, платежи, CRM, 1С и webhook.
- Восстанавливайте слоями. Сначала инфраструктура и сеть, затем база и файлы, после этого секреты, фоновые процессы и внешние зависимости. После каждого этапа фиксируйте результат.
- Проверьте данные. Сверьте контрольные сущности до и после точки: пользователей, заказы, документы, файлы. Оцените фактическую потерю относительно заявленного RPO.
- Проверьте функции. Выполните заранее описанные сценарии и изучите журналы. Простого ответа HTTP 200 недостаточно.
- Замерьте время. Зафиксируйте начало, длительность ручных операций и момент готовности сервиса. Сравните результат с RTO.
- Обновите план. Любая неясная команда, отсутствующий пароль или несовместимая версия превращаются в конкретную задачу с владельцем и сроком.
Облачная автоматизация может регулярно выбирать реальную точку, создавать тестовый ресурс и показывать продолжительность восстановления. Например, AWS Backup описывает restore testing как отдельный периодический процесс, использующий те же recovery points, что и обычное восстановление [5]. Даже при такой автоматизации бизнес-проверка остаётся за владельцем приложения: облако может поднять виртуальную машину, но не знает, правильно ли рассчитывается заказ.
Критерии готовности, которые можно проверить
Процесс готов к аварии, если новый исполнитель по актуальной инструкции может найти копию и ключи, развернуть её в чистой среде, вернуть согласованный набор функций и получить результат в измеримое время. В протоколе должны быть не общие слова, а доказательства: версия точки, хэши или идентификаторы, снимок состава, результаты запросов к базе, скриншоты или логи контрольных операций, фактические RPO и RTO, список исключений.
Отдельно проверьте обратный путь: как переключить трафик на восстановленный контур, как остановить повторную обработку очередей и как вернуться к штатной схеме после устранения причины. План, который заканчивается запуском тестовой копии, не описывает восстановление сервиса целиком.
Что делать, если подходящей копии нет
Сначала сохраните текущее состояние и журналы, чтобы не уничтожить остатки данных и следы причины. Затем разделите задачи: восстановление доступных данных, пересборка приложения из доверенного кода, повторное получение внешних файлов, ручная сверка транзакций. Не обещайте вернуть то, чего нет ни в одной системе. После стабилизации создайте новую доверенную базовую точку и проведите полный тест, прежде чем считать резервирование исправленным.
Источники
[1] NIST — SP 800-34 Rev. 1: Contingency Planning Guide.
[2] 1С-Битрикс — Резервное копирование и восстановление.
[3] CISA — #StopRansomware Guide.
[4] Microsoft Learn — RESTORE VERIFYONLY.
[5] AWS Backup — Restore testing.