GFS backup retention

Nobody needs the backup from last Tuesday at 03:00 in five years' time. But the one from the end of the month, maybe.

The short answer

GFS stands for Grandfather-Father-Son. It is a tiered retention policy: you keep backups for different periods, many recent ones and fewer old ones, typically weekly, monthly and yearly copies on top of the short-term set [1][2]. Backup tools express it with "keep" rules, for example keep-daily, keep-weekly, keep-monthly and keep-yearly in Proxmox Backup Server (PBS) [3]. Our assessment: set a GFS-style policy once, test it in a dry run, and let the tool delete in the background instead of pruning by hand.

How it works

1. Tiers. Veeam describes GFS as weekly, monthly and yearly cycles, called sons, fathers and grandfathers, alongside the short-term retention policy. These weekly, monthly and yearly backups are always full backups [2]. The docs of PBS, Proxmox VE and restic that we read do not use the name GFS, but their keep options build the same pattern [3][4][5].
2. Rules run in order. In PBS and Proxmox VE the options are processed in the order keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, keep-yearly. Each covers only its own time period, and the next one considers only older backups [3][4].
3. One per period, the latest. If a day, week or month contains several backups, only the latest is kept. Periods without backups do not count, and weeks run from Monday to Sunday in the ISO week system [3]. restic works on natural calendar boundaries and counts only periods that have snapshots [5].
4. The upper bound is the sum. Because the periods do not overlap, a policy keeps at most as many backups as the numbers add up to. Our reading of the docs; test it with the prune simulator in PBS [3].
5. Why it exists. Long chains of incremental backups raise recovery time, and one corrupted increment can make the whole chain useless. Periodic full backups split the chain into several shorter ones [2].
6. Caveats from Veeam. A GFS flag can only be set on a full backup, so monthly retention needs at least one full backup per month. Flagged backups stay protected until their period ends, and flags apply only to backups created after you save the settings [1].
7. Pruning is not freeing. In PBS, prune removes only snapshot metadata. The chunks go with the next garbage collection run, and data in a chunk outlives a pruned snapshot until then [3].
8. Err on the long side. PBS and Proxmox VE recommend a longer retention than the minimum you need, because you can reduce it later but cannot recreate removed backups [3][4].

A practical example

You back up a small server every night and choose keep-last=3, keep-daily=7, keep-weekly=4, keep-monthly=6. That keeps at most 20 snapshots (3 + 7 + 4 + 6) and reaches back roughly seven months. The numbers are our own illustration, not a vendor recommendation. The Proxmox documentation shows a larger example for ten years of coverage: keep-last=3, keep-daily=13, keep-weekly=8, keep-monthly=11 and keep-yearly=9 [3][4]. With Proxmox VE you can pass it on the command line, as in vzdump 777 --prune-backups keep-last=3,keep-daily=13,keep-yearly=9 [4]. We have not documented a backup setup like this in our inventory (14 to 16 Oct 2026), so this is a generic walk-through.

Checklist

• Write down how far back you must be able to restore, then choose the rules, not the other way round [3][4].
• Run restic's forget with --dry-run first to see what would go [5].
• Check that backups really run in every period, or a tier stays empty [1][3].
• Schedule garbage collection after pruning in PBS [3].
• Add verification, because old backups age [3].
• Keep one tier of copies offsite; retention says how long, not where.