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 - і у вас завжди буде контрольований шлях до відновлення навіть після найгіршого сценарію.