DRP

DRP (от англ. Disaster Recovery Plan) — это документированный набор процедур, политик и технических решений, предназначенный для восстановления критически важных информационных систем, данных и бизнес-процессов организации после крупномасштабных сбоев, катастроф или чрезвычайных ситуаций. DRP является составной частью более широкой концепции обеспечения непрерывности бизнеса (Business Continuity Planning, BCP) и сосредоточен именно на восстановлении ИТ-инфраструктуры и данных, в отличие от BCP, который охватывает все аспекты деятельности организации.

История и развитие

Концепция DRP зародилась в 1970-х годах, когда крупные компании начали осознавать зависимость своих операций от централизованных вычислительных систем (мейнфреймов). Первоначально планы восстановления были ориентированы исключительно на физическую защиту серверных помещений и резервное копирование на магнитные ленты.

В 1980-х годах, с распространением персональных компьютеров и локальных сетей, сложность DRP возросла. Появились специализированные компании, предлагающие услуги «горячих» резервных центров (hot sites) — полностью оборудованных площадок, где клиент мог развернуть свои системы в случае катастрофы.

1990-е годы ознаменовались переходом к клиент-серверной архитектуре и интернет-технологиям. DRP стали включать не только восстановление аппаратного обеспечения, но и программного обеспечения, сетевой инфраструктуры и баз данных. Ключевым событием, подтолкнувшим развитие стандартизации, стал теракт 11 сентября 2001 года в США, после которого многие организации пересмотрели подходы к обеспечению непрерывности.

В 2000-2010-х годах с развитием облачных вычислений и виртуализации DRP эволюционировали в сторону Disaster Recovery as a Service (DRaaS) — облачного сервиса аварийного восстановления. Это позволило малому и среднему бизнесу получить доступ к ранее дорогостоящим решениям.

Классификация DRP

Планы восстановления после катастроф классифицируются по нескольким признакам:

По масштабу и целям

• План восстановления ИТ-инфраструктуры — фокусируется на серверах, сетях, системах хранения данных.
• План восстановления данных — описывает процедуры резервного копирования и восстановления информации.
• План восстановления приложений — определяет порядок перезапуска критических бизнес-приложений (ERP, CRM, базы данных).
• План восстановления рабочих мест — касается обеспечения сотрудников доступом к системам с альтернативных устройств.

По типу катастрофы

• Природные катастрофы — землетрясения, наводнения, ураганы, пожары.
• Техногенные катастрофы — отключение электроэнергии, сбои в системах охлаждения, отказы оборудования.
• Кибератаки — атаки программ-вымогателей (ransomware), DDoS-атаки, утечки данных.
• Человеческий фактор — ошибки администраторов, саботаж, случайное удаление данных.

По архитектуре восстановления

• «Холодный» резервный центр (cold site) — помещение с коммуникациями, но без оборудования. Восстановление требует длительного времени (дни-недели).
• «Тёплый» резервный центр (warm site) — помещение с частично настроенным оборудованием и сетевыми подключениями. Восстановление занимает часы-сутки.
• «Горячий» резервный центр (hot site) — полностью дублирующая инфраструктура, синхронизированная с основной. Восстановление происходит в реальном времени или за минуты.
• Облачное восстановление (DRaaS) — инфраструктура предоставляется провайдером облачных услуг, оплата по факту использования.

Ключевые метрики DRP

Эффективность плана оценивается двумя основными показателями:

RTO (Recovery Time Objective)

Максимально допустимое время, в течение которого система или сервис могут быть недоступны после катастрофы. Измеряется в часах или минутах. Например, для интернет-банкинга RTO может составлять 1 час, а для внутренней системы учёта — 24 часа.

RPO (Recovery Point Objective)

Максимально допустимый объём потери данных, измеряемый во времени. Показывает, насколько «свежими» должны быть восстановленные данные. RPO в 15 минут означает, что организация готова потерять данные за последние 15 минут. RPO в 0 минут (zero data loss) требует непрерывной репликации данных.

Структура типового DRP

Документ DRP обычно включает следующие разделы:

1. Цели и область применения

Определение, какие системы и процессы покрываются планом, какие катастрофы рассматриваются, какие метрики (RTO/RPO) установлены.

2. Роли и обязанности

Список членов команды восстановления (Disaster Recovery Team) с указанием контактных данных, заместителей и зон ответственности. Обычно включает:

• Координатора DRP
• Специалистов по сетям, серверам, базам данных
• Представителей бизнес-подразделений
• Связь с внешними подрядчиками

3. Инвентаризация активов

Перечень всех критических ИТ-активов: серверы (физические и виртуальные), сетевые устройства, системы хранения, приложения, лицензии, конфигурации.

4. Процедуры эскалации и оповещения

Порядок действий при обнаружении сбоя: кто и как оповещается, в какой последовательности, какие каналы связи используются (телефон, электронная почта, мессенджеры).

5. Процедуры восстановления

Пошаговые инструкции для каждого сценария катастрофы:

• Порядок запуска резервного центра
• Процесс восстановления данных из резервных копий
• Проверка целостности и работоспособности систем
• Возврат к основной инфраструктуре (failback)

6. Коммуникационный план

Как информировать сотрудников, клиентов, партнёров и регуляторов о сбое и ходе восстановления.

7. Тестирование и обновление

График регулярных тестов DRP (например, раз в квартал или полугодие), порядок внесения изменений после тестов или изменений в инфраструктуре.

Технологии и решения

Современные DRP опираются на несколько ключевых технологий:

• Резервное копирование — создание копий данных на локальных носителях, ленточных библиотеках или в облаке. Используются схемы «дед-отец-сын», инкрементальное и дифференциальное копирование.
• Репликация данных — синхронная или асинхронная передача изменений на удалённый сервер или в облако в реальном времени. Обеспечивает минимальный RPO.
• Виртуализация — позволяет быстро развернуть виртуальные машины на резервном оборудовании или в облаке, используя снимки состояния (snapshots).
• DRaaS — облачные сервисы, автоматизирующие процесс восстановления. Примеры: Veeam, Zerto, Azure Site Recovery, AWS Disaster Recovery.
• Автоматизация оркестрации — инструменты, которые по заданному сценарию автоматически запускают резервные системы, переключают трафик и уведомляют персонал.

Правовые и нормативные требования

В различных отраслях и юрисдикциях существуют обязательные требования к DRP:

• Банковская сфера — в России Центральный банк РФ (Банк России) устанавливает требования к обеспечению непрерывности деятельности и восстановлению информационных систем для кредитных организаций (Положение № 719-П).
• Государственные информационные системы — в РФ действуют требования Федерального закона № 152-ФЗ «О персональных данных» и приказы ФСТЭК России, предписывающие создание резервных копий и планов восстановления.
• Медицина — в США закон HIPAA требует наличия плана восстановления для защиты медицинских данных.
• Промышленность — стандарты ISO 22301 (менеджмент непрерывности бизнеса) и ISO 27031 (информационные технологии — обеспечение готовности к аварийному восстановлению).

Типичные ошибки и критика

Несмотря на очевидную необходимость, многие организации сталкиваются с проблемами при внедрении DRP:

• Отсутствие регулярного тестирования — план, который никогда не тестировался, может оказаться неработоспособным в реальной ситуации. Исследования показывают, что до 40% компаний не проводят тесты DRP чаще раза в год.
• Устаревшая документация — изменения в инфраструктуре (новые серверы, приложения, конфигурации) часто не отражаются в плане, что делает его бесполезным.
• Недооценка человеческого фактора — увольнение ключевого специалиста, знающего процедуры, может парализовать восстановление.
• Игнорирование киберугроз — многие планы ориентированы на физические катастрофы и не учитывают сценарии с атаками программ-вымогателей, которые требуют иных подходов (например, изоляция заражённых систем, восстановление из офлайн-копий).
• Сложность и избыточность — чрезмерно детализированные планы трудно поддерживать и выполнять в стрессовой ситуации.

Примеры из практики

• 2011 год, землетрясение в Японии — многие компании, имевшие резервные центры в зоне бедствия, потеряли и основные, и резервные мощности. Это привело к пересмотру географического распределения резервных площадок.
• 2017 год, атака NotPetya — компания Maersk потеряла доступ к своим системам. Восстановление заняло более недели и обошлось в сотни миллионов долларов. После этого компания внедрила распределённую архитектуру с несколькими независимыми центрами восстановления.
• 2020 год, пандемия COVID-19 — массовый переход на удалённую работу потребовал от организаций пересмотра DRP с учётом того, что сотрудники не могут физически находиться в резервном центре. Возросла роль облачных решений и VPN-доступа.

Источники

1. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
2. Положение Банка России от 10.12.2020 № 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств».
3. ISO 22301:2019 «Security and resilience — Business continuity management systems — Requirements».
4. ISO 27031:2011 «Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity».
5. Whitman, M. E., & Mattord, H. J. (2019). Principles of Information Security. Cengage Learning.
6. Veeam Software. (2023). 2023 Data Protection Trends Report.
7. Gartner. (2022). Magic Quadrant for Disaster Recovery as a Service.