← All guides

Designing a backup retention policy (GFS explained)

How long to keep Postgres backups: the grandfather-father-son scheme, compliance drivers, and the one backup you must never delete.

The failure retention protects against

Fast failures (dropped table today) need recent backups. Slow failures — corruption or bad logic quietly mangling rows for weeks — need OLD backups, because every recent one contains the damage. Retention design is about the second kind.

GFS: 7 daily, 4 weekly, 12 monthly

Keep every daily for a week (fast failures), a weekly (say Sunday's) for a month, and a monthly (the 1st) for a year. ~23 archives cover you from 'oops just now' to 'this has been wrong since Q1' at a fraction of keep-everything storage.

Two hard rules

1. Never delete your most recent VERIFIED backup — age is irrelevant; it may be the only copy proven to restore.
2. Keep the audit trail after pruning — delete the object, keep the record (when taken, size, checks passed). Auditors ask about the policy's history, not just its present.

Firedrill enforces GFS automatically on Pro/Team and hard-codes rule 1.

A backup you've never restored is a hope, not a backup.

Firedrill restore-tests every backup it takes — on real infrastructure, with the report to prove it.