Disaster Recovery и cold-backups

Краткое резюме

DR — это способность восстановить функции бизнеса после крупной аварии. Cold-backups — «последняя линия обороны»: неизменяемые/изолированные копии, пригодные для восстановления при полном обесточивании площадки или компрометации. Стратегия строится вокруг RTO/RPO, приоритизации систем, ежегодных DR-учений и строгой операционной дисциплины (каталоги, ключи, проверки).

Термины и цели

RPO (Recovery Point Objective) — максимально допустимая потеря данных (напр., ≤ 15 мин).
RTO (Recovery Time Objective) — максимально допустимое время восстановления (напр., ≤ 2 ч).
Black-start — восстановление «с нуля»: железо/кластер/секреты/данные/DNS.
Air-gap — физическая/логическая изоляция копий (лента/отключенный аккаунт/офлайн-носитель).
Immutability (WORM) — неизменяемое хранение (лента/объектка с Lock/Retention).

Уровни DR-готовности

Cold Site — инфраструктура отсутствует/заморожена; RTO: часы–дни; самый дешевый CAPEX/OPEX.
Warm Site — шаблоны/образы/частично готовые сервисы; RTO: десятки минут–часы.
Hot Site — активные реплики; RTO: минуты; дороже и сложнее.
Гибрид: ядро → hot/warm, все остальное → cold (с приоритезацией при запуске).

Где cold-backups незаменимы

Массовое криптозаражение/компрометация домена.
Коррупция данных, уехавшая на все реплики.
Потеря региона/ЦОДа, форс-мажор (пожар, наводнение).
Умышленное удаление/саботаж с привилегированных учеток.

Топология cold-backups

1. Медиа/классы хранения

Ленты (LTO-8/9): дешевизна, air-gap по умолчанию, высокая емкость, последовательный доступ.
Offline-диски/NAS: «сейф-кейсы», подключаются только на окно бэкапа/restore.
Архивные классы объектки (Glacier-подобные): низкая цена хранения, более высокое время извлечения.

2. Размещение

Другая площадка/регион; иной провайдер/аккаунт; отдельные ключи/администраторы.

3. Иммутабельность

Ленты WORM / Object Lock (Compliance/Governance) с ретеншном и Legal Hold.

Политика 3-2-1-1-0 (с фокусом на cold)

3 копии данных (прод + локальная резервная + оффсайт).
2 разных носителя (диск/лента/объектка).
1 оффсайт (другая площадка/облако).
1 неизменяемая (WORM/air-gap).
0 ошибок проверок (checksum/периодические тест-восстановления).

Каталоги, метаданные и контроль целостности

Каталог бэкапов: что, где, когда, версия, ключи, чек-суммы, срок ретеншна.
Каталог активов: сервис → зависимости → тома/бакеты → приоритет.
Checksums и manifest-файлы: сверка на запись и на восстановлении.
Canary-файлы: регулярный restore для раннего детекта проблем носителей.

Шифрование и ключи

Шифрование в покое (лента/объектка) и в полете (копирование).
KMS/Vault с dual-control, оффлайн-сейфы для мастер-ключей, ротация.
Раздельные ключи для прод/бэкапов/архивов (минимизация blast-радиуса).
Документированный процесс доступа к ключам при DR (требования, роли, журнал).

План DR: приоритезация и последовательность

1. Идентификация и доступ: IdP (минимальная зона), Vault/KMS, сетевое ядро.

2. Данные и управляющие плоскости: etcd K8s, конфиги, секrets, реестры образов, артефакты деплоев.

3. Транзакционные БД/кошелек: журналы + последние full/incremental.

4. Платежные/интеграционные шлюзы: ключи, сертификаты, IP/DNS.

5. Веб/апи-фронты: канареечный запуск, статический контент из объектки.

6. Аналитика/отчетность: по завершении ядра.

1. Инфраструктура: сеть, DNS/Anycast, IAM ядра, базовые образы/кластер.

2. Секреты/сертификаты: восстановить Vault/KMS из cold-backup, раздать bootstrap-секреты.

3. Контрольная плоскость: etcd/Control Plane/регистры/репозитории.

4. Данные: развернуть БД из cold-backup + PITR из журналов (по RPO).

5. Приложения: запуск зависимостей по дереву, прогрев кэшей/CDN.

6. Тесты и валидация: health-пробы, консистентность, контрольные суммы.

7. Переключение трафика: DNS/маршрутизация/балансировщики (поэтапно/канареечно).

8. Пост-проверки: отсутствие утечек/долгов, логирование и акт DR.

Процедуры cold-restore (типовые)

Ленты: инвентарь, загрузка, параллельные стримы, map файлов → каталоги → таски на восстановление; учет времени поиска и перемотки.
Архив-классы: запрос на извлечение (minutes→hours), staging в горячее хранилище, восстановление по манифесту.
Offline-диски: подключение read-only, проверки checksum → копирование.
Практика: изолированная «песочница» для восстановления, затем перенос в прод-среду.

Коммуникации и орг.структура при DR

Роли: Incident Commander, Tech Lead (Infra), DB Lead, App Lead, Comms, Security.
Каналы: резервные (вне корпоративного домена), голос/чат, SecureDocs.
Шаблоны сообщений: клиентам/партнерам/регуляторам; частота апдейтов; единый «источник правды».
Единый журнал событий: таймлайн, решения, владельцы.

DNS, сети и трафик

Split-brain-защита: флаги «DR-режим» в конфигурации; feature-flags для ограниченного функционала.
DNS-стратегия: низкие TTL заранее, независимый провайдер DNS; поэтапная смена A/AAAA/CNAME, прогрев CDN.
Маршрутизация: Anycast/Geo, BGP-анонс с DR-сайта; ACL/файрволлы пересобираются из IaC.

SLO для DR

RPO соблюден ≥ 99% времени (лаг журналов/инкрементов в пределах цели).
RTO black-start (полный сценарий) ≤ целевого (например, 4 часа) на тестах раз в квартал.
Успех DR-учений — 100% критичных задач выполнены в окне.
Иммутабельность — доля бэкапов с Retention/Lock = 100%.
Проверки целостности — 100% по графику; отказ носителя → тикет на миграцию.

Тесты и учения

Table-top: сценарии, роли, чек-листы, контакт-лист.
Технические: выборочные восстановление БД/файлов/секретов в «песочницу» с проверкой контрольных сумм и консистентности.
Black-start-drill: раз/квартал (или раз/полгода) — полный запуск ядра в DR-сайте.
Post-mortem: факты, узкие места, план улучшений (SLO/процессы/автоматизация).

Автоматизация и артефакты

IaC: кластеры, сети, стеки — в коде; DR-ветки/параметры.
Runbooks: покомпонентно (Vault/KMS, etcd, БД, шлюзы, фронты).
DR-пакет: оффлайн-копия ключевых доков (контакты, схемы, пароли сейф-фраз), инструкции физдоступа.
Canary-restore: ежедневный небольшой restore и сверка checksum.
Теги/метки: «DR-critical», «Warm-only», «Cold-only» для сервисов/томов.

Чек-лист внедрения

• Классы данных и их RPO/RTO согласованы с бизнесом; приоритеты восстановления определены.
• Реализованы cold-backups: носители, иммутабельность (WORM/Object Lock), оффсайт/air-gap.
• Каталоги: активов, бэкапов, ключей; чек-суммы и контроль версий.
• Процедуры black-start: сети/DNS, IdP/Vault/KMS, контрольная плоскость, данные, апп-слой.
• Учения: table-top ежеквартально; канареечные restore ежедневно; black-start раз/квартал-полгода.
• Коммуникации и регуляторные шаблоны; отдельные каналы связи.
• SLO/метрики/алерты для DR; отчеты руководству.
• Договоренности с провайдерами (ленты/архив-классы/DNS/CDN), SLA подтверждены.
• Финансы: бюджет носителей/архива, логистика, замена носителей по срокам.

Типичные ошибки

«Есть реплика — бэкап не нужен» → логическая ошибка/шифровальщик уедут везде.
Нет иммутабельности/air-gap → единый вектор компрометации всех копий.
Отсутствие каталогов/чек-сумм → восстановили «что-то», но не то.
TTL DNS слишком велик → многодневная миграция трафика.
Ключи/KMS в том же домене/аккаунте → блокировка доступа при инциденте.
Учения только «на бумаге» → RTO/RPO не подтверждены.

Специфика для iGaming/финтех

Кошелек/платежное ядро: строгий RPO (≤ 1–5 мин) и RTO (≤ 15–60 мин); журналы в объектку с WORM; DR-функция «read-only баланс» для прозрачной коммуникации.
PSP/провайдеры контента: заранее согласованные DR-IP/домен, whitelists, сертификаты, HMAC/мTLS ключи — копии в DR-пакете.
Отчетность/регуляторы: шаблоны уведомлений, неизменяемые архивы, доказуемая целостность, журнал действий.
Пики и ивенты: DR-готовность проверяется до крупных турниров/акций; канареечные restore и прогрев CDN.

Мини-runbook-шаблоны

1. Инициализация DR-кластера, загрузка ключей unseal (dual-control).

2. Восстановление storage-бэкапа (cold-copy).

3. Проверка политик, выдача bootstrap-секретов для CI/CD/K8s.

1. Развернуть пустой инстанс, восстановить full из cold.

2. Подложить WAL-журналы (инкременты) до целевого момента.

3. Проверка консистентности, включить репликацию, открыть read-only, затем read-write.

1. Снизить TTL за 24–72 ч до плановых рисков (или держать низкий постоянно).

2. Переключение A/AAAA/CNAME по чек-листу, мониторинг ошибки/латентности.

3. Постепенный рост трафика (канарейка 5% → 25% → 100%).

Итог

Надежный DR с опорой на cold-backups — это: иммутабельные изолированные копии, формализованные black-start-процедуры, четкие RPO/RTO, регулярные учения, продуманная DNS/сетевая стратегия и дисциплина ключей. Зафиксируйте все в IaC и runbook-ах, автоматизируйте проверки целостности и канареечные restore — и у вас всегда будет контролируемый путь к восстановлению даже после наихудшего сценария.