Disaster Recovery (Аварійне відновлення та бекапи)(Стратегія аварійного відновлення та резервного копіювання)

1. Огляд концепції та системна проблема

В інфраструктурній інженерії апаратні збої SSD-накопичувачів, аварії в дата-центрах провайдерів, шифрувальники (Ransomware) та людські помилки (DROP DATABASE production, випадковий rm -rf) є не питанням «якщо», а питанням «коли».

Більшість команд перебувають в ілюзії безпеки: вони додають рядок у crontab для створення дампу раз на добу і вважають задачу вирішеною. Коли стається реальна катастрофа, з'ясовується:

• Останній бекап впав три місяці тому через переповнення диска.
• Дамп містить пошкоджені бінарні дані.
• Відновлення бази на 100 ГБ займає 36 годин, паралізуючи бізнес (неприйнятний RTO).
• Зловмисник, зламавши сервер, видалив бекапи разом із робочою базою, оскільки API-ключ S3 мав повні права на видалення (s3:DeleteObject).

Disaster Recovery (аварійне відновлення) — це комплексна стратегія безперервності бізнесу. Вона охоплює не просто збереження файлів, а математично розраховані цілі RTO/RPO, незмінні сховища (Immutable Storage) та автоматизовані регулярні навчання з розгортання інфраструктури з нуля.

2. Архітектурна таксономія та ментальна модель

Архітектурна матриця аварійного відновлення базується на компромісі між швидкістю та частотою фіксації стану:

┌─────────────────────────────────────────────────────────────┐
│                 DISASTER RECOVERY TAXONOMY                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Point-In-Time Recovery (PITR) ➔ RPO ~ секунди            │
│    • Стрімінг журналів WAL (Write-Ahead Log) у реальному часі│
│    • Інструменти: Litestream (для SQLite), pgBackRest (PG)  │
├─────────────────────────────────────────────────────────────┤
│ 2. Deduplicated & Encrypted Snapshots ➔ RPO ~ години        │
│    • Атомарні знімки даних через Restic, BorgBackup, Kopia  │
│    • Клієнтське шифрування AES-256 / ChaCha20               │
├─────────────────────────────────────────────────────────────┤
│ 3. Offsite Immutable Storage Tier (Anti-Ransomware)         │
│    • S3 Object Lock (WORM - Write Once, Read Many)          │
│    • Географічно ізольовані сховища (Cloudflare R2, AWS S3) │
├─────────────────────────────────────────────────────────────┤
│ 4. Cold Standby & Automated Recovery Drill (RTO валідація)  │
└─────────────────────────────────────────────────────────────┘

1. Відновлення на довільний момент часу (Point-In-Time Recovery - PITR):
   • Замість одного важкого дампу раз на добу база безперервно стрімить свій бінарний журнал змін (WAL) у хмару. Це дозволяє «відмотати» стан бази до секунди, що передувала збою або помилковому запиту розробника (RPO < 10 секунд).
2. Дедупліковані інкрементальні знімки (Content-Addressed Snapshots):
   • Утиліти на зразок Restic розбивають файли на криптографічні блоки. Якщо в 50-гігабайтній базі змінився лише 1%, завантажуються лише нові блоки, заощаджуючи до 95% дискового простору та мережевого трафіку.
3. Незмінне сховище (Immutable WORM Storage):
   • Політика безпеки S3 Object Lock, за якої ніхто (навіть адміністратор із root-доступом) не може видалити або перезаписати створений архів протягом заданого періоду (наприклад, 30 днів).
4. Тестові навчання відновлення (Recovery Drills):
   • Регулярний автоматичний процес у CI, який завантажує останній архів, розгортає його в ізольованому контейнері, запускає перевірочні SQL-запити та підтверджує цілісність даних.

3. Технічний пайплайн та внутрішня механіка

Життєвий цикл надійного резервного копіювання з дедуплікацією та шифруванням:

1. Консистентне заморожування стану (Snapshot Lock): База даних переводиться у режим підготовки до копіювання або створюється транзакційний знімок через механізми COW (Copy-on-Write) файлової системи ZFS/Btrfs.
2. Клієнтське шифрування на хості: Перед відправкою у мережу дані шифруються надійним алгоритмом (AES-256-GCM) за допомогою парольної фрази, відомої лише інженеру. Хостинг-провайдер S3 отримує виключно зашифрований бінарний шум.
3. Паралельне завантаження в ізольоване хмарне сховище: Блоки передаються через HTTPS на незалежний географічний регіон (наприклад, сервер у Німеччині бекапиться у сховище Cloudflare R2 у Швеції).
4. Застосування політики ротації (GFS Retention Policy): Алгоритм зберігає: останні 24 погодинні копії, 7 щоденних, 4 щотижневих та 12 щомісячних (Grandfather-Father-Son), автоматично видаляючи старі проміжні знімки.
5. Автоматична верифікація цілісності (Automated Integrity Check): Окрема задача у фоні раз на тиждень виконує команду restic check --read-data-subset=5%, виявляючи можливу деградацію бітів (Bit Rot) у сховищі.

4. Практичні інженерні сценарії в продакшені

01. Безперервна реплікація SQLite за допомогою Litestream

Для додатків на базі SQLite/Turso:

• Litestream працює як фоновий системний процес, перехоплюючи зміни у WAL-файлі.
• Кожні 10 секунд нові фрейми шифруються і вивантажуються у бакет Cloudflare R2.
• У разі повного згоряння сервера нова машина піднімається однією командою litestream restore -o /var/data/app.db, відновлюючи стан системи практично без втрати даних (RPO < 10 с, RTO < 60 с).

02. Захист від зловмисників через S3 Object Lock

Запобігання знищенню інфраструктури хакерами:

• Навіть якщо зловмисник отримує повний root-доступ до сервера і знаходить конфіг із ключами AWS_ACCESS_KEY_ID, спроба виконати aws s3 rm --recursive блокується політикою AWS Compliance Lock на рівні дата-центру Amazon.
• Компанія гарантовано має доступ до незмінних резервних копій.

03. План відновлення холодного резерву через Terraform (IaC Standby)

Аварія рівня OVH (пожежа у центрі обробки даних у Страсбурзі):

• Основний сервер стає фізично недоступним.
• Інженер запускає CI-пайплайн: Terraform за 3 хвилини орендує новий інстанс у Hetzner, Ansible накатує базову конфігурацію, скрипт завантажує останній бекап Restic, а DNS-записи Cloudflare перемикаються на новий IP за 60 секунд.

5. Підводні камені, типові помилки та безпека

• Зберігання пароля дешифрування поруч із бекапом: Якщо пароль до репозиторію Restic зберігається у відкритому файлі /root/.backup_pass, компрометація сервера одночасно відкриває зловмисникам доступ до читання всієї клієнтської бази в бекапах.
• Спроба копіювання файлів живих баз без блокувань (Dirty Reads): Просте копіювання каталогу даних PostgreSQL (cp -r /var/lib/postgresql) під час активних запитів створює неконсистентний бінарний стан (Torn Pages), який неможливо буде запустити після відновлення.
• Брак пам'яті для декомпресії дампу: Якщо на новому сервері встановлено диск меншого розміру, ніж розпакована база даних, процедура відновлення впаде посеред процесу з помилкою нестачі місця на диску (No space left on device).
• Ігнорування конфігураційних файлів та змінних середовища: Бекап лише бази даних без збереження конфігурацій Nginx, SSL-сертифікатів та файлів .env збільшує RTO з 15 хвилин до кількох діб ручного пригадування налаштувань.