Check repository integrity

A repository can sit on a slowly failing disk for years, accepting new snapshots while old data rots underneath. Repository checks validate structure and can read stored data to detect damage — before the day you need that data back.

They complement, but do not replace, restoring usable files. A check proves the repository’s internal bookkeeping and bytes are intact. Only a restore drill proves you can turn those bytes into a working system.

Two levels of checking

Check the practice repository:

restic check
restic check --read-data-subset=10%

Plain restic check verifies the repository structure: it confirms every snapshot’s metadata is consistent and every data chunk that should exist is referenced correctly. It’s fast because it reads almost none of the actual data.

create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
no errors were found

no errors were found is the line you’re looking for.

The --read-data-subset=10% variant additionally downloads 10% of the stored data and verifies it against its checksums. This is what catches bit rot and truncated uploads — problems invisible to the structural check.

Schedule rotating coverage

Reading all data on every check would hammer a large repository and burn bandwidth on remote storage. Record duration and result for your repository, then design a schedule that eventually covers all stored data without overwhelming the backup target.

The subset syntax supports rotation directly:

restic check --read-data-subset=1/10   # week 1: first tenth
restic check --read-data-subset=2/10   # week 2: second tenth

Cycle through 1/10 to 10/10 and every byte gets verified once per ten weeks, at a tenth of the weekly cost.

When a check fails

Investigate failures before pruning or rewriting the repository. A failed check means the repository holds damage, and your instinct will be to “clean it up” — resist it. Pruning rewrites and deletes data, which can turn a partially damaged repository into a thoroughly broken one, and destroys the evidence of what went wrong.

Preserve evidence and another copy first: the error output, the affected files, and a second copy of whatever still restores. Then diagnose. Damaged repositories can often be partially recovered, but only if you didn’t rewrite them in a panic.