Тема Disaster Recovery часто напоминает страховку: все про неё знают, оформляют «для галочки» и надеются, что страховой случай никогда не наступит. В итоге планы аварийного восстановления годами пылятся в недрах технической документации, а когда реально падает прод, команда в панике пытается вспомнить, как и куда разворачивать бэкапы.
Недавно на вебинаре Хайстекс как раз разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, и наиболее интересные из них легли в основу этого разбора.
Ссылка на полную версию вебинара с живой демонстрацией отказоустойчивости и архитектурными схемами будет ждать вас в конце статьи.
Что такое адекватные RTO и RPO?
Для начала стоит договориться о терминах.
RTO (Recovery Time Objective) — за какое максимальное время сервис должен вернуться в рабочее состояние. RPO (Recovery Point Objective) — какой максимальный объем данных бизнес готов потерять, обычно в минутах или часах.
На уровне пожеланий часто звучит «RTO = 0 и RPO = 0». Технически к этому можно приближаться, но цена и сложность растут очень быстро. RPO около нуля обычно требует синхронной репликации или очень частой фиксации изменений. RTO около нуля обычно требует активной резервной площадки, автоматизированного переключения трафика, проверенной сетевой модели и понятной логики разрешения конфликтов.
Поэтому RTO/RPO лучше рассматривать на трех уровнях:
-
Целевые — что хочет бизнес.
-
Проектные — что обещает архитектура.
-
Подтвержденные — что реально получилось на тестах.
Пока метрики не подтверждены регулярным фейловером, это не SLA, а гипотеза.
Если бизнес требует 15 минут RTO, а технический план включает ручной поиск бэкапа, восстановление нескольких ВМ, правку DNS и запуск SQL-скриптов «по памяти», значит реального RTO в 15 минут у вас нет.
Почему бумажный DR-план не работает?
Потому что авария почти никогда не идет по документу.
На бумаге все выглядит линейно: обнаружили сбой, объявили аварию, подняли резервную площадку, переключили пользователей, потом сделали failback. В реальности одновременно появляются десятки мелких проблем:
-
у части команды нет доступа к нужной консоли;
-
пароль от break-glass-аккаунта лежит в системе, которая тоже недоступна;
-
DNS-записи меняются дольше, чем ожидалось;
-
сертификат привязан к старому имени или старому IP;
-
внешняя интеграция не принимает трафик с резервной площадки;
-
база поднялась, но приложение не проходит миграции или health-check;
-
кластер потерял кворум;
-
мониторинг смотрит только на основной ЦОД и не видит резерв.
Рабочий DR-план — это отрепетированная процедура. Документ нужен, но он должен быть результатом тестов, а не заменой тестов.
Что превращает текстовый DR-план в работающий сценарий восстановления?
Самая частая проблема бумажного DR-плана — он написан человеческим языком, но в аварии его надо исполнять машиной и дежурной сменой под давлением. В хорошем DR-плане должны быть конкретные параметры:
-
какие машины входят в сценарий;
-
сколько CPU и RAM им нужно;
-
в каком порядке они стартуют;
-
какие сети и подсети создаются;
-
какие IP назначаются;
-
какие security groups или firewall-правила нужны;
-
какие задержки или условия ожидания есть между компонентами;
-
какие машины можно поднимать параллельно, а какие зависят от базы, брокера или AD.
В Хайстекс Акура эта идея выражена через DR-план: сценарий восстановления описывает машины, сети, ранги запуска и параметры инфраструктуры. План можно создавать через UI, генерировать для группы машин, формировать из списка машин или редактировать в экспертном JSON-режиме. Вместо ручного регламента появляется структура, которую можно переиспользовать для тестового Cloud Site и реального восстановления.
Но неудобный вопрос остается: кто поддерживает этот план актуальным после изменения прода?
Если команда добавила новую ВМ, изменила сеть, перенесла базу, поменяла размер диска или добавила зависимость от нового сервиса, DR-план должен измениться вместе с продом. Иначе он становится не планом восстановления, а снимком старой архитектуры.
Как протестировать DR и не сломать прод?
Для этого используется тестовый failover: резервные машины поднимаются из точек восстановления в изолированной сети. Такой режим позволяет проверить, что ОС загружается, сервисы стартуют, базы проходят recovery, скрипты адаптации отрабатывают, а зависимости между ВМ не разваливаются.
Ключевое слово здесь — изолированной. Тестовая копия не должна:
-
конфликтовать с продом по IP-адресам;
-
писать в боевые очереди, S3-бакеты, базы или CRM;
-
отправлять реальные письма и SMS;
-
регистрироваться в продуктивном service discovery;
-
участвовать в боевом кластере как еще одна нода.
В DR-платформах это обычно решается через отдельные тестовые сети, временные правила маршрутизации, NAT, отключение внешнего доступа или управляемые правила firewall. Например, в Акуре можно автоматизировать тестовый failover и поднимать ВМ на резервной площадке без воздействия на работающий прод.
Но сама платформа не знает всех бизнес-зависимостей приложения. Если тестовая копия при старте отправляет реальные платежи, это проблема не гипервизора, а архитектуры приложения и качества DR-runbook.
Для Акуры важная практическая деталь здесь — Cloud Site. Его можно использовать не только как рабочее аварийное восстановление, но и как площадку для проверки: поднять бизнес-приложение в резервном ЦОДе, пройти тесты, проверить сеть и зависимости, а затем удалить Cloud Site. Это как раз та механика, которая переводит DR из теории в регулярную репетицию.
Достаточно ли просто смонтировать диск с копией базы?
Не всегда. И это один из самых неприятных вопросов в DR.
Снапшот диска может быть согласованный по сбоям: примерно как состояние сервера после внезапного отключения питания. Многие СУБД умеют восстанавливаться из такого состояния за счет журналов транзакций. Но это не то же самое, что гарантированная согласованная на уровне приложений копия на нужный момент времени.
Для файлового сервера согласованной по сбоям копии часто достаточно. Для PostgreSQL, Oracle, MS SQL Server и других СУБД нужно понимать, в каком состоянии находятся:
-
файлы данных;
-
журналы транзакций;
-
архивные логи;
-
незавершенные транзакции;
-
внешние зависимости приложения.
В PostgreSQL надежный сценарий часто строится вокруг базового бэкапа и WAL-архива. Базовый бэкап дает стартовую точку, а WAL позволяет докатить изменения до нужного момента через PITR (Point-in-Time Recovery).
Упрощенно это выглядит так:
# Фрагмент конфигурации восстановления PostgreSQL.
# Конкретные параметры зависят от версии PostgreSQL и выбранного сценария.
restore_command = 'cp /mnt/archived_wal/%f %p'
recovery_target_time = '2026-06-11 10:15:00+03'
В Oracle похожая логика строится вокруг data files, archived redo logs и штатных инструментов восстановления. Детали отличаются, но принцип тот же: DR-платформа может доставить и поднять инфраструктуру, однако корректность восстановления СУБД определяется тем, насколько правильно подготовлены бэкапы, журналы и процедуры recovery.
Агентская или безагентская репликация?
Вопрос не в том, какой подход «правильный», а в том, где вы можете получить стабильную точку восстановления с приемлемой нагрузкой на прод.
Агентский подход работает внутри гостевой ОС. Он может лучше понимать состояние системы, использовать механизмы вроде VSS в Windows, запускать pre/post-скрипты и передавать измененные блоки на резервную сторону.
Безагентский подход работает на уровне гипервизора или платформы виртуализации. Он удобен для массовой защиты ВМ: не нужно ставить компонент внутрь каждой ОС, а снапшоты и чтение изменений выполняются средствами инфраструктуры.
Оба подхода имеют ограничения. Агенту важны совместимость с ОС и ядром, права, нагрузка на CPU/IO/network, корректная установка и обновление. Безагентской репликации важны возможности гипервизора, guest tools, качество снапшотов, доступ к механизму отслеживания изменившихся блоков и поведение приложений внутри ВМ.
Если продукт поддерживает оба варианта, выбор обычно делается по типу нагрузки:
Что делать, если агент потребляет слишком много ресурсов?
Если у ВМ высокий коэффициент оттока, то есть данные меняются постоянно и большими объемами, агент или гипервизор неизбежно будут читать, сжимать, передавать и подтверждать много блоков.
Перед внедрением DR стоит проверить:
-
есть ли ограничение пропускной способности по сети;
-
можно ли ограничить параллелизм;
-
можно ли разнести полные синхронизации по окнам;
-
есть ли лимиты на IO;
-
как продукт ведет себя при отставании репликации;
-
что происходит, если канал до резервной площадки временно деградировал.
Иногда достаточно пересмотреть RPO, выделить отдельный канал, исключить временные данные из репликации или изменить расписание тяжелых операций.
Для Linux-систем с нестандартными ядрами отдельно проверяйте совместимость модулей. Если используется DKMS или похожий механизм сборки драйвера под текущее ядро, это нужно тестировать заранее, а не в день аварии после обновления kernel minor version.
У Акуры здесь есть несколько практичных преимуществ: для VMware используются механизмы VMware CBT и снапшоты, для Windows — VSS, для Linux — блочный механизм консистентных снимков, а передача дельт идет с дедупликацией, сжатием и WAN-оптимизацией. Это не делает репликацию «бесплатной», но снижает объем передаваемых данных и дает инженерные рычаги для защиты разных типов инфраструктуры.
Почему lift-and-shift решает перенос ВМ, но не всю задачу DR?
Перенести ВМ на резервную площадку — это только часть задачи. После запуска машина должна оказаться в правильной сети, с правильными маршрутами, DNS, firewall-правилами, секретами и зависимостями.
DR-платформа может помочь с оркестрацией запуска, назначением IP-адресов, порядком старта, шаблонами сетевой адаптации и скриптами вроде cloud_init/user_data. Но она не может автоматически угадать, что конкретное приложение хранит адрес соседнего сервиса в старом конфиге, а лицензия привязана к mac_адресу.
Поэтому в DR-плане должны быть явно описаны:
-
какие IP меняются, а какие сохраняются;
-
как переключается DNS и какой TTL стоит заранее;
-
как обновляются security_groups, firewall и routing_allowed;
-
где лежат секреты и доступны ли они при падении основного ЦОДа;
-
какие внешние интеграции должны разрешить резервную площадку;
-
какие сервисы стартуют первыми, а какие ждут базу, брокер или LDAP/AD.
Если завтра резервная площадка поднимется с другими адресами, приложение должно уметь жить не в своей старой сети.
Что если у вас не один гипервизор, а мультиплатформенная инфраструктура?
В реальных инфраструктурах редко бывает стерильная картина, когда все ВМ живут в одном VMware-кластере. У компании может быть VMware, OpenStack, oVirt, KubeVirt, публичное облако, отдельные Linux/Windows-машины и временная площадка у провайдера.
Здесь важны два вопроса.
Первый: откуда мы забираем данные? Для разных источников используются разные механизмы: API гипервизора, change tracking, снапшоты, агент внутри ОС, чтение блочных изменений.
Второй: куда мы восстанавливаемся? Целевая площадка должна уметь принять машины, сети, диски, security_groups, маршруты и настройки доступа. Если целевое облако не подготовлено или не прошло валидацию, DR-план может быть правильным на бумаге, но невыполнимым технически.
Сильная сторона Акуры в том, что решение изначально работает с несколькими типами целевых облаков и платформ, в зависимости от поставки и конфигурации. В интерфейсе настраиваются target clouds, source/failback_clouds, параметры репликации, типы хранилищ, сети и cloud_agents. Для инженера это важно: DR перестает быть набором разрозненных скриптов под каждую площадку и становится единым управляемым процессом.
Как не сломать восстановление из-за изменившегося порядка дисков?
Имена блочных устройств в Linux не являются надежным контрактом. Сегодня диск может быть /dev/vdb, завтра — /dev/vdc или /dev/sdb, особенно если поменялись драйверы, порядок обнаружения устройств или тип виртуализации.
Хрупкий вариант:
mount /dev/vdb1 /var/lib/postgresql/data
Более надежный вариант — использовать стабильные идентификаторы:
UUID=2d7b0c5a-8b5b-4b3e-8c43-2b5a7f6c9d11 /var/lib/postgresql/data ext4 defaults,nofail 0 2
Или:
mount /dev/disk/by-uuid/2d7b0c5a-8b5b-4b3e-8c43-2b5a7f6c9d11 /var/lib/postgresql/data
Для некоторых систем удобнее использовать filesystem label, LVM, multipath или /dev/disk/by-id. Важно не название механизма, а принцип: DR-скрипт не должен зависеть от случайного порядка устройств при загрузке.
Что будет с кластерами, если на резервной площадке меньше узлов?
Кластеры плохо относятся к неопределенности. Если в основном ЦОДе было пять узлов, а на резервной площадке вы поднимаете три или один, нужно заранее понимать, как поведут себя:
-
кворум;
-
leader election;
-
изоляция;
-
статические списки peers;
-
старые IP и hostnames;
-
политики anti-affinity;
-
split-brain protection.
Для PostgreSQL-кластеров это может означать отдельную процедуру promotion. Для Kafka — проверку ISR, replication factor и controller quorum. Для etcd — аккуратную работу с membership. Для Kubernetes — отдельную стратегию восстановления control plane и etcd.
DR-платформа может поднять машины и выполнить сценарий оркестрации. Но решение «этот узел теперь primary», «этот peer удаляем из membership», «кворум пересобираем так» должно быть описано и проверено владельцами приложения.
Что если нужно восстановить не всю ВМ, а один файл, диск или образ?
Не каждая авария требует полного failover. Иногда пользователь удалил каталог, администратор испортил конфиг, база требует отдельного анализа журналов, а разработчикам нужен один диск из точки восстановления.
Если единственный доступный сценарий — «поднять всю машину целиком», команда будет тратить часы на задачу, которую можно решить точечно.
Полезно заранее иметь несколько уровней восстановления:
-
Загрузка образа из failover — достать отдельный файл или каталог из restore point;
-
Присоединение дисков — подключить диск из точки восстановления к уже запущенной машине для анализа или ручного восстановления;
-
Восстановление в виде виртуальной машины — поднять полноценную ВМ из restore point;
-
Восстановление файлов и папок — выгрузить диск в распространенном формате для внешнего восстановления или расследования.
В Акуре такие сценарии есть в продуктовой модели: восстановление файлов и папок, подключение диска, запуск ВМ из restore point, скачивание failover image или RAW-образа. Это сильная сторона не только для аварии, но и для повседневных инцидентов: не нужно каждый раз запускать полноценный DR, если задача точечная.
Как понять, что резервная площадка действительно готова?
Фраза «ВМ включилась» не означает, что сервис восстановлен. Минимальный набор проверок после тестового фейловера:
-
ОС загрузилась без emergency mode;
-
нужные файловые системы смонтированы;
-
база прошла recovery и принимает подключения;
-
приложение отвечает не только на port check, но и на бизнес health-check;
-
очереди, кэши и фоновые воркеры работают;
-
есть доступ к DNS, NTP, LDAP/AD, KMS, secret storage;
-
мониторинг и логи видят резервную площадку;
-
команда понимает, куда смотреть при ошибках;
-
результаты теста зафиксированы, а не обсуждены устно.
Хорошая практика — хранить evidence: время старта, скриншоты, логи, результаты health-check, список проблем и план исправления. Иначе через полгода никто не вспомнит, что именно было проверено.
Акура помогает закрыть часть этой операционной задачи с помощью логов событий, отчетов, графиков на панелях мониторинга и готовых сводок по процессам аварийного восстановления: состояние машин, использование дискового пространства и сервисная отчетность. Это не заменяет сквозную проверку работоспособности на уровне бизнес-логики приложения, но помогает собрать объективную доказательную базу: что реплицировалось, когда запускалось, какие действия выполнялись, где возникали ошибки и сколько ресурсов при этом потреблялось.
Чем DR отличается от бэкапа?
Бэкап отвечает на вопрос: «Есть ли у нас копия данных?» DR отвечает на вопрос: «Можем ли мы восстановить работающий сервис в заданное время и с заданной потерей данных?» Можно иметь отличные бэкапы и плохой DR. Например, если:
-
восстановление занимает двое суток при RTO четыре часа;
-
никто не знает порядок запуска сервисов;
-
бэкап базы есть, но WAL-архива нет;
-
данные восстановились, но приложение не работает из-за внешней зависимости;
-
резервная площадка не имеет нужных лицензий или сетевых доступов.
Обратная ошибка — считать репликацию заменой бэкапа. Репликация быстро переносит изменения, но так же быстро может перенести логическое удаление, шифрование ransomware или ошибку оператора. Поэтому для критичных систем нужны retention, immutable-копии, отдельные учетные данные, контроль удаления и периодические restore-тесты.
Если ransomware зашифрует прод и изменения уедут на резервную сторону, где находится последняя чистая точка восстановления?
Здесь у Акуры есть отдельный механизм: ransomware protection может обнаруживать аномально большой размер инкрементальной репликации и при превышении порога приостанавливать защиту этой машины, чтобы снизить эффект массового шифрования на DR-копии. Это не замена EDR, сегментации и immutable backup, но хороший предохранитель на уровне DR-процесса.
Как не разориться на длинной истории точек восстановления?
Для минимального RTO данные часто держат в cloud-native block storage: так восстановление быстрее, но хранение может быть дорогим.
Для долгого хранения история обычно уезжает в более дешевое объектное или файловое хранилище. Это снижает стоимость, но увеличивает RTO: перед запуском ВМ данные нужно прочитать, отрендерить или переложить обратно в блочное хранилище целевой площадки.
Это нормальный компромисс:
-
горячие restore points — быстрее восстановление, дороже хранение;
-
холодные restore points — дешевле хранение, дольше восстановление;
-
короткий retention — меньше стоимость, выше риск не найти чистую точку;
-
длинный retention — больше шансов пережить логическую ошибку или ransomware, но выше стоимость и сложность управления.
В Акуре это отражается через разные типы replication storage и retention policies: можно использовать cloud-native block storage для DR-сценариев с низким RTO или объектное/файловое хранилище для VM Backup и более длинной истории. Об этом коллеги подробнее писали тут.
Что происходит во время failback?
Failover обычно обсуждают чаще, чем failback. Хотя обратное переключение часто сложнее.
Когда основной ЦОД недоступен, пользователи работают на резервной площадке. Там появляются новые данные. Когда основной ЦОД восстановился, нельзя просто «включить старый прод»: он уже отстал и может содержать устаревшее состояние.
Нужен failback-процесс:
-
Зафиксировать, какая площадка сейчас является источником правды.
-
Остановить или ограничить запись на время финальной синхронизации.
-
Передать накопленную дельту изменений обратно.
-
Проверить консистентность.
-
Переключить трафик.
-
Убедиться, что старая резервная площадка снова стала резервной, а не продолжает жить как второй активный прод.
В разных платформах это реализуется по-разному: через обратную репликацию, временный failback-агент, миграцию средствами гипервизора или повторную защиту ВМ уже в обратную сторону. Важно не название механизма, а то, что этот сценарий должен быть протестирован до аварии.
Что если упал сам DR-контроллер?
Это вопрос, который часто забывают. DR-система тоже является частью инфраструктуры, а значит тоже может сломаться.
Нужно заранее понимать:
-
где хранится конфигурация DR-планов;
-
где находится каталог точек восстановления;
-
можно ли восстановить контроллер из внешнего бэкапа;
-
что будет, если база управления DR недоступна;
-
можно ли поднять критичные ВМ без исходного контроллера;
-
есть ли HA-режим для management plane;
-
кто и как разворачивает новый контроллер в чистой среде.
В Акуре и похожих DR-платформах для этого используются бэкап конфигурации контроллера и отказоустойчивые варианты развертывания в плоскости управления . Но общий принцип шире: DR-план должен включать восстановление самого инструмента DR.
Еще сильнее этот вопрос проявляется в сценариях с холодными архивами и переносимыми копиями. Если ваша точка восстановления существует только как запись в базе контроллера, потеря контроллера становится критичной. Поэтому для долгосрочного хранения полезны самодостаточные артефакты: пакет с данными, манифестом, контрольными суммами и инструкцией восстановления.
Что если основной ЦОД внезапно оживет?
Это классический риск сетевой сегментации: две площадки считают себя активными и принимают запись.
Автоматический failover звучит красиво, но без надежного fencing может создать больше проблем, чем решить. В реальном DR часто используется осознанное ручное подтверждение: человек или дежурная группа объявляет основную площадку недоступной, после чего запускается переключение.
Для критичных кластеров дополнительно нужны механизмы изоляции:
-
отключение питания или сетевой изоляции старой площадки;
-
fencing на уровне гипервизора;
-
запрет записи на старом primary;
-
контроль quorum/witness;
-
понятная процедура возврата площадки после восстановления.
Вместо вывода: чек-лист для самопроверки, пока всё работает
-
Для каждого критичного сервиса есть подтвержденные RTO и RPO, а не только желаемые?
-
Последний тестовый failover проводился недавно и с фиксированными результатами?
-
Тестовая среда изолирована от прода и внешних бизнес-систем?
-
Для СУБД проверено восстановление на нужный момент времени, а не только запуск ВМ?
-
Понятно, какие точки восстановления crash-consistent, а какие application-consistent?
-
Известно, как репликация влияет на CPU, IO, RAM и сеть источника?
-
DR-план обновляется вместе с изменениями прода?
-
Скрипты восстановления не завязаны на /dev/vdb1, старые IP и ручные действия «по памяти»?
-
Кластеры проверены на потерю узлов, смену primary, кворум и fencing?
-
Целевая площадка проверена по правам, квотам, сетям и лимитам?
-
Есть сценарии точечного восстановления: файл, диск, образ, отдельная ВМ?
-
Storage/retention выбраны по требованиям систем, а не оставлены дефолтом?
-
Есть план failback, а не только failover?
-
DR-контроллер, каталог и конфигурация тоже восстанавливаются?
-
Есть immutable или изолированные копии на случай ransomware?
-
Команда знает, кто принимает решение о переключении и как идет коммуникация, если основной канал связи недоступен?
Хорошая DR-платформа снимает много рутины: репликацию, оркестрацию запуска, тестовый фейловер, шаблоны сетевой адаптации, автоматизацию фейлбэка, хранение точек восстановления, отчеты и мониторинг. Это действительно важно. Но автоматизация не отменяет консистентность базы, кворум, внешние интеграции, DNS, секреты и порядок переключения трафика и тд. Пока DR-план не проходил репетицию, он не доказан. А прод обычно падает именно в тот момент, когда недоказанные предположения становятся самыми дорогими.
Полную версию вебинара с демонстрацией сценариев аварийного восстановления и архитектурными схемами можно посмотреть по ссылке.
ссылка на оригинал статьи https://habr.com/ru/articles/1048140/