Налаштування 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 години на production-базі. Довелося перейти на 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.