Реалізація автоматичного відновлення з бекапу при збої

Реалізація автоматичного відновлення з бэкапу при сбою

Автоматичне відновлення — це наступний рівень після простого наявності бэкапів. Система сама виявляє проблему, сама вибирає підходящу точку відновлення, сама піднімає інфраструктуру та сама перевіряє результат. Участь людини — тільки фінальна верифікація.

Сценарії автоматичного відновлення

Пошкодження даних у БД. Тригер: моніторинг фіксує аномалію (різкий ріст помилок, невідповідність контрольних сум). Автоматика: зупинити запис у пошкоджену БД, відновити з останнього валідного снімка, перевірити цілісність, переключити трафік.

Сбой файлової системи. Тригер: монтування завершується помилкою або read-only режим. Автоматика: Terraform створює новий інстанс з чистим диском, rsync або S3-sync відновлює дані, додаток перезапускається.

Повний вихід сервера з ладу. Тригер: health check завершується невдачею N разів поспіль. Автоматика: Auto Scaling Group (AWS) або аналог піднімає новий інстанс з AMI, cloud-init розгортає конфігурацію, дані монтуються з персистентного сховища.

Архітектура для PostgreSQL

Point-in-Time Recovery (PITR) — основа автоматичного відновлення для реляційних БД.

WAL архівування в S3:

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'aws s3 cp %p s3://mybackups/wal/%f'
restore_command = 'aws s3 cp s3://mybackups/wal/%f %p'

Базові снімки через pgBackRest або pg_basebackup — раз на добу в S3.

Автоматизація відновлення:

def auto_restore_postgres(target_time: datetime, db_config: dict):
    # 1. Знайти найближчий базовий снімок до target_time
    base_backup = find_latest_base_backup_before(target_time)

    # 2. Розгорнути новий PostgreSQL інстанс
    instance = provision_postgres_instance(db_config)

    # 3. Відновити базовий снімок
    restore_base_backup(instance, base_backup)

    # 4. Застосувати WAL-логи до target_time
    apply_wal_until(instance, target_time)

    # 5. Перевірити цілісність
    verify_database_integrity(instance)

    return instance

Утиліти: pgBackRest (найкращий вибір для PostgreSQL), Barman, WAL-G (мінімалістичний, популярний у хмарі).

Автоматичне відновлення файлів та медіа

Для S3/об'єктних сховищ: AWS S3 Versioning + S3 Object Lock захищають від випадкового видалення. Відновлення конкретної версії файлу — через AWS Lambda, запущену за SNS-подією або за запитом додатку.

Для файлових систем: снімки EBS (AWS) або Persistent Disk (GCP) за розкладом кожні 4-6 годин. Terraform-скрипт відновлює том зі снімка та монтує до нового інстансу.

Верифікація після відновлення

Автоматичне відновлення без верифікації — напівготове рішення. Обов'язкові перевірки:

def verify_restoration(instance):
    checks = [
        check_db_connectivity(instance),
        check_row_counts(instance, expected_counts),
        check_referential_integrity(instance),
        check_recent_data_present(instance, min_age_minutes=5),
        run_application_smoke_tests(instance),
    ]
    return all(checks)

Якщо верифікація не пройшла — автоматика пробує попередню точку відновлення або ескалірує alert команді.

Оркестрація відновлення

AWS Systems Manager Automation або Ansible playbook, запущений за подією:

1. CloudWatch Alarm → SNS Topic → Lambda function
2. Lambda ініціює SSM Automation Document
3. SSM виконує кроки: provision → restore → verify
4. За результатом: переключити Route 53 або ескалірувати у PagerDuty

Для Kubernetes: Velero відновлює namespace зі снімка. Operator-патерн — кастомний Kubernetes Operator стежить за станом PVC та автоматично відновлює при виявленні проблем.

Тестування автоматичного відновлення

Щотижневий плановий тест: автоматика розгортає ізольовану копію з бэкапу в окремому оточенні, запускає верифікацію, надсилає звіт. Якщо верифікація пройшла — бэкапи валідні. Якщо ні — alert без очікування реального інцидента.

Метрики для моніторингу

• RTO actual — час від виявлення проблеми до верифікації відновлення
• RPO actual — скільки даних втрачено (різниця між останнім бэкапом та моментом сбою)
• Backup freshness — вік останнього успішного бэкапу кожного компонента
• Restore test success rate — % успішних автоматичних тест-відновлень на місяць

Терміни реалізації

• PostgreSQL PITR з WAL архівуванням — 3-5 днів
• S3 versioning + Lambda авто-відновлення — 2-3 дні
• ASG + cloud-init авто-відновлення сервера — 3-5 днів
• Оркестрація + верифікація + alerts — 3-5 днів
• Тестування та документація — 2-3 дні

Разом: 2-3 тижні для повноцінної системи автоматичного відновлення.