Налаштування політик ротації бекапів GFS: Grandfather-Father-Son

Ми налаштовуємо політики ротації бекапів за схемою GFS понад 5 років. Наш досвід — понад 50 проєктів — дозволяє гарантувати, що ви не втратите дані та заощадите до 70% витрат на сховище. Багато адміністраторів досі використовують crontab із простим видаленням файлів за mtime — це призводить до втрати критичних точок відновлення, коли відкотитися потрібно на два тижні, а снєпшотів уже немає. Схема GFS (Grandfather-Father-Son) вирішує цю проблему, створюючи детерміновану структуру зберігання. Нижче — як ми це робимо.

Як GFS вирішує проблему балансу зберігання?

GFS розділяє бекапи на три рівні: щоденні (Son), щотижневі (Father) та щомісячні (Grandfather). Це дозволяє зберігати історію за рік, використовуючи лише 24 точки відновлення замість 365. Економія місця — до 93% порівняно з щоденним безстроковим зберіганням. Для баз даних з дедуплікацією (Restic, Borg) реальний об'єм додатково знижується в 10 разів за рахунок зберігання лише змінених блоків.

Порівняйте: при щоденному зберіганні за рік накопичується 365 бекапів. GFS залишає лише 24. Зниження TCO на бекапи досягає 70%. Для бази даних розміром 500 ГБ зі змінами 5% на день реальне сховище складе 500 × (1 + 23 × 0.05) = 1075 ГБ замість 500 × 24 = 12 ТБ. Економія — понад 90%. GFS краще простого щоденного зберігання в 15 разів за кількістю точок відновлення.

Класична схема GFS

Разом: 7 + 5 + 12 = 24 бекапи покривають рік історії. Для compliance (фінанси, медицина) додають щорічний рівень зі зберіганням 5–7 років.

Реалізація у скрипті

#!/bin/bash
# /usr/local/bin/gfs-rotation.sh
set -euo pipefail

BACKUP_ROOT=/backups/databases
DATE=$(date +%Y%m%d)
DOW=$(date +%u)
DOM=$(date +%d)
DUMP_FILE="$BACKUP_ROOT/daily/mydb_${DATE}.sql.gz"

sudo -u postgres pg_dump mydb | gzip > "$DUMP_FILE"

# Son: щоденні — зберігати 7 днів
find "$BACKUP_ROOT/daily" -name "*.sql.gz" -mtime +7 -delete

# Father: щотижневий (неділя)
if [ "$DOW" -eq 7 ]; then
    cp "$DUMP_FILE" "$BACKUP_ROOT/weekly/mydb_week_${DATE}.sql.gz"
    find "$BACKUP_ROOT/weekly" -name "*.sql.gz" -mtime +35 -delete
fi

# Grandfather: щомісячний (1-е число)
if [ "$DOM" -eq "01" ]; then
    cp "$DUMP_FILE" "$BACKUP_ROOT/monthly/mydb_month_${DATE}.sql.gz"
    find "$BACKUP_ROOT/monthly" -name "*.sql.gz" -mtime +366 -delete
fi

/backups/databases/
├── daily/
│   ├── mydb_YYYYMMDD.sql.gz
│   ├── mydb_YYYYMMDD.sql.gz
│   └── mydb_YYYYMMDD.sql.gz
├── weekly/
│   ├── mydb_week_YYYYMMDD.sql.gz
│   └── mydb_week_YYYYMMDD.sql.gz
└── monthly/
    └── mydb_month_YYYYMMDD.sql.gz

Інструменти з підтримкою GFS

Більшість сучасних інструментів (наприклад, Restic) підтримують GFS нативно. Нижче — порівняння популярних рішень.

Restic:

restic forget \ --keep-daily 7 \ --keep-weekly 5 \ --keep-monthly 12 \ --keep-yearly 3 \ --prune 

Veeam Backup & Replication — у налаштуваннях завдання: Storage → Retention Policy → GFS retention, галочки Weekly/Monthly/Yearly.

BorgBackup/Borgmatic у config.yaml:

retention: keep_daily: 7 keep_weekly: 5 keep_monthly: 12 keep_yearly: 3 

Barman для PostgreSQL — через retention window, з додатковою логікою для щотижневих/щомісячних копій.

Процес налаштування GFS

Ми працюємо за наступним планом:

1. Аудит даних і RPO. Оцінюємо об'єми, частоту змін, вимоги до точки відновлення.
2. Вибір інструменту. Restic для Linux, Veeam для Windows, Borg для великих кластерів.
3. Налаштування політики. Визначаємо терміни зберігання для кожного рівня, враховуючи compliance.
4. Тестування. Перевіряємо відновлення з бекапів кожного рівня.
5. Моніторинг. Налаштовуємо оповіщення у Prometheus/Grafana при порушенні свіжості.

Переваги впровадження GFS

Порівняно з простим щоденним зберіганням GFS скорочує кількість бекапів з 365 до 24 — в 15 разів менше. Для бізнесу це означає зниження TCO на бекапи до 70%. Ми гарантуємо, що після налаштування ротація буде працювати автоматично, а ви отримаєте документацію та скрипти моніторингу. Замовте налаштування — отримайте консультацію та тестовий період.

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

• Аналіз поточної інфраструктури бекапів
• Вибір оптимального інструменту (Restic, Borg, Veeam, скрипти)
• Налаштування політики GFS з урахуванням RPO/RTO
• Скрипти верифікації та оповіщення
• Документація щодо процедури відновлення
• Навчання чергової зміни
• Сертифіковані інженери (AWS, HashiCorp)

Терміни та вартість

Термін налаштування: від 0,5 дня для одного інструменту до 2–3 днів при уніфікації політики по всій інфраструктурі. Вартість розраховується індивідуально — залежить від об'єму даних, кількості систем і вимог до compliance. Зв'яжіться з нами для оцінки вашого проєкту — надамо план і кошторис протягом дня.

Як перевірити свіжість бекапів?

Регулярна перевірка — запорука надійності. Використовуйте скрипт, що перевіряє вік останнього бекапу кожного рівня:

check_freshness /backups/daily 25 "Daily"
check_freshness /backups/weekly 169 "Weekly"
check_freshness /backups/monthly 745 "Monthly"

Запускайте через cron з відправкою метрик у Prometheus. Ми включаємо таку перевірку в регламент.