Бекапи і disaster recovery

Бекапи і Disaster Recovery

1) Визначення та цілі

Бекап - узгоджена копія даних/конфігурацій для подальшого відновлення (від випадкових видалень, багів, криптолокерів, катастроф).
DR (Disaster Recovery) - процес відновлення інфраструктури/сервісів до робочих SLO після великої аварії (пожежа, втрата регіону, масова компрометація).
RPO (Recovery Point Objective) - максимально допустима втрата даних за часом (наприклад, 15 хвилин).
RTO (Recovery Time Objective) - цільовий час відновлення сервісу (наприклад, 30 хвилин).

Ключовий принцип: реплікація ≠ бекап. Реплікація швидко «розмазує» помилки і шифрування по всіх копіях. Бекап - ізольована, перевірена, потенційно незмінна копія.

2) Класифікація даних та рівні критичності

Розділіть активи на класи:

Tier-0 (життєво важливі): транзакційні БД, платежі, облік балансів, секрети/PKI.
Tier-1 (критичні): конфіги сервісів, черги, артефакти CI/CD, реєстри контейнерів.
Tier-2 (важливі): аналітика, звіти, вторинні індекси, лог-архіви.
Tier-3 (допоміжні): кеші, тимчасові дані (можна відновити реконструкцією).

Для кожного класу визначте RPO/RTO, термін зберігання, вимоги до незмінюваності та локації.

3) Стратегії зберігання: правило 3-2-1-1-0

3 копії даних (прод + 2 резервні).
2 різних типи носіїв/сховищ.
1 копія offsite (інший регіон/хмара).
1 immutable/air-gap (WORM/Object Lock/Tape).
0 помилок у перевірках відновлення (регулярні тести).

4) Типи бекапів

Full - повна копія. Повільно/дорого, але база для всіх стратегій.
Incremental - різниця з останнім будь-яким бекапом. Оптимально за обсягом.
Differential - різниця з останнім full. Швидше відновлення, більше місце.
Snapshot - моментальний зліпок тому/диска (EBS/ZFS/LVM). Потрібні app-consistent снапшоти (quiesce).
PITR (Point-in-Time Recovery) - базовий бекап + журнали (WAL/binlog) для відкату до точного часу/LSN.
Об'єктні/файлові/образні - під конкретні типи даних (VM-образи, S3-об'єкти, БД-дампи).

5) Узгодженість бекапів

Crash-consistent: як після раптового вимикання - підходить для stateless/журналируемых FS.
App-consistent: додаток «заморожує» операції (fsfreeze/pre-post scripts) → гарантована цілісність.
БД-консистентність: API бекап-інструменту (pgBackRest, XtraBackup), режими hot-backup, заморожування контрольних точок.

6) Шифрування, ключі та доступ

Шифрування at-rest і in-transit для всіх копій.
Ключі в KMS/HSM, ротація по політиці (90/180 днів), роздільні ключі по оточеннях.
Поділ обов'язків: хто створює/видаляє бекапи ≠ хто може їх розшифрувати/читати.
Не тримайте ключі дешифрування в тому ж домені довіри, що і цільові копії.

7) Незмінні копії та захист від ransomware

Object Lock/WORM (Compliance/Governance) з ретеншном і Legal Hold.
Air-gap: ізольоване/офлайн сховище (стрічка, офлайн-хмара/акаунт).
Політики видалення «з відкладеною активацією», MFA-Delete, окремий акаунт для backup-бакетів, заборона публічного доступу.
Верифікація на malware/індикатори компрометації перед монтуванням.

8) Частота, розклад і ретеншн

GFS (Grandfather-Father-Son): денні інкрементали, щотижневі full/diff, щомісячні full з тривалим зберіганням.
RPO диктує частоту інкременталів і WAL/binlog архівування (наприклад, кожні 5-15 хвилин).
Зберігання: критичні - ≥ 35-90 днів + щомісячні на 12-36 місяців (юридичні вимоги).
Сезонні піки - окремі контрольні точки (перед акціями/релізами).

9) DR-моделі та сценарії

Active-Active: обидва регіони обслуговують трафік. Мінімальний RTO, схлопування даних вимагає суворої політики конфліктів.
Active-Passive (гарячий/теплий): гарячий - розгорнутий і синхронізований (RTO хвилини), теплий - частково готовий (RTO годинник).
Cold: зберігаємо копії і Terraform/Ansible/образи, піднімаємо за запитом (RTO доба +).
DRaaS: провайдерська оркестрація VM/мереж/адрес в іншій зоні.

10) Оркестрація фейловера і пріоритети відновлення

Пріоритет запуску: мережа/VPN/DNS → секрети/KMS → бази/кластери → черги/кеш → додатки → периметр/CDN → аналітика.
Автоматизація: скрипти/Runbook-дії, Terraform/Ansible/Helm/ArgoCD профілі для DR-оточення.
Дані: DB PITR → reindex/replica → warm-кеш → запуск сервісів з прапорами сумісності схем.
DNS/GSLB: зниження TTL заздалегідь, сценарії перемикання з валідацією.

11) Тести відновлення (backup verification)

Restore-тести за розкладом: вибірка N% бекапів, розгортання в «пісочниці», автоматичні перевірки схем/інваріантів.
Повний DR-drill (game-day): відключення регіону/AZ, перевірка RTO/RPO на живому трафіку (або трафік-тіні).
Тести цілісності: хеш-каталоги, контрольні суми, спроба читання всіх шарів (full + chain).
Док-звіт: час, кроки, аномалії, розмір розриву від цілей, виправлення.

12) Практика для основних технологій

Бази даних

PostgreSQL: base backup + WAL архів (PITR), інструменти pgBackRest/Barman; слоти реплікації, контроль'lsn'.
MySQL/MariaDB: Percona XtraBackup/Enterprise Backup, binlog архівування.
MongoDB: 'mongodump'для логічної копії + snapshot для великих наборів; Oplog для PITR.
Redis: RDB/AOF для критичних (якщо Redis не тільки кеш), але частіше - логічна реконструкція з вихідника + snapshot для аварій.
Kafka/Pulsar: бекап метаданих (ZK/Kraft/BookKeeper), снапшоти дисків, дзеркалювання топіків/логів.

Kubernetes

etcd snapshot + Velero для ресурсів/томів (CSI snapshots).
Бекап секретів/PKI окремо (Vault snapshot).
Окремий реєстр образів: полісі зберігання артефактів (immutable tags).

ВМ і файлові системи

ZFS: 'zfs snapshot'+'zfs send | zstd | send-recv'інкрементами, перевірка'scrub'.
LVM/EBS снапшоти з pre/post скриптами (app-consistent).
Об'єктні сховища: версії + Object Lock.

13) Каталогізація і контроль версій бекапів

14) Спостережуваність і метрики

Успішність завдань: % успішних/завалених, причини.
Час бекапа/відновлення, ширина вікна.
RPO-фактичний: лаг архівів журналів (WAL/binlog) p95.
Цілісність: частка перевірених ланцюжків, помилки звірки хешів.
Вартість: обсяг зберігання за класами, коефіцієнт дедуплікації/стиснення.
DR-готовність: частота і результат навчань (pass/fail).

15) Політики доступу та комплаєнс

Роздільні облікові записи/проекти для бекап-сховищ; доступ за принципом NaC (не допускаємо видалення/шифрування з прод-обліків).
Логи доступу/змін (audit trail), алерти на масові видалення/зміни ретеншну.
Відповідність нормам: GDPR (право на видалення vs архіви), PCI DSS (шифрування, ключі, сегментація), локальні регулятори.

16) Анти-патерни

«Репліка є - значить бекап не потрібен».
Немає immutable/air-gap: одна помилка/шкідливість стирає все.
Бекапи в тому ж акаунті/регіоні, що і прод.
Ніколи не перевіряти відновлення (бекап «мертвий до перевірки»).
Немає каталогізації і контролю версій → хаос при аварії.
Загальні ключі шифрування для всіх оточень.
Снапшоти без app-consistent режиму для БД.
Вікно бекапа перетинається з піками (впливає на p99 і SLO).

17) Чек-лист впровадження (0-60 днів)

0-10 днів

Інвентаризація систем/даних, класи критичності.
Виставити цілі RPO/RTO по класах.
Увімкнути full + incremental для Tier-0/1, архів WAL/binlog.
Рознести бекапи: окремий регіон/аккаунт + включити шифрування KMS.

11-30 днів

Налаштувати immutable (Object Lock/WORM) для критичних копій.
Ввести каталогізацію, теги, звітність; алерти на провали і лаг журналів.
Перший DR-drill: відновити окремий сервіс з бекапа в ізольованому оточенні.

31-60 днів

Автоматизувати runbook: Terraform/Ansible/Helm профілі DR.
Регулярні restore-тести (тиждень/місяць) + квартальний full DR сценарій.
Оптимізувати вартість: дедуплікація/стиснення/життєві цикли зберігання.

18) Метрики зрілості

Restore-тести: ≥ 1/нед для Tier-0 (вибірково), ≥ 1/міс - повний сценарій.
Immutable coverage для Tier-0/1 = 100%.
RPO-фактичний p95 ≤ цільового (напр., ≤ 15 хв).
RTO-фактичний на DR-навчаннях ≤ цільового (напр., ≤ 30 хв).
Каталог-комплитність = 100% (кожен бекап описаний і перевірений).
Incident-to-restore: час від виявлення до запуску відновлення.

19) Приклади (сніпети)

PostgreSQL - політика PITR (ідея):

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

MySQL - інкрементальний цикл:

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

Kubernetes - Velero (ідеї маніфестів):

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

S3 Object Lock (приклад політики життєвого циклу):

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20) Комунікації та операційні ролі

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.
Шаблони повідомлень для стейкхолдерів/регуляторів/користувачів.
Post-mortem з діями: де втратили хвилини, де поліпшити автоматизацію.

21) Висновок

Надійний контур бекапів і DR - це не «зробити копію», а цикл: класифікація → цілі RPO/RTO → мульти-рівневі та immutable копії → автоматизовані runbook'і → регулярні відновлення та навчання. Дотримуйтесь 3-2-1-1-0, відокремлюйте реплікацію від бекапів, шифруйте та ізолюйте ключі, документуйте та перевіряйте. Тоді навіть «чорний лебідь» перетвориться на керований процес з передбачуваним часом простою і мінімальною втратою даних.

Бекапи і disaster recovery