Disaster Recovery: backup, restore, RPO, RTO и регулярные учения
↑ Этап 8 · Senior: надёжность, безопасность, платформа
Зачем это на собесе
Общесистемный DR (не только БД): стратегии, RPO/RTO, учения. Связан с HA и бэкапами, но отвечает за потерю площадки и массовые сбои.
Цели и метрики
| Метрика | Вопрос | Определяет |
|---|---|---|
| RPO | сколько данных (по времени) можно потерять | частоту бэкапов/репликации |
| RTO | за какое время нужно восстановить сервис | уровень готовности резерва |
| MTD/MAO | максимально допустимое время простоя бизнеса | верхняя граница RTO |
| RLO | какой уровень функциональности сначала | приоритеты восстановления |
Задаются бизнесом (BIA — Business Impact Analysis: стоимость часа простоя, регуляторные требования), затем фиксируются в DR-плане для каждого сервиса (тиры: Tier 0 — платёжный шлюз/авторизация, Tier 1 — ключевые сервисы, Tier 2 — второстепенные).
Сценарии катастроф
Отказ зоны/региона/провайдера, потеря ЦОД, массовое повреждение данных (баг, ошибка оператора, terraform destroy), шифровальщик/компрометация (в т.ч. бэкапов и учётных записей), отказ ключей/секретов/IdP/DNS, потеря облачного аккаунта, сбой цепочки поставок, стихийные бедствия, потеря персонала.
HA ≠ DR ≠ бэкап: HA — автоматическое переживание отказа компонентов; DR — восстановление после потери площадки; бэкап — возврат к прошлому состоянию (логические ошибки/атаки). Нужны все три.
Стратегии DR (по стоимости и скорости)
| Стратегия | Описание | RPO | RTO | Стоимость |
|---|---|---|---|---|
| Backup & Restore | бэкапы в другом регионе; при катастрофе развернуть инфраструктуру и восстановить данные | часы | часы–сутки | низкая |
| Pilot Light | минимальное ядро в DR-регионе (БД реплицируется, остальное выключено/в IaC); при катастрофе поднять остальное | минуты | десятки минут–часы | средняя |
| Warm Standby | уменьшенная работающая копия; при катастрофе масштабировать и переключить трафик | секунды–минуты | минуты | выше |
| Hot / Multi-site Active-Active | полноценные активные регионы | ~0 | ~0 (секунды–минуты) | максимальная |
Выбор по RPO/RTO и бюджету; разные тиры — разные стратегии.
Компоненты плана
- Данные: бэкапы БД с PITR, снапшоты дисков, репликация объектных хранилищ (cross-region), неизменяемые (immutable/WORM) копии и в отдельном аккаунте/регионе/у другого провайдера, правило 3-2-1-1-0 (3 копии, 2 носителя, 1 вне площадки, 1 immutable/offline, 0 ошибок при проверке восстановления).
- Инфраструктура как код: Terraform/Ansible/GitOps позволяют воссоздать окружение в другом регионе по коду; образы и артефакты доступны в DR (реплика реестра образов, зеркала пакетов).
- Секреты и ключи: резервирование Vault/KMS (мульти-регион ключи, бэкап Raft), доступ к секретам в DR; «break-glass» учётные записи.
- Идентичность и сеть: IdP (Keycloak/SSO) в DR, DNS (резервные зоны/провайдер, низкий TTL), сертификаты, BGP/VPN, внешние зависимости (платёжные, почтовые).
- Приложения: совместимость версий, конфигурации окружения DR, лицензии, лимиты/квоты в DR-регионе (заранее поднять квоты облака!).
- Трафик: GSLB/DNS failover, health checks, runbook переключения; failback (возврат) продуман отдельно (часто сложнее).
- Наблюдаемость: мониторинг в DR и независимый от основного региона (иначе «слепота»), алерты на состояние репликации/бэкапов.
- Коммуникации и люди: роли, кто объявляет катастрофу (критерии), контакты, резервные каналы связи, статус-страница вне основной инфраструктуры, клиенты, регуляторы.
- Документация: DR-runbook вне основной инфраструктуры (печатная/офлайн копия), актуальный, пошаговый, с проверенными командами и ответственными.
Runbook переключения (пример структуры)
0. Решение: критерии объявления катастрофы; кто принимает (IC + CTO); время решения.
1. Заморозить изменения; остановить запись в основной регион (если доступен).
2. Проверить состояние репликации/бэкапов DR: последний LSN/время (фактический RPO).
3. Поднять/масштабировать инфраструктуру DR (terraform apply / GitOps sync), проверить квоты.
4. Промоутить БД DR (Patroni standby leader / PITR restore).
5. Подключить секреты/ключи/IdP; проверить сертификаты.
6. Запустить приложения, миграции НЕ запускать без необходимости; smoke-тесты.
7. Переключить трафик (DNS/GSLB), TTL, проверить с внешних точек.
8. Мониторинг, коммуникации (внутренние/внешние), фиксация времени (фактический RTO).
9. Стабилизация; план failback; постмортем.Тестирование DR — обязательно
Непроверенный DR-план не работает.
| Уровень | Что | Частота |
|---|---|---|
| Автоматическая проверка бэкапов | восстановление в песочницу + контрольные запросы | ежедневно/еженедельно |
| Tabletop | разбор сценария за столом по runbook | раз в квартал |
| Тест восстановления | полное восстановление сервиса в изолированной среде, замер RTO/RPO | раз в квартал/полугодие |
| Failover-учение | реальное переключение (staging/prod в окно) | раз в год и после значимых изменений |
| Game day / chaos | отказ зоны/региона/зависимостей | регулярно |
| Red team / ransomware-сценарий | потеря основной учётки и бэкапов | раз в год |
Фиксировать фактические RPO/RTO, найденные проблемы (просроченные сертификаты, недоступные секреты, отсутствующие квоты, устаревший runbook), задачи на исправление; повторять после изменений архитектуры.
Защита от шифровальщиков и злонамеренных действий
- Immutable backups (Object Lock compliance mode, WORM), отдельные учётные записи и ключи для бэкапов (не доступные из продакшн-аккаунтов), MFA delete, air-gap/offline копия;
- сегментация и минимальные права; защита CI/IaC (
destroyтребует подтверждения,prevent_destroy); - обнаружение аномалий (массовые изменения/удаления), задержка удаления (soft delete/versioning);
- чистая комната/верификация восстановленных данных до ввода (могут быть заражены); план очистки ОС/образов;
- процедуры IR и взаимодействие с безопасностью и юристами.
Особенности Kubernetes
- GitOps + IaC = воссоздание кластера; данные приложений: Velero (ресурсы + PV снапшоты), CSI-снапшоты, бэкапы БД операторов, репликация объектных хранилищ;
- etcd-бэкапы для self-managed; восстановление namespaces/CRD/секретов; порядок (CRD → операторы → приложения → данные);
- образы и Helm-чарты доступны в DR; DNS/Ingress/сертификаты (cert-manager в DR-кластере); внешние зависимости.
Организация и процессы
- владелец DR на сервис; DR-план — часть релизной готовности;
- интеграция в изменения: новый сервис → тир, RPO/RTO, бэкап, DR-runbook;
- метрики: фактические RPO/RTO vs цели, успех тестов, возраст последнего успешного теста, покрытие бэкапами;
- соответствие: ISO 22301, PCI DSS, требования регуляторов (ЦБ), аудит;
- стоимость: DR-инфраструктура (горячая/тёплая) — инвестиция по BIA; оптимизация (scale-to-zero резерв, IaC);
- культура: регулярность, открытость ошибок, улучшения.
Вопросы с ответами
Чем Pilot Light отличается от Warm Standby?
Pilot Light — минимальное ядро (обычно реплика БД), остальное поднимается при катастрофе; Warm Standby — работающая уменьшенная копия всей системы, которую нужно лишь масштабировать и переключить (быстрее, дороже).
Почему репликации недостаточно для DR?
Она мгновенно копирует и логические ошибки и повреждения (удаление, шифровальщик). Нужны бэкапы с PITR, неизменяемые копии в другом аккаунте/регионе и проверка восстановления.
Как убедиться, что DR-план рабочий?
Регулярно тестировать: автоматические проверки восстановления, tabletop, полные восстановления и failover-учения с замером фактических RPO/RTO, исправлять найденные проблемы и обновлять runbook.