Disaster Recovery

Что такое Disaster Recovery

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

Ключевое слово — сервис, а не «данные». Данные могут лежать в целости в резервных копиях, пока бизнес стоит: сеть не настроена, DNS смотрит в мёртвую площадку, лицензии привязаны к погибшим серверам, а человек с паролем от хранилища в отпуске. DR — про то, чтобы вся эта цепочка отработала.

RPO и RTO

Два числа, вокруг которых строится всё остальное:

       RPO                      RTO
   |<-------->|              |<-------->|
---+----------+--------------+----------+--->  время
 последняя   АВАРИЯ        начало     сервис
 копия                  восстановления  работает

RPO — сколько данных не жалко потерять (отсчёт назад от аварии)
RTO — сколько времени можно лежать (отсчёт вперёд от аварии)

RPO определяет, как часто снимать копии и реплицировать. RTO определяет, что и в каком виде держать наготове. Оба числа назначает бизнес, а не админ: «ноль и ноль» хочется всем, но за каждый шаг к нулю платят деньгами, поэтому реальная задача — назвать сумму, которую не жалко, и получить под неё честные цифры.

DR — это не бэкап и не HA

Три термина, которые постоянно смешивают:

Кластер из двух узлов в одной стойке — это HA, и от пожара в зале он не спасёт. Бэкап — необходимый компонент DR, но сам по себе не отвечает ни за DNS, ни за балансировщик, ни за порядок запуска сервисов.

Стратегии

Классическая лестница — чем ниже строка, тем меньше RTO и больше счёт:

Выбор делается не «по красоте», а от стоимости часа простоя. Если час простоя стоит меньше, чем месяц содержания второй площадки, вся правда жизни — в первой строке таблицы.

Технические грабли

• Синхронная или асинхронная репликация. Синхронная даёт RPO около нуля, но добавляет round-trip до второй площадки в каждую транзакцию записи — на межрегиональном плече задержка убивает производительность. Асинхронная не тормозит запись, но RPO равен лагу репликации.
• DNS и TTL. Переключение трафика упирается в кеши резолверов. Снижать TTL нужно заранее, а не в момент аварии, иначе часть клиентов будет ходить на мёртвый IP ещё сутки.
• Split-brain. Автоматический failover без арбитра рано или поздно поднимает вторую активную площадку при живой первой — и вы получаете две расходящиеся копии данных вместо одной аварии.
• Обратное переключение. План возврата на основную площадку забывают чаще, чем сам failover, а данные за время аварии накопились именно на резервной.
• Зависимости за периметром. Внешние API, лицензионные серверы, CI, репозитории и почта тоже должны быть в плане.

Испытания

План, который не проверяли, не работает — это правило без исключений. Уровни учений: разбор на бумаге, частичное переключение отдельного сервиса, полный failover с секундомером. Проверяют не факт «поднялось», а укладывается ли реальное время в заявленный RTO, и не всплывает ли на середине пароль, который знал только уволившийся коллега.

Runbook пишется командами, а не намерениями: строка «восстановить базу» бесполезна в три часа ночи, строка с конкретной командой и путём к репозиторию — работает. Для виртуальных сред проверку автоматизируют — например, Veeam умеет поднимать ВМ из копии в изолированной песочнице и проверять, что ОС и сервисы стартовали.

Связанные термины

• Резервное копирование — фундамент DR и его обязательный компонент
• SLA и отказоустойчивость — где RPO и RTO становятся обязательствами
• Veeam — типовой инструмент DR для виртуальной инфраструктуры
• Репликация — как данные попадают на резервную площадку
• ЦОД — то, потерю чего и отрабатывает DR
• snapshot — быстрый откат, который DR не заменяет