Setting Up GFS Backup Rotation (Grandfather-Father-Son)

We have been configuring GFS backup rotation policies for over 5 years. Our experience — more than 50 projects — guarantees that you will not lose data and will save up to 70% on storage costs. Many administrators still use crontab with simple file deletion based on mtime — this leads to the loss of critical restore points when you need to roll back two weeks but the snapshots are no longer there. The GFS (Grandfather-Father-Son) scheme solves this problem by creating a deterministic storage structure. Below is how we do it.

How GFS Solves the Storage Balance Problem?

GFS divides backups into three tiers: daily (Son), weekly (Father), and monthly (Grandfather). This allows storing a year of history using only 24 restore points instead of 365. Space savings — up to 93% compared to daily perpetual storage. For databases with deduplication (Restic, Borg), the actual volume is further reduced by 10x by storing only changed blocks.

Compare: with daily storage for a year, 365 backups accumulate. GFS leaves only 24. TCO reduction for backups reaches 70%. For a 500 GB database with 5% daily changes, actual storage will be 500 × (1 + 23 × 0.05) = 1075 GB instead of 500 × 24 = 12 TB. Savings — more than 90%. GFS is 15 times better than simple daily storage in terms of restore points.

Classic GFS Scheme

Total: 7 + 5 + 12 = 24 backups covering a year of history. For compliance (finance, healthcare), an annual tier with 5–7 years retention is added.

Implementation Script

#!/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: daily — keep 7 days
find "$BACKUP_ROOT/daily" -name "*.sql.gz" -mtime +7 -delete

# Father: weekly (Sunday)
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: monthly (1st day)
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

Tools with Native GFS Support

Most modern tools (e.g., Restic) support GFS natively. Below is a comparison of popular solutions.

Restic:

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

Veeam Backup & Replication — in job settings: Storage → Retention Policy → GFS retention, checkboxes Weekly/Monthly/Yearly.

BorgBackup/Borgmatic in config.yaml:

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

Barman for PostgreSQL — via retention window, with additional logic for weekly/monthly copies.

GFS Setup Process

We follow this plan:

1. Data audit and RPO assessment. We evaluate volumes, change frequency, restore point requirements.
2. Tool selection. Restic for Linux, Veeam for Windows, Borg for large clusters.
3. Policy configuration. Define retention periods for each tier, considering compliance.
4. Testing. Verify restore from backups at each tier.
5. Monitoring. Set up alerts in Prometheus/Grafana upon freshness violation.

Benefits of GFS Implementation

Compared to simple daily storage, GFS reduces the number of backups from 365 to 24 — 15 times fewer. For business, this means a TCO reduction of up to 70% on backups. We guarantee that after setup, rotation will work automatically, and you will receive documentation and monitoring scripts. Order configuration — get a consultation and a trial period.

What's Included

• Analysis of current backup infrastructure
• Optimal tool selection (Restic, Borg, Veeam, scripts)
• GFS policy setup considering RPO/RTO
• Verification and alerting scripts
• Restore procedure documentation
• On-call team training
• Certified engineers (AWS, HashiCorp)

Timeline and Cost

Setup time: from 0.5 days for a single tool to 2–3 days for unified policy across the infrastructure. Cost is calculated individually — depends on data volume, number of systems, and compliance requirements. Contact us for a project evaluation — we will provide a plan and estimate within a day.

How to Verify Backup Freshness?

Regular verification is key to reliability. Use a script that checks the age of the latest backup at each level:

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

Run via cron with metrics sent to Prometheus. We include such checks in the policy.