Restic retention policy: forget, prune, and safe schedules
Build a restic retention policy that keeps useful recovery points, previews deletions safely, and runs forget and prune without surprises.
Forget and prune do different jobs
The forget command removes snapshot records according to a policy. Data chunks referenced only by those snapshots remain in the repository until prune finds and removes unreferenced data. Running forget by itself changes the available recovery points without immediately returning all of their storage space.
The convenient form is forget with --prune, which applies the snapshot policy and then reclaims data. Prune can read repository metadata, rewrite partially used pack files, rebuild indexes, and delete obsolete objects. Budget more time, I/O, and object-store traffic for it than for listing snapshots.
What the keep counts actually mean
Keep-last preserves the newest n snapshots in a group. Calendar options choose the most recent snapshot in each occupied hour, day, week, or month. Keep-daily 7 therefore means seven days that contain snapshots. If backups failed for three days, an older snapshot can remain among those seven daily points.
The options are combined. A snapshot survives when it matches any keep rule, so the totals should not be added together. The newest snapshot may count as last, daily, weekly, and monthly at once. Calendar boundaries are natural boundaries: restic treats a week as Monday through Sunday and a day as midnight through 23:59.
Start from the loss you need to undo
A retention policy is a recovery decision. Keep-last covers recent rapid changes and gives you several attempts if the newest backup is bad. Daily and weekly points cover mistakes discovered later. Monthly points provide a sparse history for slower-moving corruption or record lookup.
A common policy keeps dense recent recovery points and progressively sparser daily, weekly, and monthly history. Size each tier from the loss window, delayed incident discovery, legal obligations, and the cost of proving that older snapshots still restore.
- Tie backup frequency to the acceptable amount of lost work.
- Keep enough recent snapshots to survive a bad deployment and a delayed alert.
- Retain older points for as long as corruption or deletion could go unnoticed.
- Check that the oldest surviving snapshot meets the intended recovery window.
Grouping can change the result completely
Restic normally groups snapshots by host and backup paths before applying a policy. That protects unrelated backup sets in one repository, but changing paths can create a new group whose snapshots are retained separately. Tags can also be used for grouping or filtering when a repository intentionally contains several jobs.
Inspect how existing snapshots are grouped by host and paths before choosing a policy. If paths vary for an implementation reason and all snapshots from a host belong to one stream, host-level grouping may be appropriate. Do not apply that choice to a shared repository until you have checked that it cannot mix unrelated jobs.
A safe operating sequence
Preview every new or tightened policy, inspect what would remain, and apply destructive maintenance only after a successful backup. Once prune removes the final chunks referenced by a forgotten snapshot, that recovery point is gone.
Monitor backup and maintenance separately. A new snapshot can exist even when pruning fails, while an overlapping maintenance window can still exhaust network, storage, or time budgets. Periodic restores remain the evidence that the surviving history is useful.
Retention is not ransomware protection
Credentials that can prune can also delete repository objects. If malware takes over the backup host and can use those credentials, a generous retention policy does not make the repository immutable. Object lock or an append-only copy can reduce that risk, but the maintenance design changes because forget and prune require full read, write, and delete access.
For higher-risk systems, keep an independent protected copy and run destructive maintenance from a separate, well-secured context. Be careful with lifecycle rules on a versioned S3 bucket: deleting a current object may leave an older version billable, and expiring provider versions too aggressively can defeat the protection you expected from versioning.
Technical basis
First-party references
Technical claims and limitations in this guide were checked against these primary sources. Confirm version-specific behavior when designing a production recovery process.
Related from Rested
Common questions
Frequently asked questions
What is the difference between restic forget and prune?
Forget removes snapshot references according to a policy. Prune removes unreferenced repository data and may repack partially used files, which is what reclaims storage space.
Does keep-daily 7 mean the last seven calendar days?
No. It keeps one snapshot for each of the last seven days that contain at least one snapshot. Use a keep-within-daily duration when you specifically need a time window rather than a count of occupied days.
How often should I run restic prune?
Run it often enough to control repository growth and within a maintenance window that can handle its I/O and storage traffic. Small repositories may prune after each successful backup; large repositories often separate pruning from the frequent backup schedule.
Can I undo restic forget --prune?
Do not assume so. Forget removes the snapshot and prune can delete its last referenced data. Preview policy changes with --dry-run, verify the removal list, and keep an independent protected copy for recovery from operator mistakes.
Why did restic keep more snapshots than expected?
The keep rules overlap and are applied per snapshot group. Different hosts, paths, or tags may create separate groups, with each group retaining its own set. Inspect the grouping shown by restic snapshots and forget before changing the policy.