How PBS keep-* Prune Rules Actually Work

Almost everyone reads keep-daily 7 as "keep backups for the last 7 days." It does not mean that. If your backups run on an irregular schedule, that same setting can retain snapshots spanning weeks. The keep-* rules count backups per time bucket, not calendar days on a clock. Once you see how Proxmox Backup Server actually buckets and selects snapshots, retention stops surprising you and you can set policies that do what you intended.

This is the mechanics companion to our pruning and garbage collection guide. That post covers scheduling and how pruning interacts with garbage collection. This one is about the selection algorithm itself: exactly which snapshots survive and why.

The Mental Model That Trips People Up

The intuitive reading is time-window based. "keep-daily 7" sounds like "delete anything older than 7 days." Under that model, retention is a sliding window anchored to the current date, and a day with no backup still burns a day of the window.

Proxmox Backup Server does not work that way. It never looks at "how many days ago" a snapshot is. It groups snapshots into period buckets and keeps a fixed number of buckets. An empty period is simply not a bucket. This one difference is the source of nearly every "why do I still have that snapshot" question.

How PBS Buckets a Snapshot

Every snapshot has a timestamp. For each time-based rule, Proxmox Backup Server derives a bucket key from that timestamp, computed in the server's local timezone:

• keep-daily buckets by calendar day (2026-07-16).
• keep-weekly buckets by ISO week (2026-W29, weeks start Monday).
• keep-monthly buckets by calendar month (2026-07).
• keep-yearly buckets by calendar year (2026).

Two snapshots with the same bucket key are in the same period. The selection then works one rule at a time:

1. Sort all snapshots newest to oldest.
2. Walk the list from newest. For each snapshot, compute its bucket key for this rule.
3. If that bucket key has not been kept yet and you have kept fewer than N buckets, keep this snapshot and mark the bucket as used.
4. Stop once N buckets are filled.

The consequence: for each time-based rule you keep the most recent snapshot in each of the N most recent non-empty periods. keep-last N is the exception. It ignores buckets entirely and keeps the N newest snapshots by count.

Why keep-daily 7 Is Not "7 Days"

Here is the case that makes it click. Suppose your backups run weekly, not daily, and you set keep-daily 7 because it sounded safe. These snapshots exist, newest first:

Each backup falls on a distinct calendar day, so each one is its own daily bucket. keep-daily 7 keeps the 7 most recent daily buckets, which here span six weeks of history. The setting named "daily" retained roughly 42 days of backups. Nothing is broken. The rule counted seven days-with-a-backup, and those days happened to be a week apart.

The same logic runs in reverse. If you back up six times a day and set keep-daily 7, you keep one snapshot from each of the last 7 days, discarding the other five per day. Seven daily buckets, one survivor each.

Multiple Backups in One Period

Because time-based rules keep one snapshot per bucket, running many backups inside a single period does not multiply what you retain under those rules. Consider four backups today plus one yesterday, with keep-daily 2:

Today is one bucket, so only the most recent snapshot from today survives the daily rule. If you want to retain several backups from the same day (common with hourly or intraday jobs), that is exactly what keep-last is for. keep-last 4 here would keep all four of today's snapshots because it counts snapshots, not days.

Evaluation Order and Overlap

Proxmox Backup Server evaluates the rules in a fixed sequence: keep-last, then keep-daily, keep-weekly, keep-monthly, keep-yearly. A snapshot kept by an earlier rule is already safe. Later rules do not need to re-keep it, but the same snapshot can satisfy several rules at once.

This is why you cannot add the numbers to predict the total. With keep-last 3 and keep-daily 7 on a once-a-day schedule, your three newest snapshots satisfy both keep-last and three of the seven daily buckets. The total kept is around seven, not ten. The overlap is intentional and keeps the retained set smaller than a naive sum suggests.

A Combined Worked Example

Put the rules together. Daily backups exist for the last several months. The policy is keep-last 3, keep-daily 7, keep-weekly 4, keep-monthly 3. Walking newest to oldest:

• The 3 newest snapshots are kept by keep-last. They also fill the 3 newest daily buckets.
• keep-daily 7 fills daily buckets 4 through 7 with the next four days.
• keep-weekly 4 then keeps the newest snapshot in each of the 4 most recent ISO weeks that are not already covered. The current week is already represented, so this reaches back into older weeks.
• keep-monthly 3 keeps the newest snapshot in each of the 3 most recent months not already covered, extending history to roughly three months back.

The result is dense granularity near the present (every day for a week) that thins out into weekly and then monthly checkpoints as you go back. That tapering shape is the whole point of layering the rules. Each snapshot you keep costs very little on disk anyway, because deduplication shares chunks across every snapshot in the datastore. Our chunk store deep dive explains why an extra monthly snapshot is nearly free.

Common Mistakes

• Setting only keep-daily for intraday backups. Hourly jobs with just keep-daily 7 collapse to one snapshot per day. Add keep-last to retain recent intraday points.
• Assuming gaps expire old data. A paused or failed backup schedule means fewer non-empty buckets, so old snapshots hang around longer than the numbers imply. Combine time rules with keep-last if you want a hard cap on count.
• Expecting pruning to free disk space. Pruning only removes snapshot references. Space returns during garbage collection. The pruning and garbage collection guide covers the ordering.
• Reading across namespaces. Prune policies are set per prune job and can be scoped per namespace. If you consolidate several clusters into one datastore, each namespace can carry its own keep-* settings.

Preview Before You Commit

Never guess. The PBS web UI has a prune simulator under each datastore's content view: pick a backup group, open the prune dialog, and it shows exactly which snapshots would be kept or removed under your proposed settings without deleting anything. From the CLI, add --dry-run to any prune command for the same preview. Run it against a group with an irregular history, not a clean daily one, so the bucket behavior is visible.

Wrapping Up

The keep-* rules are a bucketing algorithm, not a time window. Proxmox Backup Server groups snapshots by day, week, month, and year, then keeps the newest snapshot in each of the N most recent non-empty buckets, while keep-last keeps a raw count of the newest snapshots. Empty periods are skipped, backups in the same period collapse to one under the time rules, and overlap between rules means the total kept is smaller than the sum. Set your policy against how often you actually back up, then confirm it with a dry run before trusting it.