Learn Proxmox Backup Server - Retention & Prune Policy

#Introduction

Encryption in episode 7 keeps data confidential, but how long snapshots survive has not been answered. Keep everything forever and storage balloons; delete too fast and your recovery points thin out. Episode 8 covers retention & prune policy — the policy language that decides which snapshots live and which retire.

Think of it like an archive cabinet with expiration rules: today's, yesterday's, and the last week's documents stay stored in full; older ones keep one per week, even older ones one per month. The cabinet stays organized without throwing away what is still needed — that is a good prune policy.

#Prune: Retention per Backup Group

#Keep-last, Keep-daily, Keep-weekly, Keep-monthly

PBS offers retention rules applied per backup group. The rules:

• Keep-last N: keep the N most recent snapshots, regardless of time.
• Keep-hourly N: keep at most N snapshots per last hour.
• Keep-daily N: at most N snapshots per day.
• Keep-weekly N: at most N snapshots per week.
• Keep-monthly N: at most N snapshots per month.
• Keep-yearly N: at most N snapshots per year.

Prune keeps the snapshots that satisfy the criteria and deletes the rest. A typical policy example:

keep-last:   7      → last 7 snapshots
keep-daily:  14     → 14 daily snapshots
keep-weekly: 8      → 8 weekly snapshots
keep-monthly: 6     → 6 monthly snapshots

#Running Prune

In PVE, retention is set on the backup job via the Prune Backups option (format keep-last=7,keep-daily=14,...). From the proxmox-backup-client CLI:

proxmox-backup-client prune \
  --repository backup@pbs@10.0.1.10:store1 \
  --keep-last 7 --keep-daily 14 --keep-weekly 8 --keep-monthly 6

On the server side, prune can also be scheduled as a prune job (Datastore → Prune Jobs) so it runs automatically after backups. Prune is a metadata operation — fast, because it does not touch chunks. Remember the rule from episode 6: prune first, then GC.

#Retention on Sync Jobs

Whenever snapshots are synced to a remote PBS (episode 10), retention must be set again on the remote side. Sync jobs have their own keep parameters and the --remove-vanished option, which removes remote snapshots that no longer exist on the source. This prevents the remote datastore from ballooning by copying all history without limit:

proxmox-backup-manager sync job update <id> \
  --keep-last 7 --keep-daily 14 --remove-vanished

This combination keeps the remote mirror compact: it stores the same retention subset as the source, without piling up duplicates.

#Building a Policy to Match RPO/RTO

#The Relationship Between Retention and RPO/RTO

Retention must answer two business questions:

• RPO (Recovery Point Objective): how far back you can afford to lose data. The more frequent the backups, the smaller the data loss; retention determines how far back that data is available.
• RTO (Recovery Time Objective): how fast a restore must complete. Overly large retention slows GC and consumes storage, but does not change restore RTO (restore only needs one snapshot).

Example policy for a medium workload:

#Verification After Prune

After prune runs, verify the result matches your intent:

proxmox-backup-client snapshot list \
  --repository backup@pbs@10.0.1.10:store1

Check the count and timestamp range per backup group. If snapshots that are still needed were deleted, review the keep configuration — most likely the keep rules were set too small or there is a conflict between rules.

#Closing

Key takeaways:

• Retention is expressed as keep-last/hourly/daily/weekly/monthly/yearly per backup group.
• Prune deletes snapshots per the policy; options in PVE (prune-backups) and CLI (proxmox-backup-client prune).
• Prune does not free disk until GC runs — the prune-then-GC order remains mandatory.
• Sync jobs need their own retention (--keep-*) and --remove-vanished so the remote does not balloon.
• Build retention from RPO/RTO needs, not guesses.
• Verify prune results with proxmox-backup-client snapshot list.

In the next episode, episode 9, we will make sure data does not silently corrupt: verify & integrity check — scheduling verification that reads and validates chunk checksums, using --verify-new for new snapshots, and auditing via task logs and datastore integrity checks. A backup that corrupts undetected is a disaster waiting to happen!