Learning Restic - Forget & Prune (Retention Policy)

#Introduction

In episode 4 you started creating snapshots — and from this episode on, the snapshots keep growing. Backing up every day produces 365 snapshots a year; without a policy, the repository bloats and storage costs soar. Retention policy is the answer: deciding which snapshots deserve to live and which should retire.

The key is not technical, but business: how long you can afford to lose data (RPO) and how fast you must be back in operation (RTO).

#Forget: Managing the Snapshot History

restic forget removes snapshot metadata according to a policy. The most common example — 7 daily, 4 weekly, 6 monthly, 1 yearly:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --keep-yearly 1

Restic keeps the last snapshot of each period, so the maximum stored total is 7 + 4 + 6 + 1 = 18 snapshots per tag/path — not all 365.

#All the keep Options

restic forget \
  --keep-last 10 \
  --keep-hourly 24 \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --keep-yearly 1

The policy applies per combination of host + tag + path. That means snapshots tagged daily are counted separately from prod. Always tag consistently (episode 4) so the policy works as intended.

#keep-within & keep-tag

For time-based requirements:

restic forget --keep-within 30d

--keep-within 30d keeps every snapshot from the last 30 days (or 1y, 6m, 52w) — without the hassle of counting. Meanwhile --keep-tag protects specific snapshots from the delete policy, such as pre-deploy snapshots:

restic forget --keep-tag gold --keep-daily 7

#Setting Policy Based on RPO/RTO

• RPO (Recovery Point Objective): the maximum amount of data you can afford to lose. An RPO of 1 day means at least one snapshot per day.
• RTO (Recovery Time Objective): how fast the service must recover. A short RTO means more frequent backups + tested restores.

Example application: an e-commerce app needs an RPO of 15 minutes → snapshot every 15 minutes via cron with --keep-within 24h, then aggressive --keep-daily 7 --keep-monthly 6 for history. Archive data with a 24-hour RPO only needs --keep-daily.

#Prune: Cleaning Up Blobs

Forget only removes snapshot references. Old blobs stay stored until you run prune:

restic forget --keep-daily 7 --keep-monthly 6 --prune

Or separately:

restic prune

restic prune scans the whole repo, works out which blobs are referenced by no snapshot at all, and deletes them. This is a heavy operation (reads all indexes) — run it during quiet hours, and not too often; once a week or after a large forget is enough.

#Testing a Policy Without Deleting

Before executing a destructive forget, see first what would be removed:

restic forget --keep-daily 7 --keep-monthly 6 --dry-run

--dry-run shows the list of snapshots that would be deleted without deleting anything. Make this a habit — especially when composing a policy for the first time.

#Conclusion

• restic forget removes snapshot metadata according to the keep policy.
• Keep options: --keep-last/hourly/daily/weekly/monthly/yearly.
• --keep-within 30d for time-based policy; --keep-tag to protect important snapshots.
• Set the policy from RPO/RTO, not from available disk.
• --prune deletes unused blobs; do it periodically, avoid clashing with backups.
• Always --dry-run first before the first real forget.

In the next episode, episode 9, we bring it all together: backup automation with cron/systemd — a safe backup+forget+prune script (set -euo pipefail, lock file, logs), scheduling via cron and systemd timers, and verifying the backup result at the end of each run.