Restore and retention

Apply retention with care

Preview which snapshots a policy keeps, forget only reviewed history, and prune data in a separate controlled step.

10 minute lesson

~~~

Snapshots accumulate. Daily backups produce 365 recovery points a year, and most of them stop earning their storage after a few weeks. Retention controls storage growth while preserving useful recovery points. The danger runs the other way too: an overly aggressive policy can erase the last good version of something you haven’t noticed is broken yet.

The standard shape is tiered: keep every recent snapshot, then thin out with age. Recent history is dense because recent mistakes are the ones you discover.

Preview before deleting

restic separates deciding from deleting. Preview a simple policy first:

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

This keeps one snapshot per day for 7 days, one per week for 4 weeks, and one per month for 12 months. With --dry-run, nothing is deleted — restic prints two tables, keep and remove, with the reason each snapshot survives:

keep 11 snapshots:
ID        Time                 Reasons
------------------------------------------------
9c31de07  2026-08-03 03:00:01  daily snapshot
                               weekly snapshot
...
remove 23 snapshots:

Explain every retained and removed snapshot before dropping the flag. Apply forget only after the policy and current incident state are understood. If a snapshot you’d want is in the remove list, fix the policy now — the dry run is free, the mistake isn’t.

Forget, then prune, then check

forget only removes the snapshot records. The underlying data stays until you prune:

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

prune finds data no snapshot references anymore, repacks what’s partially used, and deletes the rest. Keeping it as a separate controlled step is deliberate: prune rewrites the repository, so you run it when things are calm, and you run restic check afterwards to confirm the repository is still healthy. Pruning on top of undetected damage makes the damage worse.

When not to prune

Do not prune during an active recovery or suspected compromise. Pruning removes unreferenced data and reduces options — including snapshots you just forgot in a hurry, which remain recoverable until prune runs. During an incident, storage cost is the cheapest problem you have. Freeze retention, finish the recovery, then clean up.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →