Backup Rotation (GFS) Calculator
Works out total storage and backup set count for a Grandfather-Father-Son rotation scheme — the standard, decades-old approach to backup retention that balances "keep enough history to actually recover from something" against "don't store infinite full copies of everything forever."
What grandfather-father-son actually means
- Son — daily backups, typically incremental (only what changed since the last backup), kept for a short window — a week or two
- Father — weekly backups, typically full, kept for a month or so
- Grandfather — monthly backups, full, kept for the longest — often a year or more depending on compliance requirements
The scheme gives you fine-grained recovery for anything recent (yesterday, or three days ago) while keeping long-term history without the storage cost of a full backup every single day for months on end.
Why dailies are usually incremental, and why that matters for cost
A full backup captures everything, every time — expensive in both storage and backup-window duration. An incremental only captures what changed since the previous backup, which for most systems is a small fraction of total data on any given day. That's why dailies (the "sons") are almost always incremental in practice, while weeklies and monthlies typically stay full — full backups are simpler to restore from directly (no chain of incrementals to replay) and full copies at wider intervals are cheap enough to justify the simplicity.
The tradeoff incrementals introduce
Restoring from an incremental chain means replaying the last full backup plus every incremental since — more restore steps, more places for something to go wrong, and a slower recovery than restoring a single full backup directly. This is exactly why the father/grandfather tiers stay full: for backups you'd reach for after a longer gap, restore simplicity and reliability matter more than the storage saved by incrementals, and the wider spacing between them means fewer full copies overall regardless.
Sizing this for real
The daily incremental size depends entirely on your actual data change rate — a database with heavy write activity might see 15-20% daily change, a mostly-static file server might see under 2%. Measure your actual change rate rather than guessing, since it's the single biggest lever on total storage cost in this whole scheme — getting it wrong by a factor of two changes the total storage estimate by roughly the same factor.