Disaster Recovery — это как пожарная тревога и план эвакуации в здании: пока не сработает, кажется лишней тратой, а когда сработает, спасает бизнес от закрытия. Это процесс восстановления ИТ-инфраструктуры после катастрофы — отказа ЦОД, пожара, наводнения или атаки шифровальщика. Разница между компаниями с планом восстановления и без него проста: первые возвращаются к работе за часы, вторые нередко не возвращаются вовсе. И ключевая ловушка тут одна: план, который написали и ни разу не проверили боевым переключением, в момент катастрофы почти всегда оказывается нерабочим.
Что такое Disaster Recovery простыми словами
Вся суть DR умещается в один вопрос: чем поднимать инфраструктуру, если основная площадка выбыла целиком. По соседству лежат два похожих понятия, которые с ним смешивают. Бэкап дает копию данных, но сам по себе не поднимает работающие сервисы — DR лишь берет копии как один из своих инструментов, охватывая при этом всю процедуру возврата к жизни. Кластер высокой доступности прикрывает от падения одного узла внутри площадки, тогда как DR рассчитан на потерю площадки целиком. Заменить друг друга они не могут: HA удерживает сервис на плаву при локальном сбое, а DR переносит его на запасную территорию, когда исходная выбывает полностью.
Катастрофы бывают разной природы, и план должен покрывать их все. Физические — пожар, затопление серверной, отказ электропитания или системы охлаждения ЦОД. Логические — атака шифровальщика, повреждение данных, ошибка администратора. Внешние — отказ провайдера связи или самого дата-центра. Ключевая мысль: DR это не разовый проект «написали и забыли», а процесс. Инфраструктура меняется, появляются новые системы, и план, не обновляемый вместе с ней, устаревает за месяцы.
Business Impact Analysis (BIA)
Планирование начинают не с технологий, а с анализа рисков и последствий — Business Impact Analysis (BIA). Начинают с сортировки систем по значимости: критичные останавливают бизнес при отказе, важные переживают недолгий простой, вспомогательные поднимают в последнюю очередь. От этой раскладки зависит и очередность восстановления, и распределение бюджета. По каждой критичной системе фиксируют максимально допустимый период простоя (MTPD) — рубеж, за которым ущерб уже не отыграть.
BIA переводит простой в деньги и обязательства. Оценивают прямой убыток за час простоя, урон репутации и, как отдельную статью, правовые последствия. Для операторов персональных данных нарушение доступности регулируется 152-ФЗ, для значимых объектов КИИ — 187-ФЗ, и несоблюдение требований к непрерывности грозит не только убытками, но и санкциями регулятора. Именно эти цифры и обязательства, а не технические предпочтения, задают требования к плану восстановления.
RTO и RPO по каждой системе
Для каждой системы из BIA вытекают два числа. Первое, RTO (Recovery Time Objective), отвечает на вопрос, за сколько сервис обязан вернуться в строй после катастрофы. Второе, RPO (Recovery Point Objective), очерчивает, данные за какой промежуток допустимо потерять. Именно эта пара и задает архитектуру: жесткий RTO в минуты вынуждает держать горячий резерв, мягкий в сутки позволяет разворачиваться из бэкапа; нулевой RPO требует синхронной репликации, а суточный закрывается ночной копией.
Метрики всегда сопоставляют со стоимостью решения и закрепляют в SLA — чем жестче RTO и RPO, тем дороже DR. Целевые значения задают по типу системы: для продуктивной 1С или основной базы данных обычно закладывают RTO в десятки минут и RPO в минуты; для веб-фронта — RTO в минуты; для внутренних вспомогательных систем допустимы RTO в сутки и RPO в часы. Разные системы получают разные цели — платить за нулевой RPO для файлового архива бессмысленно.
Стратегии Disaster Recovery
Под разные цели сложились четыре опорные стратегии, и растут они по цене вместе со скоростью возврата. Самая экономная — Backup & Restore: держим только копии и разворачиваем сервисы на новом железе после аварии, на что уходит порядка 8-24 часов при затратах около 5-15% от стоимости продуктива. Pilot Light идет дальше: базы уже реплицируются на резерв, а серверы приложений стоят выключенными и поднимаются по тревоге за десятки минут, обходясь в 20-40%. Warm Standby — это уже дремлющая копия инфраструктуры, которую будят за минуты, и стоит она примерно 50-70%.
На вершине — Hot Standby и Multi-Site. В варианте Hot Standby (Active-Passive) резервная площадка полностью развернута и синхронно повторяет продуктив, так что возврат укладывается в 1-15 минут при почти нулевой потере данных, а переезд выполняет failover. Multi-Site (Active-Active) держит оба ЦОД в работе под общей балансировкой: простой стремится к нулю, но и ценник стартует от 100% стоимости продуктива. Выбор стратегии — это не поиск «лучшей», а сопоставление требуемых RTO и RPO с тем, сколько бизнес готов платить.
Резервный ЦОД: где размещать
DR-площадка должна быть географически отделена от основной, и вариантов размещения несколько. Собственный второй ЦОД дает полный контроль, но дорог в строительстве и содержании — под него нужны серверы, сетевое ядро и инженерная инфраструктура. Colocation у российского провайдера снимает капитальные затраты: вы ставите свое оборудование в чужой дата-центр. Российское облако (Yandex Cloud, VK Cloud, Cloud.ru) позволяет строить DR как услугу (DRaaS) без закупки железа под резерв.
Распространенный компромисс — гибрид: продуктив на своей площадке (on-prem), а DR в облаке, что дает географическое разнесение без второго собственного ЦОД. Между площадками прокладывают быстрый канал, для которого важно грамотное сетевое оборудование. И ключевое ограничение для РФ: по 152-ФЗ персональные данные россиян должны храниться на территории страны, поэтому DR-площадка операторов ПДн обязана физически находиться в РФ — иностранное облако под резерв не подойдет, а российские DRaaS-провайдеры это требование закрывают.
Инструменты и технологии
Техническая основа DR — репликация данных на резервную площадку, и инструмент выбирают по типу системы. Проектирование и внедрение помогает выстроить система резервного копирования с функциями DR. Базы данных реплицируют штатными средствами: MS SQL AlwaysOn, PostgreSQL с потоковой репликацией и Patroni, MySQL Group Replication. Виртуальные машины переносят через Hyper-V Replica или DR-модули отечественных систем вроде RuBackup.
Хранилища зеркалируют на уровне массива (SAN mirror) или файловой системы (ZFS send/recv), что дает репликацию независимо от приложений. Отдельный слой — переключение трафика: при аварии клиентов перенаправляют на резервную площадку через смену DNS-записей или глобальные балансировщики. Без автоматизированного переключения даже идеально реплицированный DR-стенд остается недоступным для пользователей, пока кто-то вручную не поменяет маршруты.
Runbook и процесс восстановления
План бесполезен, если в момент катастрофы непонятно, кто и что делает. Runbook расписывает действия по шагам: за кем закреплен каждый этап, какова очередность подъема сервисов, кого ставить в известность. Саму очередность выстраивают деревом приоритетов (priority tree): вперед идут инфраструктурные службы и критичные системы, следом важные, а вспомогательные замыкают список. Восстанавливать все одновременно нельзя: ресурсы резервной площадки ограничены, и хаотичный запуск затягивает возврат к работе.
Отдельно прописывают связь в кризис. Основные каналы связи могут быть недоступны вместе с основной площадкой, поэтому заранее определяют резервные — мессенджеры, телефоны, точки сбора команды. Runbook разделяет внутренние коммуникации (кто координирует восстановление) и внешние (что и когда сообщать клиентам, партнерам, регулятору). Молчание во время инцидента бьет по репутации не меньше самого простоя.
Тесты DR: как проверить план
DR-план, который ни разу не проверяли, — это предположение, а не защита. Проверку ведут на нескольких уровнях глубины. Табличные учения (tabletop exercises) — команда разбирает сценарий катастрофы «на бумаге», проверяя логику плана и зоны ответственности без реального переключения. Частичный тест поднимает на резервной площадке отдельный компонент — например, одну базу — и замеряет фактические RTO и RPO против целевых.
Глубже идет полный тест на изолированной среде: разворачивают весь стек на DR-площадке, не затрагивая продуктив, и проверяют, что сервисы реально работают. Высший уровень — DR-drill, боевое переключение продуктива на резерв. Табличный тест проводят раз в квартал, полноценный DR-drill — раз в 6-12 месяцев. Именно на тестах вскрываются расхождения между планом и реальностью: устаревшие адреса, забытые зависимости, неверные RTO, — и вскрываются они до катастрофы, а не во время.
Регуляторика в РФ
Для многих организаций DR не только здравый смысл, но и требование закона, и соответствие проверяют при аудите безопасности. По 152-ФЗ персональные данные граждан РФ хранят на территории страны, что напрямую влияет на выбор DR-площадки. По 187-ФЗ значимые объекты критической информационной инфраструктуры обязаны обеспечивать непрерывность и восстановление после инцидентов.
Отдельный документ — приказ ФСТЭК № 239, задающий требования к защите значимых объектов КИИ, в том числе к действиям при инцидентах и восстановлению. Для операторов КИИ и ГИС DR-план из желательной практики превращается в обязательный элемент, наличие и работоспособность которого проверяет регулятор. Поэтому план не только пишут, но и подтверждают тестами — формального документа без доказанной работоспособности недостаточно.
Сравнение стратегий DR
Заключение: с чего начать
Рабочий Disaster Recovery строят от бизнеса, а не от технологий. Короткий порядок действий:
- провести BIA — классифицировать системы и определить MTPD для критичных;
- задать RTO и RPO по каждой системе и перевести их в деньги;
- под эти метрики выбрать стратегию — от Backup & Restore до Hot Standby;
- разместить DR-площадку с учетом 152-ФЗ (для ПДн — только РФ);
- настроить репликацию и автоматическое переключение трафика;
- написать runbook с деревом приоритетов и резервными каналами связи;
- тестировать план: табличные учения ежеквартально, DR-drill раз в год.
Пройденный цикл отличает план, который реально поднимет бизнес после катастрофы, от документа, который вспомнят слишком поздно.
Часто задаваемые вопросы
Что такое Disaster Recovery простыми словами?
Это процесс восстановления ИТ-инфраструктуры после катастрофы, когда основная площадка целиком вышла из строя. DR-план описывает, как и в каком порядке поднять сервисы на резервной территории за отведенное время.
Чем DR отличается от резервного копирования?
Бэкап — это копия данных, а DR — полная процедура восстановления работающих сервисов, где бэкап лишь один из инструментов. Бэкап отвечает на вопрос «где взять данные», DR — «как поднять всю инфраструктуру на другой площадке».
Что такое RTO и RPO?
RTO (Recovery Time Objective) — целевое время восстановления сервиса после аварии. RPO (Recovery Point Objective) — допустимая потеря данных в единицах времени. Эти две метрики задают всю архитектуру и стоимость DR.
Сколько стоит построить DR-инфраструктуру?
Зависит от стратегии: Backup & Restore обходится в 5-15% бюджета продуктива, Pilot Light — 20-40%, Warm Standby — 50-70%, Hot Standby и Multi-Site — 100% и выше. Цену диктуют требуемые RTO и RPO.
Обязательно ли иметь DR-план по 152-ФЗ и 187-ФЗ?
Для операторов персональных данных и значимых объектов КИИ обеспечение непрерывности и восстановления — требование закона. По 152-ФЗ данные хранят в РФ, по 187-ФЗ и приказу ФСТЭК № 239 значимые объекты обязаны восстанавливаться после инцидентов.
Что такое Pilot Light и Warm Standby?
Pilot Light — минимальный DR-стенд, где базы реплицируются, а серверы приложений выключены и поднимаются при аварии (RTO десятки минут). Warm Standby — копия инфраструктуры в спящем режиме, готовая быстро принять нагрузку (RTO в минуты).
Как часто тестировать DR-план?
Табличные учения проводят раз в квартал, полноценное боевое переключение (DR-drill) — раз в 6-12 месяцев. Без регулярных тестов план устаревает вместе с инфраструктурой, и в момент катастрофы оказывается нерабочим.
Можно ли использовать облако как DR-площадку?
Да, российские провайдеры предлагают DR как услугу (DRaaS) без закупки железа под резерв. Для операторов персональных данных важно, чтобы облако находилось в РФ по 152-ФЗ — российские DRaaS это требование закрывают.
Поможем построить DR-план
Строите Disaster Recovery план для критичной инфраструктуры? Инженеры Serverzilla подготовят BIA, рассчитают RTO и RPO по системам, спроектируют DR-площадку (свой ЦОД, colocation или российское облако) и составят runbook. Начнем с аудита ИТ-инфраструктуры. Оставьте заявку.
