Аварийное восстановление
Выбор сайта DR
Сайт аварийного восстановления должен быть достаточно удалён, чтобы не разделить бедствие, и достаточно близок для нужного вам режима репликации. Эти два ограничения — плюс реально существующие объекты на рынке-кандидате — определяют шортлист до любого разговора с поставщиком. Инструмент ниже проверяет все три на основе реальных данных: измеренные времена обхода между 14 рынками и каталог 1629 объектов.
Поиск пары DR
Выберите основной рынок. Кандидаты ранжированы по времени обхода с указанием режима репликации, поддерживаемого каждым расстоянием.
| Кандидат DR | RTT | Поддерживаемая репликация | Объекты на рынке |
|---|
Цифры RTT — опубликованные облачные inter-region measurements (Azure, cloudping.co) — источники на матрице задержек. Волоконно-оптические маршруты между колокейшн-объектами идут похожими путями; проверьте точную пару с операторами перед привязкой RPO к ней.
Режим репликации определяется физикой
Свет в оптоволокне преодолевает примерно 100 км за миллисекунду времени туда-обратно. Это единственное число определяет архитектуру: синхронной репликации требуется время туда-обратно в пределах бюджета записи приложения, что ограничивает расстояние примерно до 100 км — всё остальное работает асинхронно, независимо от гарантий хранилища.
| Режим | Бюджет RTT | RPO | Что это означает |
|---|---|---|---|
| Синхронная | ≤ ~10 ms | Нулевой | Каждая запись подтверждается на обоих сайтах, прежде чем приложение продолжит работу. Задержка транзакции включает время в оба конца, поэтому расстояние становится налогом приложения. |
| Квазисинхронная | ~10–25 ms | Секунды | Записи передаются непрерывно с ослабленным подтверждением. Практический выбор для близлежащих пар, вроде Франкфурт–Амстердам или Сингапур–Куала-Лумпур. |
| Асинхронная | Любая | Минуты | Сайт DR отстаёт на интервал репликации. Единственный вариант на дальние расстояния — и правильный для большинства нагрузок в любом случае. |
Четыре сценария DR, честная цена
Стоимость выражена как доля затрат основного сайта. Сценарий определяет RTO; режим репликации определяет RPO; комбинация определяет бюджет. Большинство инфраструктур используют разные сценарии для разных типов нагрузки — активный-активный для основных потоков, резервная копия и восстановление для всего, что может ждать день.
| Сценарий | RPO | RTO | Стоимость к основному | Как это работает |
|---|---|---|---|---|
| Резервная копия и восстановление | Часы–день | Дни | ~5% | Резервные копии реплицируются за пределы ДЦ, инфраструктура развёртывается только при возникновении сбоя. Дёшево и медленно, а восстановление — то, что никто никогда не проверял. |
| Дежурный режим | Минуты–часы | Часы | ~10–20% | Основные данные реплицируются на минимальную конфигурацию, которая масштабируется при переключении на резерв. На дежурном ДЦ находятся несколько стоек с базами данных; вычислительные ресурсы добавляются по необходимости. |
| Горячий резерв | Секунды–минуты | Минуты–час | ~30–50% | Уменьшенная копия production работает постоянно. Переключение — это просто активация резерва, а не построение новой инфраструктуры. |
| Активно-активная | ≈ Ноль | ≈ Ноль | 100%+ | Оба сайта обслуживают трафик; потеря одного — это событие нехватки ёмкости, а не отказ в обслуживании. Требует специальной архитектуры приложения — добавление этого в существующее — полная переписка. |
Рассчитайте стоимость резервной конфигурации, используя калькулятор расходов на колокейшн по ставке индекса целевого рынка.
Что на самом деле выходит из строя
При планировании DR часто представляют землетрясения. Однако согласно журналу инцидентов, реальные угрозы ближе к счётчику: скачки питания в сети, пожары батарей ИБП, отказы охлаждения и сбои сетевого оборудования. Дежурный ДЦ на той же энергосети, в той же зоне затопления и в том же операторском хабе практически не защищает от этих угроз. Последние записи:
- 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
- 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
- 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
- 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
- 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia
Чеклист дежурного ДЦ
- Другая энергосеть, чем у основного ДЦ — проверьте реальную подстанцию, не маркетинговое утверждение
- Вне зоны затопления и сейсмической активности основного ДЦ
- Разнесённые оптические тракты: два ДЦ не должны использовать один операторский хаб или один пункт посадки кабеля
- RTT измерено, не оценено — и укладывается в лимит задержки выбранного режима репликации
- Объект имеет необходимую сертификацию — см. каталог сертификатов
- Мощность контрактно расширяемая: DR-объект, который невозможно масштабировать во время реальной аварии — это просто имитация
- Удалённое вмешательство (remote hands) с гарантированным временем отклика по контракту — при региональной аварии вы не сможете прилететь
- Переключение на резервный объект полностью протестировано перед запуском и затем ежегодно — план это не возможность
Часто задаваемые вопросы
На каком расстоянии друг от друга должны находиться основной дата-центр и DR-объект?
Достаточно далеко, чтобы не находиться в зоне одного аварийного события, достаточно близко для вашего режима репликации. Минимальные требования: отдельные энергосети, отдельные поймы и отдельные маршруты операторов связи — на практике 50 км и более. Синхронная репликация ограничена примерно 100 км (около 10 мс задержки в оба конца); асинхронная репликация ограничений по расстоянию не имеет. Многие регуляторы в Азиатско-Тихоокеанском регионе требуют DR вне страны, что вынуждает использовать асинхронную репликацию.
В чём разница между RPO и RTO?
RPO (целевая точка восстановления) — это объём данных, потеря которых вам допустима, и определяется режимом репликации. RTO (целевое время восстановления) — это время простоя, которое вам допустимо, и определяется паттерном DR: backup-restore восстанавливается за дни, active-active за секунды. Стоимость растёт с обоими параметрами: снижение любого на порядок примерно удваивает бюджет DR.
Может ли синхронная репликация работать между странами?
Только между соседними странами. Singapore–Kuala Lumpur при ~8 мс RTT это поддерживает; Frankfurt–Amsterdam при ~11 мс — пограничный случай. Свыше ~25 мс это уже территория асинхронной репликации независимо от того, что говорит даташит поставщика хранилища — каждая запись будет нести полную задержку в оба конца, и команда приложения почувствует это раньше, чем команда DR.
Что на самом деле приводит дата-центры к отказу?
В нашем журнале инцидентов доминируют события, связанные с питанием (перебои в подаче электроэнергии и отказы ИБП), пожары (литий-ионные батареи повторяют появляться), сбои систем охлаждения и отказы сетевого оборудования — но не региональные природные катастрофы. Практический вывод: DR-объект в одном городе на одной энергосети защищает почти ни от каких инцидентов, происходящих на уровне объекта, в то время как объект в другой стране защищает от почти всех них.
Может ли публичное облако служить DR-объектом для колокейшн-нагрузок?
Для паттернов backup-restore и pilot-light часто да — вы платите за резервную мощность только когда она работает, что соответствует облачной модели платежей. Подвох в расходах на исходящий трафик и операционном разрыве: восстановление инфраструктуры колокейшна в облако означает постоянное поддержание двух платформ развёртывания. Тестируйте полное восстановление, а не репликацию.
Как часто нужно тестировать DR?
Полное переключение на резервный объект как минимум ежегодно, восстановление компонентов ежеквартально и после каждого значимого изменения инфраструктуры. Непротестированный план DR — это документ, а не возможность, и журнал инцидентов показывает, что отказы сосредоточены именно в механизмах (переключение питания, перезапуск охлаждения), которые проверяет только реальный тест.
Подбираете объект для DR?
Укажите основной объект, нужный вам RPO и требуемый режим соответствия. Мы вернёмся с объектами в жизнеспособных DR-рынках, эталонными ценами и вопросами, которые стоит задать каждому оператору.