Restic: Monitor Backups, Retention and Checks

A backup dashboard should tell you which business data you can recover and how old it is. Monitoring only whether the restic command ran can leave you with a reassuring status while a newly protected directory is unreadable, a job has stopped running, or retention has removed a recovery point you expected to keep.

Treat backup creation, repository verification, retention and restore testing as separate jobs with separate results. This makes a failure easier to interpret and prevents a successful cleanup from obscuring an unsuccessful backup.

Alert on the backup set you intended to create

Identify each set by its host, source paths and purpose. Decide its maximum acceptable age with the service owner. A daily configuration backup and an hourly order export should not share the same alert threshold simply because they use the same repository.

Restic's documented backup exit codes distinguish a successful run, a fatal error and a snapshot containing only the readable source files. In particular, code 3 means some source files could not be read. Other error codes also exist; automation should treat an unrecognised non-zero result as requiring attention. See the backup command documentation.

Store the result, snapshot identifier, finish time and relevant error details. Independently check that a suitably recent snapshot exists for every expected set. A monitor that receives only failure messages cannot report a machine that has stopped sending anything.

Also review exclusions when the application changes. Permission errors are visible when handled properly; a directory deliberately excluded months ago can be missing without causing an error. Add a harmless marker file to the intended scope during a planned check and confirm it appears in a restore.

Preview retention with real snapshot history

Restic separates removing snapshot references with forget from reclaiming unreferenced stored data with prune. Its retention policy normally groups snapshots by host and source paths, then applies the policy to each group. Changed paths, renamed hosts or altered grouping therefore deserve a review. The retention documentation also explains dry runs.

For example, this previews a policy without deleting snapshots:

restic forget --dry-run --keep-daily 14 --keep-weekly 8 --keep-monthly 12

Use your established repository and credential configuration. The numbers illustrate a review, not a universal retention recommendation. Check the actual retained dates for each group, including an inactive server and any unusually sparse backup history.

Give the service owner a concrete question: could we recover the state before last month's import, or before a mistake discovered after several weeks? Calendar retention rules do not create missing backups. The answer depends on the snapshots you actually have.

Keep pruning observable and give it adequate space and time. Do not introduce an emergency cleanup policy during a storage incident without first understanding what it will remove. Review capacity trends while there is still room to make a deliberate decision.

Check the stored data, then open a restore

A default repository check examines structural consistency. Reading and verifying the backed-up data requires additional options. Restic documents full data checks and subset checks in Working with repositories.

The full data check is:

restic check --read-data

It reads repository data and can consume significant time, bandwidth and retrieval charges. Schedule it accordingly. If you divide checks into subsets, record which portions were checked and when. Repeating a random sample does not demonstrate that every stored pack has been examined.

Integrity verification still does not establish that an application export was valid when captured. Restore a representative file set to a separate destination, open the files and run the application-specific checks. Include permissions and supporting configuration where they affect usability. Keep test restores restricted because they contain the same sensitive information as production.

Make the next failure actionable

An alert should name the affected set, its last complete snapshot, the time remaining before the recovery requirement is missed, and the responsible person. Include a link to the job log with secrets removed. Route persistent backup failures to someone who can change the schedule, credentials or source permissions.

Record exceptions with an owner and an end date. If a directory is temporarily excluded, the dashboard should describe the reduced coverage. Review the monitor after a host replacement, repository migration or credential rotation; those changes can leave an apparently healthy old job monitoring the wrong thing.

The useful weekly review is a short list of stale sets, incomplete snapshots, verification failures and overdue restore checks. Each item should lead to a specific repair or an explicit business decision about the data at risk.

References

• restic, Backing up. Accessed 17 October 2026.
• restic, Removing backup snapshots. Accessed 17 October 2026.
• restic, Working with repositories. Accessed 17 October 2026.