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-доступа.

¶Источники

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

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →