Proxmox Backup Server retention: how keep-last, keep-daily and keep-weekly actually work

Most people read keep-daily 7 as “keep seven days of backups”. That is not what it does, and the gap between what you think you configured and what Proxmox Backup Server actually keeps is where people either waste storage or, worse, discover a snapshot they needed was pruned away. The retention rules are simple once you see the model behind them, so let me lay it out and then walk a real schedule through it.

Retention is a set of time buckets, not a countdown

PBS retention is expressed with a family of keep-* options: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, and keep-yearly. Each one is a count, and each one works on a bucket of time.

Take keep-daily 7. PBS does not keep every snapshot from the last seven days. It walks your snapshots from newest to oldest, groups them by calendar day, and keeps the newest snapshot in each of the seven most recent days that have a snapshot. If a given day has six snapshots, five are candidates for removal and one survives to represent that day. If you skipped a day, that day simply does not count toward the seven. So keep-daily 7 means “one snapshot for each of the last seven days that have one”, not “everything from the last week”.

The same logic applies up the ladder. keep-weekly 4 keeps the newest snapshot in each of the last four calendar weeks. keep-monthly 6 keeps one per month for six months. keep-yearly does the same by year. Each rule is a coarser bucket than the one below it.

The rules overlap, and that is the point

The mistake that follows is to add the numbers up. keep-daily 7 plus keep-weekly 4 plus keep-monthly 6 is not seventeen snapshots. The rules overlap, and a single snapshot can satisfy several of them at once.

Today’s snapshot is the newest of today (daily), the newest of this week (weekly), and the newest of this month (monthly), so it is kept by three rules but stored once. What you actually retain is the union of every rule’s picks, deduplicated. With that schedule you end up with roughly seven dailies, plus the older weekly representatives that the dailies do not already cover, plus the older monthly ones, tapering off as you go back in time. The shape is dense recent history and sparse old history, which is exactly what a sane retention policy looks like.

keep-last is your floor

keep-last N is the odd one out: it ignores calendar buckets entirely and keeps the N most recent snapshots no matter when they were taken. It is your safety floor. If a VM is backed up every hour and you only set keep-daily 7, an incident that spans a few hours could still leave you with just one snapshot from today. keep-last 3 guarantees you always have the last three, whatever the daily rule decides. On a datastore that receives frequent backups, always set a keep-last.

A worked example

Say srv-db01 is backed up every night, and you set keep-daily 7, keep-weekly 4, keep-monthly 6. After a few months of nightly runs you retain:

• the last 7 nightly snapshots, one per day,
• 4 weekly snapshots, one per week, for the weeks not already covered by those 7 dailies,
• 6 monthly snapshots, one per month, for the months not already covered above.

That is on the order of 15 to 16 distinct snapshots spanning half a year, not 180. If you had reasoned in raw days you would have provisioned an order of magnitude too much storage. This is also why deduplication and retention have to be thought about together, which we break down in what a 3-2-1 setup actually costs on PBS.

Pruning is not the same as reclaiming space

One more thing that surprises people: running a prune does not immediately free disk. Prune only removes the snapshot from the index. The underlying chunks are still on disk until garbage collection runs, sees they are no longer referenced by any snapshot, and removes them after a safety grace period. So the storage graph does not drop the instant you prune. If you want to change how aggressively this happens, the prune and GC interval documentation covers the schedule, and the separate question of when your backup jobs run is in the Proxmox VE backup scheduling guide.

Do not guess the numbers, simulate them

The reason retention trips people up is that the outcome of a set of keep-* rules against a real backup cadence is genuinely hard to compute in your head. Rather than deploy a policy and find out months later that it kept too little or too much, put your schedule and your rules into the PBS retention simulator and see exactly which snapshots survive and how many you end up storing. It turns the abstract rules above into the concrete list of what you would actually have on disk.

On managed Cloud-PBS

On a managed cloud backup server, the prune and garbage-collection schedules run for you, tuned so that space is reclaimed on a sensible cadence without you having to babysit a cron. You still own the retention policy, because only you know your recovery requirements, but the mechanics of enforcing it, pruning on schedule and collecting garbage without impacting live backups, are ours to run. If you are sizing a policy, decide your recovery window first, express it as keep-* rules, and simulate before you commit.