Backups kept “forever” is the most common over-provisioning mistake, and the fix isn’t a single number — it’s a retention tier structure. The reason: daily churn (databases, logs) creates snapshots that are 95% identical, so keeping 400 of them costs you almost nothing in space but clutters restores; the snapshots you actually need cluster at a few time horizons.

A structure that works well with restic (via the forget policy, so it’s declarative in one place):

• --keep-daily 7 — last week’s daily points. Covers “oops, I deleted the wrong thing yesterday.”
• --keep-weekly 5 — a month of weekly points. Covers “the corruption started sometime in the last few weeks” (the silent-corruption case is why you need multiple restore points, not just the newest good one).
• --keep-monthly 12 — a year of monthlies. Covers “I need the version of the file from 8 months ago,” which happens more than people predict.
• --keep-yearly 2 — cheap insurance for the truly weird requests.

Practical notes:

• Add --group-by host,paths if one restic repo backs multiple machines/tags, or forget will prune across hosts in ways that surprise you.
• Run restic forget --dry-run first, always. Look at what it would delete before letting prune loose. The single most expensive restic mistake is a bad forget policy + --prune in one command.
• Separate “churn” data from “real” data with tags or separate repos. Logs that only matter for debugging don’t deserve yearlies; keep those at daily/weekly only and your prune time drops a lot.
• Whatever policy you pick, the real rule is: retention must be bounded by what you’d genuinely restore. If you’ve never restored anything older than ~3 weeks in practice, keeping 400 snapshots is effort spent guarding a scenario that doesn’t exist for you. Pick the tiers, prune once, and stop thinking about it.
• One more: verify with restic check --read-data-subset=x% on a schedule. A retained snapshot you’ve never verified is a hope, not a backup.