Открыть сервис
Главная → Блог → Disaster Recovery

Disaster Recovery

Disaster Recovery (аварийное восстановление, DR) — это совокупность политик, процедур, технических и организационных мер, направленных на восстановление работы информационных систем, инфраструктуры и данных организации после наступления аварии, сбоя или катастрофы. Основная цель Disaster Recovery — минимизировать время простоя (Downtime) и потерю данных (Data Loss), обеспечив возврат к нормальному функционированию в заданные сроки, определённые в целевом времени восстановления (RTO) и целевой точке восстановления (RPO).

История

Концепция аварийного восстановления возникла в середине XX века вместе с развитием крупных вычислительных центров (мейнфреймов). Первоначально она сводилась к созданию резервных копий данных на магнитных лентах и их хранению в удалённых физических хранилищах. В 1970-х годах, с ростом зависимости бизнеса от ИТ, появились первые коммерческие услуги «горячих» резервных площадок (Hot Site), предоставляемые компаниями, такими как SunGard (основана в 1978 году). В 1990-х годах, с распространением клиент-серверной архитектуры и интернета, DR-стратегии стали включать репликацию данных, кластеризацию и аварийное переключение (Failover). В 2000-2010-х годах, с развитием облачных вычислений и виртуализации, Disaster Recovery приобрёл новые формы, такие как «Disaster Recovery as a Service» (DRaaS), что позволило организациям отказаться от дорогостоящих собственных резервных центров обработки данных (ЦОД).

Ключевые понятия и метрики

Целевое время восстановления (RTO)

Recovery Time Objective (RTO) — максимально допустимое время, в течение которого система или сервис могут быть недоступны после аварии. RTO измеряется в секундах, минутах или часах. Например, для критически важных систем RTO может составлять менее 15 минут, для менее критичных — несколько часов или суток.

Целевая точка восстановления (RPO)

Recovery Point Objective (RPO) — максимально допустимый объём потери данных, выраженный во времени, на которое данные могут быть устаревшими на момент восстановления. RPO определяет, как часто необходимо создавать резервные копии или реплицировать данные. Например, RPO в 1 час означает, что в случае сбоя могут быть потеряны данные за последний час.

Время восстановления (RTO vs RTT)

Важно различать RTO и фактическое время восстановления (Recovery Time, RTT). RTO — это цель, а RTT — реальный показатель, который должен быть меньше или равен RTO.

Классификация аварий и катастроф

Аварии, требующие применения DR-процедур, классифицируются по масштабу, причине и длительности:

  • Физические катастрофы: пожары, наводнения, землетрясения, ураганы, техногенные аварии (например, отключение электроэнергии, обрыв кабеля).
  • Логические сбои: программные ошибки (баги), сбои операционной системы, повреждение файловой системы, ошибки персонала (например, случайное удаление данных).
  • Кибератаки: атаки вредоносного ПО (включая программы-вымогатели), DDoS-атаки, взломы, утечки данных.
  • Аппаратные сбои: выход из строя жёстких дисков, блоков питания, сетевого оборудования, серверов.

Стратегии аварийного восстановления

Выбор стратегии зависит от критичности систем, бюджета и требований к RTO/RPO. Основные стратегии:

Холодное резервирование (Cold Site)

Это минимальный уровень готовности. Представляет собой физическое помещение (или выделенное место в ЦОДе) с необходимой инфраструктурой (электропитание, охлаждение, сеть), но без установленного оборудования. В случае аварии оборудование завозится, устанавливается и настраивается. RTO — от нескольких дней до недель. RPO — зависит от последней резервной копии.

Тёплое резервирование (Warm Site)

Помещение с частично установленным и настроенным оборудованием (серверы, сетевое оборудование), но без актуальных данных и приложений. Для запуска требуется загрузка данных из резервных копий и настройка ПО. RTO — от нескольких часов до суток. RPO — от нескольких часов до суток.

Горячее резервирование (Hot Site)

Полностью дублирующий центр обработки данных, который работает в режиме реального времени. Все данные реплицируются синхронно или асинхронно, приложения настроены, сеть готова. Переключение на горячий сайт происходит автоматически или по команде оператора. RTO — от нескольких минут до часа. RPO — от нуля (синхронная репликация) до нескольких минут.

Disaster Recovery as a Service (DRaaS)

Облачная модель, при которой провайдер предоставляет инфраструктуру, ПО и управление процессами аварийного восстановления как услугу. Организация платит за использование ресурсов только в случае аварии или за постоянную репликацию данных в облако. DRaaS позволяет гибко масштабировать ресурсы и снижает капитальные затраты (CAPEX). RTO и RPO зависят от SLA с провайдером, но обычно составляют от нескольких минут до нескольких часов.

Процесс аварийного восстановления

Процесс DR обычно включает следующие этапы:

  1. Обнаружение и оценка: Системы мониторинга фиксируют аварию, определяется её масштаб и критичность.
  2. Активация плана: Принимается решение о запуске DR-процедур. Активируется команда реагирования.
  3. Переключение (Failover): Трафик и операции перенаправляются на резервную площадку (горячий/тёплый сайт или облако).
  4. Восстановление данных: Данные восстанавливаются из резервных копий или реплик.
  5. Тестирование и проверка: Проверяется работоспособность систем, целостность данных и доступность сервисов.
  6. Возврат (Fallback): После устранения причины аварии на основной площадке производится обратное переключение с резервной на основную инфраструктуру.
  7. Анализ и документирование: Проводится разбор инцидента, выявляются ошибки, вносятся изменения в план DR.

План аварийного восстановления (DRP)

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

  • Цели RTO и RPO для каждой критической системы.
  • Перечень ответственных лиц и их контакты (включая подрядчиков и вендоров).
  • Описание процедур для каждого типа аварий.
  • Схемы сетевой и аппаратной инфраструктуры.
  • Инструкции по восстановлению данных и приложений.
  • Порядок тестирования плана (регулярные учения).
  • Список критических активов и их приоритетность.

Тестирование и аудит

Регулярное тестирование DRP — обязательное условие его эффективности. Виды тестирования:

  • Столовая проверка (Tabletop Exercise): Команда устно обсуждает сценарий аварии и действия по плану.
  • Частичное тестирование: Проверяется восстановление одной системы или подсистемы.
  • Полномасштабное тестирование (Full-scale Test): Имитация полной аварии с переключением на резервную площадку и возвратом. Проводится в изолированной среде или в нерабочее время.

Аудит DRP проводится независимыми экспертами или внутренними аудиторами для оценки соответствия плана требованиям бизнеса и нормативным актам (например, 152-ФЗ «О персональных данных» в РФ, стандартам ISO 22301).

Применение в России

В Российской Федерации требования к аварийному восстановлению регулируются рядом нормативных актов, в частности:

  • Федеральный закон № 152-ФЗ «О персональных данных»: требует от операторов персональных данных обеспечивать их сохранность и возможность восстановления.
  • Приказы ФСТЭК России: устанавливают требования к защите информации, включая резервное копирование и восстановление для государственных информационных систем и объектов критической информационной инфраструктуры (КИИ).
  • Стандарты Банка России: для кредитных организаций устанавливают жёсткие требования к RTO и RPO, а также обязательное наличие резервных ЦОДов.

Многие крупные российские компании (например, Сбербанк, Яндекс, Ростелеком) используют собственные географически распределённые ЦОДы с горячим резервированием. Малый и средний бизнес всё чаще обращается к услугам российских провайдеров DRaaS, таких как Selectel, Cloud4Y, Yandex Cloud (сервис «Аварийное восстановление»).

Критика и ограничения

Основные критики Disaster Recovery сводятся к следующему:

  • Высокая стоимость: Создание и поддержание горячего резервного сайта требует значительных капитальных и операционных затрат.
  • Сложность: Разработка и поддержание актуального DRP, особенно в динамично меняющейся ИТ-среде, является трудоёмкой задачей.
  • Человеческий фактор: Даже лучший план может быть неэффективен, если персонал не обучен или не готов к его выполнению.
  • Недостаточное тестирование: Многие организации проводят тестирование DRP формально или не проводят его вовсе, что приводит к сбоям при реальной аварии.
  • Зависимость от вендоров: При использовании DRaaS или проприетарных решений организация может оказаться в зависимости от одного поставщика.

Источники

  • Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
  • Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах».
  • ГОСТ Р 53647.1-2009 (ISO 22301:2012) «Менеджмент непрерывности бизнеса. Общие требования».
  • ITIL Foundation, ITIL 4 edition.
  • NIST Special Publication 800-34, «Contingency Planning Guide for Federal Information Systems».
  • Материалы конференций и вебинаров компаний-провайдеров DRaaS (Selectel, Cloud4Y, Yandex Cloud).

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

На главную BFOmetr →

Похожие материалы