Стратегії бекапів та реплікації

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

Надійна стратегія даних стоїть на трьох опорах: бекап, реплікація, відновлення. Репліка знижує 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 - тільки зміни з минулого бекапа.
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 і перевірка відновлення «по факту». Поєднуйте реплікацію для аптайма і швидких фейловерів з бекапами для логічних помилок і компрометацій. Автоматизуйте, вимірюйте, документуйте - і у вас завжди буде робочий шлях назад, навіть в самий нехороший день.