Бэкапы и 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) Каталогизация и контроль версий бэкапов

Каталог (каталогизация метаданных): что, где, когда, чем сделано, хэши, ключ KMS, владелец, срок хранения.
Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.
«Золотые» контрольные точки (Gold): перед миграциями/DDL/масштабными релизами.

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) Примеры (сниппеты)

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"

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

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

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, отделяйте репликацию от бэкапов, шифруйте и изолируйте ключи, документируйте и проверяйте. Тогда даже «черный лебедь» превратится в управляемый процесс с предсказуемым временем простоя и минимальной потерей данных.