Design retention schedules that match your recovery needs.

How PBS keep rules work

PBS retention is expressed as a set of keep-* options evaluated together: keep-last, keep-hourly, keep-daily, keep-weekly, keep-monthly, and keep-yearly. Each rule keeps the newest snapshot per period for that many periods, and a snapshot kept by any rule is kept, full stop. Rules don't double-count: a snapshot already retained by keep-daily also satisfying a weekly slot means the weekly rule reaches further back for its next candidate.

Two things make long retention cheaper than intuition suggests. First, pruning removes snapshot indexes, not data directly — space returns later via garbage collection (see monitor, verify & prune). Second, deduplication means a monthly snapshot kept for a year mostly references chunks shared with its neighbors; each extra retained snapshot typically costs a small fraction of its logical size.

Three worked examples

Homelab / small cluster. Recovery scenario: "I broke something this week" plus the occasional "what did this look like a few months ago."

keep-last 3, keep-daily 7, keep-weekly 4, keep-monthly 6

Business workloads. Recovery scenarios: fine-grained recent history for operational mistakes, plus a year of monthly anchors for "when did this change" questions and slow-burn ransomware discovered late.

keep-last 2, keep-daily 14, keep-weekly 8, keep-monthly 12

Compliance-driven. Some policies require multi-year history. Yearly anchors carry that cheaply, and pairing them with the protected flag (see immutable backups) means no prune misconfiguration can ever violate the policy:

keep-daily 30, keep-weekly 12, keep-monthly 24, keep-yearly 7

Resist the urge to keep everything forever "just in case" — unbounded retention isn't a policy, it's the absence of one, and it eventually turns into an emergency prune performed in a hurry, which is exactly when mistakes delete the wrong things.

Test with the prune simulator before you commit

Never apply a new retention policy blind. The PBS web UI has a built-in prune simulator (Datastore → Prune & GC, or the standalone simulator in the docs) that shows exactly which snapshots a rule set would keep and remove against a calendar. From the CLI, every prune supports a dry run:

proxmox-backup-client prune vm/101 --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --dry-run --repository backup@pbs!prod@pbs.example.com:datastore1
vm/101/2026-07-08T02:00:11Z keep
vm/101/2026-07-07T02:00:09Z keep
vm/101/2026-05-03T02:00:14Z remove

Read the remove list before running it for real. The snapshots it removes are gone as recoverable points the moment the prune runs, even though the disk space returns only after GC.

The storage math

A rough sizing model: full deduplicated size + (retained snapshots × daily change × dedup factor). A 500GB VM with 2% daily change and typical compression might store ~250GB for the first snapshot and add 5–10GB per retained daily. The business policy above (roughly 36 retained points) might land around 450–600GB total — not the 18TB naive multiplication suggests. Your real change rate is discoverable: run two weeks of backups and watch the datastore usage curve.

This math is also why our Shared plan's pay-per-GB model past the first TB works in your favor: dedup means retention grows storage slowly, and you pay for stored chunks, not logical backup size. Sizing guidance lives in our storage and bandwidth guide.