keep-daily=7 doesn't mean 7 days of backups
Proxmox and PBS retention keeps the newest backup in each calendar bucket, not a span of days. How a month of failed jobs can prune away your history, how the keep-* rules combine, and how to set retention in one place.
Retention answers one question: how far back can you go? Most homelabs set it once, glance at keep-daily=7, and assume they have a week of history. That assumption is the trap.
The answer to "how far back" should come from your inventory of what you protect, not from how much disk you happen to have. And it starts with reading the keep-* options correctly.
The trap: buckets, not days
keep-daily=7 does not mean "keep seven days." It means "keep the last backup from each of the last seven days that have a backup."
That last part is the whole problem. Picture a job that fails quietly for a month and then runs once. That one good run satisfies keep-daily, keep-weekly and keep-monthly all at once, and pruning happily deletes the older backups. The rules keep the most recent backup for each calendar bucket; they never promise coverage of time.
So a retention policy that looks like three months of history on paper can collapse to a single backup, with no error anywhere, if the jobs stop running.
The second trap: retention doesn't fix a bad backup
Retention does not protect you from a backup that was bad when it was taken. If the guest was already corrupted when the backup ran, you now have seven pristine copies of corruption.
Retention is about reaching back past the moment something went wrong. That is why the weekly and monthly buckets matter more than the daily ones: a slow corruption can take weeks to notice, and by then the dailies have all rolled over.
How the rules combine
Each rule runs independently, and a backup survives if any rule claims it. That means you can tune the depth per type of guest instead of using one set of numbers for everything. The book's combination looks like this:
| Guest type | keep-last | daily | weekly | monthly | Why |
|---|---|---|---|---|---|
| Databases, Home Assistant, Immich | 2 | 14 | 8 | 6 | A slow corruption can take weeks to notice |
| Ordinary services | 2 | 7 | 4 | 3 | Mistakes get noticed inside a week |
| OPNsense | 2 | 0 | 8 | 6 | It barely changes; config.xml covers the rest |
| vzdump copies on the NAS | 1 | 0 | 4 | 2 | Full copies are big; PBS has the depth |
keep-last is the safety margin. It protects the newest backups even if they fall on the same day as a pruned one, and it covers the "you just took a backup before an upgrade" case.
Before you commit to any numbers, open the Prune Simulator in the Proxmox Backup Server docs (search for "Prune Simulator") and check what actually survives on a calendar. Proxmox's own retention example in the vzdump docs walks through the same thing and is worth reading once.
The fix: set it in one place
Retention belongs on the storage, not on each job. For a vzdump storage such as an NFS share, set it on the storage so every job that writes there inherits it:
pvesm set nas-backup \
--prune-backups keep-last=2,keep-daily=7,keep-weekly=4,keep-monthly=3For Proxmox Backup Server, retention lives in the datastore's prune job, and you can give different namespaces or groups different rules. Set the same keep-* numbers there that you chose for each guest type.
On the backup jobs themselves, leave Retention on "use storage defaults". Setting retention on a job as well gives you two sets of rules fighting each other.
On PBS, remember that pruning only unlinks the index. Garbage collection is what actually frees chunks, and only chunks older than a grace period (24 hours and 5 minutes by default). Schedule GC daily and expect free space to lag pruning by a day.
Changing the numbers later
Changing retention is safe in one direction only. Raising the numbers keeps more. Lowering them deletes on the next prune, with no undo.
If you are short on space, run the change through the simulator first, and if something has to give, shorten the vzdump retention, not the PBS one.
Protected backups for risky changes
Before any change you might regret, such as a major Home Assistant upgrade, a Proxmox major version, or migrating a database, take a manual backup and mark it protected. A protected backup survives every prune until you remove the flag.
In the Proxmox GUI, select the backup and tick Protected. On the command line:
V=pbs01:backup/vm/101/2026-10-04T01:30:00Z
pvesh set /nodes/pve1/storage/pbs01/content/$V --protected 1Make a habit of clearing them after a month. Protected backups do not count toward keep-*, so they pile up.
How much space to plan for
Real numbers depend on your data, but the book gives a sizing rule of thumb for a new PBS disk: the first backup of a guest is roughly its used disk space after compression, and each further day adds about the daily change. For the book's mix of guests, a year of PBS history fits in about twice the live data.
For vzdump full copies, multiply the guest's used size by the number of copies you keep, then add a third for growth.
Checklist: retention
- Keep-* numbers chosen per guest type from your inventory, not from free space
- Checked in the prune simulator that a month of failed jobs cannot wipe your history
- Retention set on the storage or the PBS prune job, with jobs on "use storage defaults"
- PBS garbage collection scheduled daily
- A protected backup taken before every risky change, and cleared a month later
- Backup storage sized with room for a year of growth
Retention only keeps history if backups keep landing. A month of silent failures is exactly what turns keep-daily=7 into a single copy, so pair these numbers with an alert for jobs that stop running.
