Определите, что включает «сайт»
Начните с инвентаризации сервисов. Для каждого сайта, портала, магазина или кампании зафиксируйте бизнес‑владельца, технического владельца, учётную запись хостинга, контроль домена и DNS, репозиторий, хранилища контента и медиа, интеграции и критические учётные данные. Отметьте, что можно восстановить из системы контроля версий, а что содержит уникальные записи.
Обязательно включите конфигурацию: перенаправления, настройки CDN или файрвола, планируемые задачи, шаблоны и файлы infrastructure-as-code. Не копируйте рабочие секреты в общий реестр; указывайте на утверждённую систему секретов и процесс аварийного доступа. Документация WordPress показывает распространённый пробел: типичный сайт требует и файлов, и отдельной базы данных.
Определите наименьшую безопасную версию, которая может предоставлять основную информацию или выполнять транзакции.
Объединяйте совместимые экспортированные базу данных, файлы, медиа и конфигурацию под одной временной меткой или меткой версии.
Назначьте частоту и хранение исходя из бизнес‑толерантности
Выберите частоту по скорости и ценности изменений. Опишите RPO простым языком, затем убедитесь, что каждая уникальная подсистема захватывается достаточно часто. Ночной копии файлов недостаточно для RPO в четыре часа для быстро меняющейся базы данных.
Установите RTO отдельно. Включите утверждение, чистую инфраструктуру, восстановление, проверку, изменения трафика и внутреннюю коммуникацию. Измеряйте RTO в ходе тренировки, а не полагаясь на утверждения поставщика. Храните старые точки достаточно долго, чтобы успеть до обнаружения ошибки; при необходимости согласуйте период хранения с отделами конфиденциальности, архивирования или юристами.
Сравните интервал между полными точками восстановления с RPO каждой службы.
Убедитесь, что уполномоченное лицо может найти старую утверждённую точку восстановления.
Разделяйте и защищайте копии восстановления
Используйте несколько копий в разных местах или сервисах, чтобы одна учётная запись, локальное событие или ошибка не уничтожили все варианты. CISA рекомендует регулярные автоматизированные бэкапы, офф‑сайт копию, шифрование и офлайн‑копии. NCSC советует избегать постоянно подключённых резервных устройств и рекомендует более одного решения или местоположения для бэкапов.
Защитите администрирование бэкапов принципом наименьших привилегий, многофакторной аутентификацией там, где доступно, отдельными учётными записями администраторов и регулярными проверками доступа. Используйте защиту от удаления, историю версий или неизменяемое хранилище только после понимания их стоимости и модели восстановления. Шифрование важно, но протестируйте хранение ключей — шифрование без доступных ключей бесполезно; широкое совместное использование доступа ослабляет каждую копию.
Копия должна иметь существенно отличающийся от продакшена режим отказа.
Перечислите, кто может читать, изменять, удалять и восстанавливать бэкапы; удалите устаревшие права.
Напишите runbook восстановления и назначьте полномочия
Runbook — это протестированная процедура восстановления. Храните копию, доступную без затронутого сайта, производственной системы удостоверений или обычной чат‑системы. Включите контакты и их резервные каналы, полномочия, приоритет систем, расположение бэкапов, предварительные условия, порядок восстановления, проверки валидации и критерии остановки.
Назначьте ответственного владельца восстановления и его резерв для каждого критического сервиса. Определите, кто утверждает восстановление в продакшен, изменения DNS и проверку бизнес‑данных. При наличии данных платёжных карт, чувствительных персональных данных или регулируемых записей привлеките специалистов по безопасности, конфиденциальности, юриспруденции и, при релевантности, PCI‑аудит до принятия решений о сохранении, уведомлении или восстановлении.
Фиксируйте выбранную точку восстановления, утверждающее лицо, затронутые системы, результат проверки и исключения.
Задокументируйте контролируемый аварийный доступ; не полагайтесь на устройство или память одного сотрудника.
Восстанавливайте безопасно при подозрении на компрометацию
Не перезаписывайте автоматически продакшен самой новой копией, если возможен несанкционированный доступ, вредоносное ПО или подозрительное удаление. Следуйте процессу инцидента, оцените, какие учётные записи и бэкапы могли быть затронуты, выберите точку на основании доказательств и постройте или изолируйте среду восстановления перед её подключением.
CISA рекомендует приоритизировать восстановление критических сервисов и предупреждает о риске перезаражения чистых систем. NCSC советует подключать бэкапы только к заранее проверенным чистым устройствам и сканировать их перед восстановлением. Эти шаги снижают риск, но не гарантируют чистоту. При необходимости подключайте квалифицированную помощь по реагированию на инциденты для расследования, сохранения доказательств или выполнения обязанностей по уведомлению.
Восстановите сервисы с наивысшим приоритетом на чистой инфраструктуре, верифицируйте их, затем продолжайте по порядку зависимостей.
Проверьте пользовательские сценарии, данные, задания, интеграции, администрирование, логирование и покрытие новыми бэкапами.
Используйте тренировки как доказательство и источник улучшений
Проводите частичные восстановления, изолированные полные сборки, упражнения на потерю зависимостей или настольные сценарии в зависимости от риска. Начните с безопасного, но значимого теста и повышайте реализм со временем. CISA рекомендует полные и частичные тесты восстановления; NCSC советует упражнения для прояснения ролей, обязанностей третьих сторон и приоритетов.
Измеряйте возраст точки восстановления относительно RPO и реальное время восстановления относительно RTO. Фиксируйте идентификатор набора, участников, результат валидации, неудачные шаги и владельца исправлений. Повторно тестируйте после закрытия пробелов и после существенных изменений платформы, идентификации, базы данных или провайдера. SIU может организовать эти профилактические работы; это не система бэкапов и не служба мониторинга в реальном времени.
Храните краткий отчёт о том, что восстановлено, где, что прошло, что провалилось и кто принял результат.
Повторяйте целевые тесты после существенных изменений архитектуры или поставщиков.