Proxmox Backup Server Retention: keep-daily Buckets by Local Day

A Proxmox Backup Server prune policy of keep-daily 7 reads like "keep a week of backups". It does not mean that. It means "keep the newest snapshot from each of the last 7 calendar days, in the server's local timezone". If your backups run near local midnight, two of them land in the same bucket. A host with exactly two backups was one prune away from having one.

How the buckets actually work

PBS prune options are not independent counts of snapshots. Each one defines time buckets and keeps the newest snapshot in each bucket:

• keep-last N. The N most recent snapshots, whenever they happened. The only option that counts snapshots rather than periods.
• keep-hourly N. Newest snapshot from each of the last N clock hours.
• keep-daily N. Newest from each of the last N calendar days.
• keep-weekly, keep-monthly and keep-yearly. The same idea at larger granularity.

A snapshot survives if any option wants it. Here is the consequence people miss. These are calendar buckets, not rolling windows, so two snapshots close together in time compete for the same slot. One of them loses.

The case that nearly cost a backup

A host had exactly two snapshots. A new machine, only just brought into the backup rotation:

2026-08-09T05:49Z
2026-08-10T04:53Z

Nearly 23 hours apart. Two different dates in UTC. Obviously two days of backups.

The backup server's local timezone was UTC−5. In local time:

2026-08-09T05:49Z  ->  2026-08-09 00:49 local
2026-08-10T04:53Z  ->  2026-08-09 23:53 local     <- same local day

Both fell on 2026-08-09 locally. With keep-daily 7 and no keep-last, PBS saw one day holding two snapshots, kept the newest, and marked the other for deletion. A host with two backups went down to one, while the policy still read like a week of retention.

This is not an edge case if your backups run in the early hours UTC. A fleet backing up between roughly 04:30 and 05:50 UTC runs right around local midnight in the Americas. Any of those jobs can straddle a local-day boundary and collide on the next run.

The fix: always pair keep-daily with a keep-last floor

keep-last counts snapshots, so it is immune to timezone bucketing. And because a snapshot survives if any rule wants it, keep-last can only ever retain more, never delete more. There is no downside beyond a little extra disk.

keep-last=3, keep-daily=7, keep-weekly=4, keep-monthly=6, keep-yearly=1

Adding keep-last 3 across every job fixed the latent version of this on jobs that had run for months without anyone noticing. After the change, a full prune across five namespaces removed 12 snapshots out of 530. All genuine same-day duplicates, with every namespace still holding one snapshot per distinct day.

Dry-run before you enable a prune job. Always.

Prune deletes. Reasoning about bucket semantics is exactly the kind of thing that feels obvious and is not. This whole article is an example. PBS tells you precisely what it intends to do:

proxmox-backup-client prune <group> \
  --repository <user@realm!token>@<host>:<datastore> \
  --ns <namespace> \
  --keep-last 3 --keep-daily 7 \
  --dry-run

It prints each snapshot with keep or remove. Read it per group rather than scanning the total. The total looks reasonable in precisely the case that ruins you. One group losing its only spare copy is invisible in an aggregate.

Two more things worth knowing

• Some backups should have no prune job at all. One-off archival backups have no schedule creating replacements. A physical PC captured once. A machine captured before decommissioning. A retention policy applied to those only ever destroys. Leave them unpruned deliberately, and write down that it is deliberate so nobody "fixes" it later.
• Namespaces need their own jobs. A prune job scoped to the root namespace does not touch snapshots inside namespaces, so hosts backed up into their own namespace accumulate indefinitely. The opposite failure, and just as silent, until the datastore fills.
• The --comment field is capped at 128 characters, which is easy to trip over when scripting job creation with a descriptive note.

Prevention

• Never enable a retention policy from reasoning alone. Dry-run it, per group.
• Pair every bucket-based rule with keep-last. It costs a little disk and removes an entire class of surprise.
• Know your backup server's timezone. That one buckets the snapshots, not the client's.
• Check newly added hosts specifically. The danger window is when a machine has only one or two snapshots. A mature group with weeks of history absorbs a bucket collision without noticing.