Стратегии бэкапов и репликации

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

Надежная стратегия данных стоит на трех опорах: бэкап, репликация, восстановление. Реплика снижает RTO (время восстановления), бэкап гарантирует RPO (потерю данных) и защищает от логических ошибок/шифровальщиков. Базовые принципы: 3-2-1-1-0 (3 копии, 2 типа носителей, 1 — оффсайт, 1 — неизменяема, 0 ошибок в проверках), регулярные тесты DR и иммутабельность критичных наборов.

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

RPO — сколько данных допустимо потерять (например, ≤ 5 минут).
RTO — сколько времени допустимо восстанавливать (например, ≤ 15 минут).
PITR (Point-in-Time Recovery) — восстановление «на момент X» с реплеем журналов.
SLO данных — контракт уровня сервиса для RPO/RTO и успеха задач бэкапа.

Пример матрицы:

Класс данных	RPO	RTO	Примечания
Транзакции/кошелек	≤ 1–5 мин	≤ 5–15 мин	Журналы + синхронная реплика ядра
Отчетность/PII	≤ 1 ч	≤ 1 ч	WORM/immutability, архивы
Логи/сырые события	≤ 24 ч	≤ 4 ч	Объектка, lifecycle

Модели отказоустойчивости и репликации

Варианты топологий

Active-Passive (горячий/теплый/холодный): проще, предсказуемые фейловеры.
Active-Active: высокая доступность, но сложнее конфликт-резолв и консистентность.
Multi-Zone/Region/Cloud: баланс задержек и стоимости egress.

Синхрон vs асинхрон

Синхрон: RPO≈0, выше latency, ограничение расстояния.
Асинхрон: близок к нулю RTO при малом RPO (минуты), выдерживает регионы/облака.
Гибрид: синхрон в пределах зоны, асинхрон — в удаленный регион.

Реплика ≠ бэкап

Реплика уносит ошибки/удаления вслед за источником. Бэкап — off-path копия с версионированием, проверками и изоляцией.

Политика 3-2-1-1-0 и иммутабельность

3 копии (прод + локальная резервная + оффсайт).
2 типа носителей (блок/NAS/объектка/ленты).
1 оффсайт (другая площадка/облако/лента).
1 неизменяемая копия (WORM: Object Lock, immutable snapshots/лента).
0 ошибок: регулярная проверка интегритета (checksum/verify/restore-тесты).

Практика:

Включайте версионирование и Object Lock (Compliance/Governance) для объектки с критичными бэкапами.
Для NAS/блоков — immutable snapshots с ретеншном и запретом удаления до срока.

Типы бэкапов и расписания

Full — полная копия.
Incremental — только изменения c прошлого бэкапа.
Differential — изменения со времени последнего полного.
Forever-incremental с GFS-планом (Grandfather-Father-Son): дневные инкременты, еженедельные и ежемесячные «синтетические полные».

Рекомендация (пример):

Prod БД: ежедневный full (или синтетический full), инкременты/журналы каждые 5–15 минут (PITR).
Файловые сервера: еженедельный full, ежедневные incremental, месячные архивы.
Объектка: lifecycle + версии; холод — в архивный класс хранения/ленту.

Приложения и БД: практики PITR

PostgreSQL

Включить WAL архивирование и base backup; PITR через `restore_command`.
Инструменты: `pgBackRest`, `wal-g` (объектка), `pg_basebackup` для полных.
Разделять тома: данные и WAL; писать WAL на быстрый NVMe с PLP.

MySQL/MariaDB

Binary log для PITR, полные через `Percona XtraBackup` (hot backup).
Репликация GTID; для DR — асинхрон в регион/облако.

MongoDB

Oplog для PITR; снапшоты на уровне стораджа + `mongodump` для логических копий.
Тестировать консистентность реплики перед бэкапом.

Redis/Кэши

Не считать бэкапом: держать RDB/AOF + offsite; восстанавливать как warm-cache или из источника правды.

Kubernetes и контейнеры

etcd кластера — отдельная критичная цель (частые снапшоты, оффсайт).
Velero: бэкап манифестов/ресурсов + CSI-снапшоты/PV; хранение в S3-совместимом бакете (с Object Lock).
Stateful-награрузки: app-consistent снапшоты (pre/post hooks), иначе — crash-consistent.
Версионирование объектных артефактов (модели/медиа) — на уровне бакетов.

Виртуализация и файловые сервера

VM-снапшоты: использовать CBT (Changed Block Tracking), хранить offsite, периодически делать guest-aware quiesce (VSS для Windows).
Файловые сервера (NAS): снапшоты + реплика и регулярные каталожные restore-тесты (выборка файлов).

Безопасность бэкапов

Шифрование в покое (LUKS/ZFS/облачные KMS/Vault) и при передаче (TLS/mTLS).
Управление ключами: отдельные роли, dual-control, ротация, оффлайн-хранение мастер-ключей.
Изоляция: учетные записи бэкап-софта без прав на удаление иммутабельных копий; отдельные сети/VLAN.
Ransomware-устойчивость: immutable, air-gap (ленты/изолированный аккаунт/лаб).
Аудит: журнал операций бэкап-системы, оповещения об удалении/сокращении ретеншна.

Планирование окон и пропускной способности

Backup window vs нагрузка: троттлинг I/O/сети, дедупликация, компрессия.
Сеть: инкременты каждые N минут, отдельные каналы/VPN, реплика ночью или постоянно с QoS.
Change Block Tracking/CDC для снижения трафика.
Большие базы: параллельные потоки/стриминг, многоканальный multipart в объектку.

Мониторинг, метрики и SLO

Тех-метрики:

Успешность задач бэкапа/репликации (%), длительность, скорость, лаг журналов (WAL/binlog/oplog).
Пространство хранилища бэкапов, дедуп-коэффициент, прочие расходы.
Время и успех тестовых восстановлений.

SLO (пример):

Успешность бэкапов ≥ 99.9%/30 дней.
RPO соблюден ≥ 99% времени (лаг журналов ≤ целевого).
RTO (тест-restore) ≤ 15 мин для кошелька, ≤ 1 ч для отчетности.
Ежемесячный DR-drill: 100% регламентных сценариев завершены.

Алерты:

Пропущенный/неуспешный бэкап, лаг PITR > порога, падение степени дедупликации, нехватка места, изменение ретеншн-политики, отсутствие свежих тест-restore.

Учения DR и проверка восстановлений

Табличные (table-top): координация ролей, контакты, коммуникации.
Технические: восстановление «в песочницу», измерение RTO, сравнение контрольных сумм/данных.
Black-start: полное восстановление на «голое железо/чистый кластер».
Каталоги данных: заранее описанные шаги восстановления (runbooks) по каждому классу систем.
Автоматика: периодический «канареечный» restore и сверка контрольных сумм.

Практические шаблоны

1) PostgreSQL (pgBackRest + WAL-архив в объектку)

ini
[global]
repo1-type=s3 repo1-path=/pgbackups repo1-s3-endpoint=minio. local:9000 repo1-s3-bucket=pg-wal repo1-s3-key=ACCESSKEY repo1-s3-key-secret=SECRET repo1-retention-full=8 start-fast=y compress-type=zst

2) wal-g (пример ENV)

bash export WALG_S3_PREFIX=s3://pg-wal/prod export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export WALG_COMPRESSION_METHOD=zstd

3) Velero (K8s — объектка + иммутабельность бакета)

yaml apiVersion: velero. io/v1 kind: BackupStorageLocation metadata: { name: default, namespace: velero }
spec:
provider: aws objectStorage:
bucket: k8s-backups config:
s3Url: https://minio. example s3ForcePathStyle: "true"
publicUrl: https://minio. example

4) Политика Object Lock (пример `mc`)

bash mc version enable my/backups mc retention set --default COMPLIANCE 365d my/backups

5) Пример GFS-расписания (концепт)

Daily: инкременты каждые 15 мин (журналы), дневной синтетический full.
Weekly: один «полный» (синтетический), хранить 8 недель.
Monthly: полный, хранить 12–24 месяца (архив/лента).

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

Определены классы данных, владельцы, RPO/RTO/SLO.
Выбраны модели репликации (sync/async) и топологии (AZ/Region/Cloud).
Настроены бэкапы: full/incremental/PITR, расписания, каталоги.
Включены иммутабельность (WORM/Object Lock/immutable snapshots) и оффсайт/air-gap.
Шифрование и KMS/Vault, раздельные роли и ротации ключей.
Мониторинг: успех задач, лаг журналов, место, тест-restore; алерты.
Runbooks восстановления и фейловера; контакты, эскалации, шаблоны коммуникаций.
Ежемесячные DR-учения + отчет, корректировка планов.
Бюджет и FinOps: стоимость хранения/egress, проект архивации/тиринга.

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

«Реплика есть — бэкап не нужен»: логические удаления и шифровальщики уедут на реплику.
Нет тестов восстановления — бэкап существует «теоретически».
Отсутствие иммутабельности и оффсайта — единая точка риска.
Один и тот же аккаунт/ключи для прод и бэкапов — компрометация = потеря всего.
Слишком длительные окна бэкапа → конфликт с пиками; нет троттлинга и QoS.
PITR без контроля лага журналов.
Игнор app-consistent снапшотов — «грязные» восстанавливаемые тома.

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

Кошелек/платежное ядро: RPO ≤ 1–5 мин, RTO ≤ 15 мин; журналы (WAL/binlog) в объектку с WORM; синхрон в зоне + асинхрон регион.
Отчетность/регуляторика: неизменяемые хранилища, длительный ретеншн (годы), проверяемая целостность, четкие процедуры выдачи данных регуляторам.
Логи/сырые события/антифрод: дешевое долгоживущее хранилище (объектка) + lifecycle; индексы и витрины — отдельно.
Пики (матчи/турниры): окна бэкапа вне пиков, throttling; DR-планы на период событий; канареечные restore перед акциями.

Итог

Защита данных — это архитектурная дисциплина: 3-2-1-1-0, версионирование и иммутабельность, RPO/RTO как SLO, регулярные учения DR и проверка восстановления «по факту». Совмещайте репликацию для аптайма и быстрых фейловеров с бэкапами для логических ошибок и компрометаций. Автоматизируйте, измеряйте, документируйте — и у вас всегда будет рабочий путь назад, даже в самый нехороший день.