Настройка Disaster Recovery плана для инфраструктуры

Большинство компаний вспоминают о Disaster Recovery после первого серьёзного инцидента. Падение ЦОД, удалённая по ошибке production-база, компрометация облачного аккаунта с удалением всех ресурсов — в этот момент обнаруживается, что бэкапы есть, но никто не знает, как их восстанавливать, а время восстановления оказывается в 10 раз больше допустимого. Мы помогаем предотвратить такие сценарии, разрабатывая DR-планы, которые гарантированно сработают в нерабочее время.

DR-план — это не документ ради документа. Это набор проверенных технических процедур с конкретными RTO и RPO, которые работают в 3 часа ночи без автора плана. Наша команда имеет 10+ лет опыта в разработке планов аварийного восстановления для компаний различного масштаба — от стартапов до enterprise с compliance-требованиями.

Как выбрать RTO и RPO для ваших сервисов?

Инвентаризация критических компонентов. Для каждого сервиса определяем: где данные, как бэкапятся, каков допустимый простой (RTO) и максимальная потеря данных (RPO). Типичная матрица:

Документация по восстановлению каждого компонента. Не «восстановить БД из бэкапа», а пошаговая инструкция с конкретными командами. Каждый шаг должен уметь выполнить дежурный инженер без доступа к автору плана и без времени на раздумья.

Технические процедуры: самая ценная часть

Для каждого компонента в DR-плане описываем три сценария: частичный сбой (одна нода), полный сбой (потеря всей площадки), компрометация (злоумышленник удалил данные).

Пример процедуры восстановления PostgreSQL из pg_basebackup:

# 1. Остановить сервис, подключённый к БД
systemctl stop app-service

# 2. Очистить data directory
rm -rf /var/lib/postgresql/15/main/*

# 3. Восстановить из последнего бэкапа
aws s3 cp s3://backups-prod/postgresql/basebackup-latest.tar.gz /tmp/
tar xzf /tmp/basebackup-latest.tar.gz -C /var/lib/postgresql/15/main/

# 4. Настроить recovery target
cat > /var/lib/postgresql/15/main/postgresql.auto.conf << EOF
restore_command = 'aws s3 cp s3://backups-prod/postgresql/wal/%f %p'
recovery_target_time = '2023-01-15 10:00:00'
recovery_target_action = 'promote'
EOF
touch /var/lib/postgresql/15/main/recovery.signal

# 5. Запустить PostgreSQL и проверить recovery
systemctl start postgresql
tail -f /var/log/postgresql/postgresql-15-main.log

Такой уровень детализации — единственный приемлемый для production DR-плана. Восстановление из streaming replication быстрее, чем из полного бэкапа, в 10 раз — это разница между минутным простоем и часом.

Цепочки зависимостей. Приложение не запустится без БД. БД не запустится без правильного network routing. Routing не работает без DNS. В плане явно документируем порядок восстановления: сначала инфраструктура (VPC, security groups), потом базы данных, потом stateful сервисы, потом stateless приложения, потом DNS и load balancer.

Почему тестирование DR-плана критично?

Тестирование выявляет скрытые проблемы: устаревшие скрипты, изменившиеся версии ПО, недоступные бэкапы. Мы проводим тесты в изолированной среде, имитируя реальные сбои. Каждый тест завершается postmortem, а процедуры корректируются. Без регулярного тестирования план теряет актуальность уже через месяц.

Пример из практики: у клиента RPO было 1 час, но во время теста обнаружилось, что pg_dump выполняется 2 часа на продакшн-базе. Пришлось перейти на pg_basebackup с WAL-архивацией. Тест спас от потери данных.

Инфраструктурный код как часть DR

Вся инфраструктура должна быть описана в Terraform или Ansible — это само по себе часть DR-плана. terraform apply на чистом аккаунте должен поднять базовую инфраструктуру без ручных действий:

# Инициализация в аварийном регионе
terraform init -backend-config="bucket=tfstate-dr-backup" \
  -backend-config="region=eu-central-1"

# Проверка плана без применения
terraform plan -var-file=environments/production-dr.tfvars

# Применение
export TF_VAR_region="eu-central-1"
terraform apply -var-file=environments/production-dr.tfvars -auto-approve

Terraform state хранится в S3 с cross-region репликацией и версионированием. Потеря primary-региона не должна означать потерю state-файла.

Runbooks и эскалация

DR-план включает runbooks — краткие сценарные инструкции для конкретных типов сбоев. Структура каждого runbook: триггер (что произошло), диагностика (как убедиться), шаги восстановления, проверка результата, кому докладывать.

Матрица эскалации: кто первый дежурный, кто second-on-call, кто принимает решение о переключении на резервную площадку, кто уведомляет клиентов.

Как создать runbook за 5 шагов? — настройка disaster recovery

1. Определите типичные сценарии сбоев (отказ диска, сбой БД, ошибка развёртывания).
2. Опишите триггер — метрика или алерт, однозначно указывающий на сбой.
3. Запишите диагностические команды для подтверждения (например, pg_isready, curl health-check).
4. Пошагово опишите восстановление с конкретными командами и скриптами.
5. Укажите, как проверить успешность восстановления и кого уведомить.

Что входит в работу по разработке DR-плана?

• Аудит текущей инфраструктуры и выявление критических компонентов.
• Определение целевых RTO/RPO для каждого сервиса.
• Разработка технических процедур восстановления с проверкой на реальных системах.
• Создание runbooks для типовых сценариев сбоев.
• Тестирование DR-процедур в изолированной среде.
• Финализация документации и передача команде (доступы, обучение, поддержка).

Этапы работы

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Мы выполнили более 50 DR-проектов, и каждый план сопровождается гарантией актуальности на 6 месяцев.

Средняя стоимость восстановления после сбоя без DR-плана может достигать $1000 в минуту. Наши клиенты экономят до 80% затрат на восстановление благодаря заранее разработанным процедурам. Свяжитесь с нами для консультации — мы поможем подготовить инфраструктуру к любым сбоям. Получите демо-версию нашего подхода на вашем проекте.

Определение терминов Disaster Recovery и RTO/RPO дано в Wikipedia.