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

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

Уявіть: о 3 годині ночі відмовила файлова система на сервері з базою даних. Ручне відновлення зайняло б 6 годин, а автоматичне — 15 хвилин. Ми впроваджуємо систему, яка виявляє збій, обирає точку відновлення, піднімає інфраструктуру та перевіряє результат без участі людини. За плечима понад 50 проєктів з автоматизації відмовостійкості. Гарантуємо SLA на RTO та RPO. Отримайте консультацію — оцінимо ваш проєкт.

Як працює автоматичне відновлення?

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

Чому автоматичне відновлення критичне для бізнесу?

Ручні процедури повільніші в 10–15 разів. У середньому RTO при ручному відновленні становить 4–6 годин, автоматичне — 15–30 хвилин. RPO знижується з 24 годин до хвилин завдяки PITR. Це безпосередньо впливає на доступність сервісу та репутацію.

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

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

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

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

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

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

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 (мінімалістичний, популярний у хмарі).

Порівняння інструментів для PostgreSQL PITR

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

Для 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) 

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

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

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 і автоматично відновлює при детектуванні проблем.

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

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

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

Що входить у роботу

• Налаштування WAL-архівування та PITR для PostgreSQL
• Terraform-скрипти для автоматичного відновлення інфраструктури
• CI/CD-пайплайн для щотижневого тестування відновлення
• Документація щодо процедури та метрик
• Навчання команди (1 сесія)
• Підтримка 2 тижні після запуску

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

Разом: 2-3 тижні для повноцінної системи. Замовте аудит — оцінимо ваш проєкт.