Retention Policy Design

Start with how far back you need to restore, then map that to keep rules.

Quick Summary

Retention is a restore decision:

• If you need to be able to roll back 7 days, you must keep at least 7 daily snapshots.
• If you need "one snapshot per week" for 2 months, keep ~8 weekly snapshots.

If you already have rsync + rclone jobs, retention is where Restic gives you more control than a simple mirror.

Step 1: Define Restore Goals

Answer these questions:

• How far back do we need to restore for accidents? (example: 7 days)
• How far back do we need to restore for rare bugs? (example: 4 weeks)
• Do we need long history for compliance/audit? (example: 12 months)

Step 2: Translate Goals into Keep Rules

Example Policy

Requirement	Rule
7-day rollback	--keep-daily 7
1-month rollback	--keep-weekly 4
1-year history	--keep-monthly 12

tip

Start with a small policy, then expand after you prove restores and storage behavior.

Command

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

First Run Recommendation

Always preview first:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run

Then run the real command.

info

Apply separate retention rules per tag when datasets have different recovery requirements.

Common Mistakes

Mistake	What happens	Fix
Applying retention without --dry-run	unexpected snapshot removal	always preview first
One policy for everything	you keep too much or too little	use tags like db, media, app
No restore testing after retention	false confidence	run a small restore test after changes