Disaster Recovery: как не остаться без данных¶
В главе «Про RTO и RPO» мы разбирали метрики восстановления: за какое время нужно поднять сервис и сколько данных допустимо потерять. Эта глава — про практику: как именно реализовать Disaster Recovery (DR) так, чтобы в реальной аварии план работал, а не остался красивым документом в Confluence.
Что такое Disaster Recovery¶
Disaster Recovery — это комплекс мер, который позволяет компании продолжать работу после катастрофического события: - Дата-центр полностью недоступен - Удалены критичные данные (ransomware, ошибка оператора) - Регион облака лёг - Потерян ключ шифрования - Санкции, отзыв лицензий, геополитика
DR отличается от обычной надёжности (high availability): HA защищает от локальных сбоев, DR — от катастроф, которые ломают весь сайт или регион.
Уровни DR¶
В индустрии принято выделять несколько уровней Disaster Recovery. Чем выше уровень, тем меньше downtime и потерь, но тем дороже.
Tier 0: No DR¶
Описание: бэкапов нет или они не тестируются. Сервис упал — данные потеряны.
Downtime: дни-недели (если восстановим вообще) Data loss: всё
Когда допустимо: пет-проекты, прототипы, MVP. Не для прода.
Tier 1: Backup & Restore (Cold DR)¶
Описание: регулярные бэкапы на отдельную площадку (другой регион, другой провайдер, on-premises). Восстановление вручную при катастрофе.
Downtime: часы-дни (пока развернём из бэкапа) Data loss: с последнего успешного бэкапа (часы)
Когда использовать: некритичные данные, аналитика, логи.
Стоимость: низкая. Платите только за хранение бэкапов.
Tier 2: Pilot Light (Warm DR)¶
Описание: в резервном регионе работают минимальные ресурсы (БД, конфигурация), но не приложения. При аварии — поднимаем compute-слой.
Downtime: десятки минут-часы Data loss: минуты (репликация БД)
Когда использовать: средний приоритет, RTO порядка часа.
Стоимость: умеренная. Платите за хранение + маленький standby-стенд.
Tier 3: Warm Standby¶
Описание: в резервном регионе работает уменьшенная копия прода (например, 30% мощности). При аварии — увеличиваем capacity.
Downtime: минуты Data loss: секунды-минуты
Когда использовать: бизнес-критичные сервисы с RTO < 1 часа.
Стоимость: высокая. Платите за полный standby с заниженной мощностью.
Tier 4: Active-Active (Hot DR)¶
Описание: оба региона работают параллельно и обслуживают трафик. При аварии одного региона второй забирает всю нагрузку.
Downtime: секунды (DNS failover или балансировщик) Data loss: секунды (синхронная репликация)
Когда использовать: миссия-критичные системы, финансы, телеметрия.
Стоимость: очень высокая. Платите за двойную инфраструктуру + сложность синхронизации данных.
Tier 5: Multi-Cloud Active-Active¶
Описание: активная работа в нескольких облачных провайдерах. Самый дорогой и сложный уровень.
Когда использовать: требования регуляторов (ЦБ, ФСТЭК), compliance, защита от vendor lock-in.
Стратегии бэкапов¶
Правило 3-2-1¶
Классика DR: - 3 копии данных (оригинал + 2 бэкапа) - 2 разных типа носителя (например, диск + лента, или два облака) - 1 копия off-site (другой физический регион)
В облачную эпоху это трансформируется: - 3 копии: production DB + cross-region replica + snapshot в S3 - 2 типа: block storage + object storage - 1 off-site: в другом регионе или у другого провайдера
Типы бэкапов¶
| Тип | Что копирует | Размер | Время восстановления | Когда использовать |
|---|---|---|---|---|
| Full | Всё | Большой | Быстро | Раз в неделю/месяц |
| Incremental | Только изменения с последнего бэкапа (любого типа) | Маленький | Медленно (нужна цепочка) | Каждый час/день |
| Differential | Изменения с последнего full | Средний | Быстрее incremental | Каждый день |
| Snapshot | Состояние на момент времени (для БД — через copy-on-write) | Зависит от изменений | Быстро | Для БД каждые 5-15 минут |
| Continuous (WAL archiving) | Транзакционный лог | Маленький | Зависит от объёма | Point-in-time recovery |
Snapshot — для баз данных¶
Большинство современных БД (PostgreSQL, MySQL, MongoDB) умеют consistency snapshots:
# PostgreSQL через pg_basebackup
pg_basebackup -D /backup/postgres -Ft -z -P
# Или через облачный API (AWS RDS, Yandex Managed PostgreSQL)
aws rds create-db-snapshot \
--db-instance-identifier production \
--db-snapshot-identifier prod-snapshot-$(date +%Y%m%d)
WAL archiving для PostgreSQL¶
Для point-in-time recovery (PITR) нужны WAL-сегменты (транзакционный лог):
wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://my-backups/wal/%f'
Восстановление до любого момента:
pg_restore --target-time="2026-07-23 14:30:00"
Инкрементальные бэкапы для volumes¶
Для Kubernetes volumes и блочных хранилищ:
- Velero — бэкап кластера целиком (PV, secrets, deployments)
- Stash (от AppsCode) — инкрементальные бэкапы для stateful workloads
- AWS EBS Snapshots — для EC2 и EKS
- Yandex Disk Snapshots — для YC Managed Kubernetes
Тестирование восстановления¶
Это самая важная часть DR. Бэкапы, которые никто не проверял — это бэкапы, которые не работают.
Виды тестов¶
1. Tabletop exercise (на бумаге). Собирается команда, обсуждается сценарий: «дата-центр недоступен, что делаем?». Не трогаем реальную инфраструктуру.
2. Walkthrough (пошагово). Прогоняем процедуру восстановления по документу, проверяем что шаги актуальны.
3. Simulation (в изоляции). Разворачиваем копию в test-окружении, восстанавливаем из бэкапа, проверяем что всё поднялось.
4. Partial failover (частичное переключение). Переключаем один сервис в резервный регион, проверяем работу.
5. Full DR test (GameDay). Полная симуляция аварии. Один регион «мёртв», второй должен обслуживать всю нагрузку.
Что тестировать¶
- Время восстановления (RTO). Реально ли мы укладываемся в заявленные часы?
- Полнота данных (RPO). Все ли данные восстановились? Нет ли пропусков в транзакциях?
- Конфигурация. Правильные ли параметры в восстановленной системе (secrets, URLs, DNS)?
- Зависимости. Все ли внешние сервисы доступны из резервного региона?
- Люди. Знает ли команда процедуру? Может ли выполнить её в 3 часа ночи?
Регулярность¶
| Тип теста | Частота |
|---|---|
| Tabletop | Ежемесячно |
| Simulation в test | Еженедельно (для критичных) |
| Partial failover | Ежеквартально |
| Full DR test (GameDay) | Раз в год (для критичных) |
Главное правило: непроверенный бэкап — это отсутствие бэкапа. Регулярное восстановление в test-окружении — обязательное условие.
Репликация и стратегии синхронизации¶
Синхронная репликация¶
Запись считается успешной только когда подтверждение получено от всех реплик.
Плюсы: RPO = 0, никакой потери данных. Минусы: latency растёт с расстоянием. Невозможно между континентами (timeout). Когда: primary + standby в одном регионе.
Асинхронная репликация¶
Запись подтверждается сразу на primary, реплики догоняют в фоне.
Плюсы: нет overhead на latency. Минусы: при аварии primary теряются данные, которые не успели реплицироваться. Когда: primary в одном регионе, standby в другом.
Semi-sync¶
Компромисс: ждём подтверждения хотя бы от одной standby.
Active-Active и конфликты¶
Если оба региона принимают записи, могут возникнуть конфликты: - Один и тот же пользователь редактирует запись в обоих регионах - ID-генерация даёт дубли
Решения: - CRDT (Conflict-free Replicated Data Types) — структуры данных, которые умеют автоматически мержить - Last-write-wins — последняя запись побеждает (потеря данных) - Vector clocks — отслеживание причинности - Single-writer routing — каждый пользователь/объект привязан к одному региону для записей
Runbook для DR¶
У вас должен быть документ, по которому команда может выполнить восстановление. Структура:
DR-Runbook для production
1. Сценарий: потеря primary-региона
- Триггер: метрики показывают полную недоступность > 5 минут
- Решение принимает: Incident Commander
2. Переключение DNS
- Понизить TTL заранее (за день) до 60 секунд
- При аварии: изменить DNS на CNAME резервного региона
- Ответственный: @sre-oncall
3. Поднятие compute в резервном регионе
- Terraform: terraform apply -var-file=dr.tfvars
- Проверить: kubectl get nodes (должно быть ≥3)
- Ответственный: @platform-team
4. Подключение БД
- Standby уже принимает репликацию
- Promote в primary: pg_ctl promote
- Проверить: psql -c "SELECT pg_is_in_recovery()"
5. Smoke tests
- Health check всех критичных сервисов
- Synthetic transaction через API
- Ответственный: @qa-team
6. Переключение трафика
- Load balancer указывает на новый регион
- Мониторинг: алерты на error rate
7. Восстановление primary
- После возвращения региона — reverse failover
- Полная репликация в обе стороны перед возвратом
Когда НЕ нужен сложный DR¶
- Если вы теряете деньги от простоя меньше, чем стоит DR setup. Считайте ROI: Tier 4 для магазина цветов — overkill.
- Если SLA с клиентом не требует. Многие сервисы обходятся Tier 1-2.
- Если данные невозможно восстановить никак (например, одноразовые пароли пользователей). Тогда DR сводится к защите периметра, а не к восстановлению.
Резюме¶
Disaster Recovery — это не один продукт и не одна практика, а комплексная стратегия: - Определить уровень (Tier 1-5) по RTO/RPO и бюджету - Бэкапы по правилу 3-2-1, желательно с PITR - Регулярное тестирование восстановления в изолированном окружении - Задокументированный runbook с пошаговой процедурой - GameDay раз в год — полная симуляция
Самое важное: DR-план, который не тестировался, не работает. Большинство команд узнают об этом на реальной аварии, когда уже поздно.
См. также: «Про RTO и RPO», «Зачем нужны несколько дата-центров», «Культура blameless postmortem», «Chaos Engineering», «Runbooks и документация».