DR-план на бумаге и DR-план в реальности: учебное восстановление показало разрыв вдвое

После волны CryptoLocker осенью и нескольких громких историй про затопленные датацентры в США клиенты начали приходить с одним и тем же вопросом: «А у нас DR-план есть, мы вообще проверяли, работает ли он?» В большинстве случаев ответ на вторую часть был «нет» - документ есть, учений не было.

Один из таких клиентов - средний производственный бизнес, managed-сопровождение у нас уже пару лет - предложил провести честное учебное восстановление. Не «посмотрим в консоль Veeam и убедимся, что галочки зелёные», а именно учение: берём и физически отключаем prod-хранилище в основной серверной, а потом поднимаем всё из реплики в резервной. RTO по документу - четыре часа. Ударили по рукам.

Подготовка заняла больше, чем само восстановление. Согласовали окно на субботу, предупредили ключевых пользователей, собрали чек-лист шагов. Казалось бы, всё под контролем.

Учение пошло не по плану примерно с первых минут.

Первое - сетевые настройки в резервной серверной. Репликация Veeam работала исправно, виртуальные машины поднялись достаточно быстро. Но IP-адреса в резервной подсети отличались от prod - об этом в DR-плане была одна строчка: «перенастроить сетевые параметры по схеме». Схема оказалась устаревшей на полгода: за это время prod-сеть перекроили, а резервный сегмент остался как был. Полчаса разбирались с адресацией, ещё полчаса - с тем, что AD-контроллер в резервной серверной поднялся с конфликтом имён.

Второе - зависимости, которые никто не документировал. Учётная система смотрела на файловый сервер по UNC-пути с хардкоженным именем хоста. Имя в реплике не менялось, но DNS в момент переключения какое-то время отдавал старую запись. Пользователи получили бы ошибку «сервер недоступен» - не потому что он упал, а потому что клиент не туда смотрит.

Третье - люди. DR-план описывал технические шаги. Про то, кто звонит провайдеру для переключения внешнего IP, в документе была фраза «ответственный администратор». В субботу выяснилось, что этот человек в отпуске, а контакт провайдера у него в рабочем почтовом ящике - который в этот момент тоже лежал.

В итоге подняли всё за восемь часов вместо четырёх. Сервисы заработали, данные не потеряли - но разрыв с задокументированным RTO оказался ровно вдвое. И это при том, что учение шло в штатных, даже тепличных условиях: нет паники, нет реального давления, мы рядом и всё контролируем. При реальном инциденте добавились бы стресс и потеря нескольких часов только на осознание происходящего.

Что вынесли из этого учения:

• DR-план - живой документ. Он устаревает каждый раз, когда меняется prod-инфраструктура. Если изменения в основной серверной не синхронизируются с DR-документом автоматически или хотя бы по чек-листу изменений - план гниёт незаметно.
• Сетевую схему резервного сегмента надо держать актуальной и тестировать отдельно, не дожидаясь учений.
• Контакты и доступы - отдельный раздел в DR-плане, не просто «ответственный администратор». Конкретный человек, его заместитель, контакты провайдера, логины от out-of-band управления - всё это должно быть доступно без корпоративной почты.
• Зависимости внутри инфраструктуры часто не документируются вообще. Хардкоженные UNC-пути, имена хостов в конфигах, ссылки на конкретные IP - это бомбы замедленного действия при любом переключении.

Клиент воспринял результат конструктивно - собственно, ради этого и звали. Теперь планируем повторить учение через полгода с исправленным планом и посмотреть, укладываемся ли в RTO. Пока что четыре часа выглядят достижимо, но только если заранее разобраться с сетью и контактами.

История с CryptoLocker в октябре напомнила, что DR - не про резервный датацентр у крупных корпораций, а про базовую гигиену у всех. И бэкап в облако - это только часть истории: бэкап без проверки восстановления остаётся гипотезой.