Настройка политик ротации бэкапов 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. Мы включаем такую проверку в регламент.