DRP (Disaster Recovery Plan) — структурированный план действий организации при катастрофическом сбое IT-инфраструктуры: отказ дата-центра, хакерская атака, природная катастрофа, человеческая ошибка. Документ устанавливает, кто, что и в каком порядке делает для восстановления систем и данных.
Ключевые метрики DRP
DRP строится вокруг двух показателей:
- RTO (Recovery Time Objective) — целевое время восстановления: сколько часов/минут система может простаивать. Для банковских транзакций RTO = 15 минут; для корпоративного сайта — 4–8 часов.
- RPO (Recovery Point Objective) — допустимая потеря данных во времени: данные за какой период можно потерять без критических последствий. RPO 1 час означает, что бэкапы должны создаваться каждый час.
Структура DRP
- Инвентаризация — список критических систем, их зависимостей и приоритетов восстановления
- Сценарии катастроф — перечень возможных инцидентов: пожар в ДЦ, ransomware, DDoS, отказ БД
- Процедуры восстановления — пошаговые инструкции для каждого сценария
- Роли и контакты — ответственные, эскалация, внешние подрядчики
- Расписание тестирования — DR-тест минимум раз в год
Уровни DR-стратегий
| Стратегия | RTO | Стоимость | Описание |
|---|---|---|---|
| Cold Standby | Часы–сутки | Минимальная | Бэкапы в облаке, новые серверы поднимаются с нуля |
| Warm Standby | 15 мин–2 ч | Средняя | Резервные серверы в режиме standby с актуальными данными |
| Hot Standby (Active-Passive) | Минуты | Высокая | Реплика готова к работе, переключение через DNS/балансировщик |
| Active-Active | Секунды | Максимальная | Обе площадки активны, нагрузка распределена |
История
Планирование восстановления после катастроф появилось в финансовом секторе США в 1970-х — банки были обязаны иметь процедуры на случай отказа вычислительных систем. Стандарт BS 7799 (1995, впоследствии ISO 27001) формализовал требования к BCP/DRP. Ураган Катрина (2005) и теракты 9/11 (2001) показали реальную стоимость неготовности к катастрофам: тысячи компаний потеряли данные безвозвратно.
DRP для хостинга
Для серверной инфраструктуры минимальный DRP включает: ежедневные бэкапы в стороннее облако по правилу 3-2-1, задокументированную процедуру разворачивания инфраструктуры через Ansible или Terraform (Infrastructure as Code), снапшоты перед каждым значимым изменением, проверку восстановления из бэкапа ежеквартально. Не протестированный DR-план — не план, а иллюзия безопасности.
Ключевые метрики DRP: RTO и RPO
RTO (Recovery Time Objective) — максимально допустимое время восстановления: сколько часов/минут система может быть недоступна. RPO (Recovery Point Objective) — допустимая потеря данных: за какой период допустима потеря транзакций. Интернет-магазин с RPO=1 час означает, что можно потерять максимум 1 час заказов. Для банковского приложения RPO=0 — нулевая допустимая потеря данных.
Зависимость между RTO/RPO и стоимостью: уменьшение RTO с 24 часов до 1 часа может увеличить затраты на DR-инфраструктуру в 5-10 раз. Горячий резерв (hot standby) с RTO=5 минут требует работающего дублирующего сервера. Холодный резерв (cold standby) с RTO=24 часа требует только резервной копии и возможности поднять сервер.
Структура DRP-документа
- Инвентаризация систем — перечень критичных компонентов с приоритетами восстановления.
- Матрица зависимостей — какие системы от каких зависят и в каком порядке восстанавливать.
- Процедуры восстановления — пошаговые инструкции для каждой системы (не общие слова, а конкретные команды).
- Контакты — список ответственных с мобильными телефонами и альтернативными каналами связи.
- Расписание тестирования — минимум раз в год проводится учебное восстановление (tabletop exercise или реальный failover-тест).
Связь с хостингом
Для сайтов на хостинге DRP включает: документацию всех DNS-записей, учётных данных панели управления и базы данных, актуальные резервные копии в независимом хранилище, процедуру восстановления у резервного хостера. Критичный элемент — время получения SSL-сертификата и распространения DNS: при смене хостера это занимает 24-72 часа, если не настроен заранее TTL 300 секунд на A-записи.