01DR — это не бэкап
Самое распространённое заблуждение: «у нас есть бэкапы, значит, мы защищены». Бэкап защищает данные, но не время. Если основная площадка недоступна, восстановление из бэкапов «на голое железо» занимает дни — а бизнесу нужны часы. Disaster Recovery — это готовая резервная площадка, на которой сервисы поднимаются за согласованное время (RTO) с потерей данных не больше согласованной (RPO).
Для компаний, возвращающихся в Россию, DR имеет дополнительный смысл: инфраструктура собирается из новых компонентов — новое облако, новый ЦОД, новое железо, новые каналы. У всего нового нет истории надёжности, и единственный способ её обеспечить — спроектированная отказоустойчивость с первого дня.
02С чего начинается: RTO и RPO
Два числа, которые определяют всё: RTO (Recovery Time Objective) — за какое время сервис должен быть восстановлен, и RPO (Recovery Point Objective) — сколько данных допустимо потерять. Эти числа определяет бизнес, а не IT: мы проводим интервью, считаем стоимость часа простоя для каждого сервиса и согласовываем целевые значения. От них зависит архитектура и бюджет.
| Уровень DR | RTO | RPO | Что требуется |
|---|---|---|---|
| Базовый (backup-restore) | 1–3 дня | 24 часа | Бэкапы 3-2-1, документированная процедура, резервный контур по запросу |
| Стандартный (тёплый резерв) | 4–8 часов | 15–60 минут | Резервная площадка, репликация данных, готовые образы, план переключения |
| Высокий (горячий резерв) | до 1 часа | ≈0 | Активная репликация, синхронные каналы, автоматический failover |
03Что входит в проект
- BIA (анализ влияния на бизнес). Критичность сервисов, стоимость простоя, целевые RTO/RPO по каждому сервису.
- Выбор резервной площадки. Другой регион: облако, ЦОД или комбинация; оценка каналов между площадками.
- Репликация. Базы данных (асинхронная/синхронная репликация), виртуальные машины (поснимочная), файлы (rsync/объектное хранилище), конфигурации (IaC).
- План восстановления. Пошаговый runbook: кто, что, в каком порядке делает; контакты, доступы, зависимости; план коммуникаций.
- Автоматизация. Скрипты переключения DNS, поднятия сервисов, проверок — чем меньше ручных шагов, тем быстрее реальное восстановление.
- Тесты. Плановые учения: от tabletop-разбора до полного переключения на резервную площадку с работой на ней. Протокол, найденные проблемы, исправления.
- Поддержание актуальности. DR-план устаревает вместе с инфраструктурой: пересмотр при изменениях, регулярные тесты (минимум 2 раза в год).
04Где размещать резервную площадку
Правило: другой город, другой ЦОД, другой провайдер каналов. Резерв в соседней стойке того же дата-центра не спасёт ни от аварии площадки, ни от регионального инцидента. Типовые схемы для России: основной контур в Москве — резерв в Санкт-Петербурге, Новосибирске или Казани; либо основной контур на своём железе — резерв в облаке (экономично: ресурсы резерва минимальны до момента переключения).
05Почему тесты важнее плана
DR-план, который не тестировался, — художественная литература. На первом реальном учении всегда находятся проблемы: реплика отстала, доступы не работают, DNS переключается дольше, чем планировалось, кто-то уволился, а он был единственным исполнителем шага 4. Каждое учение — это протокол, исправления и рост реальной готовности. Мы проводим первые учения сами, затем обучаем вашу команду или берём DR на сопровождение.
06Частые вопросы
Сколько стоит резервная площадка?
Зависит от уровня DR: базовый (бэкапы + облачный резерв «в свёрнутом виде») стоит заметно меньше, чем горячий резерв с синхронной репликацией. После BIA мы даём смету по уровням — бизнес выбирает осознанный баланс риска и бюджета.
Можно ли использовать российскую площадку как DR для глобальной инфраструктуры?
Да, такие проекты мы делаем: российский контур принимает часть глобальных сервисов при недоступности зарубежных площадок. Ключевые вопросы — каналы, задержки, объёмы репликации и юридическая допустимость размещения конкретных данных.
Как часто нужно тестировать DR?
Минимум дважды в год — плюс после каждого значимого изменения инфраструктуры. Хотя бы один тест в год — с реальным переключением сервиса на резервную площадку, а не только «на бумаге».
Чем DR отличается от отказоустойчивого кластера?
Кластер защищает от отказа компонента (сервер, диск) внутри площадки; DR — от потери всей площадки (пожар, авария, региональный инцидент, блокировка). Это разные уровни защиты; для критичных сервисов нужны оба.