Learning Restic - Check & Integrity Verification

#Introduction

Episodes 9 and 10 made backups run automatically. But there is a deeper question: how do we know a backup is correct? A snapshot that shows up in the list is not necessarily restorable — bit rot, silent disk failures, or missing blobs can damage the repository without any symptoms until a restore is needed.

Verification is not optional; it is part of the definition of "a working backup". This episode gives you the tools and the schedule to prove it.

#restic check: Repository Consistency

The first command checks the logical structure of the repository:

restic check

Check output

load indexes
check snapshots, trees and blobs
no errors were found

restic check makes sure: all indexes are readable, every snapshot references a valid file tree, every referenced blob exists, and no blob is missing. This is fast because it does not read the full blob contents.

#check --read-data: Verifying All Data

The basic check does not detect blobs that are corrupted but still present — for example a disk that stored wrong bits. For that, re-read and verify the MAC of every blob:

restic check --read-data

This downloads/reads all blobs and verifies their checksums — expensive (hours for large repos), but it is the only way to prove the data is truly intact.

#read-data-subset for Large Repos

Large repos cannot be fully --read-data checked every day. Split it into parts:

restic check --read-data-subset=1/7

Schedule the 1/7 subset daily — the entire repository is verified within a week without a single overbearing run.

#Periodic Scheduling

Add to the automation script from episode 9:

• Every backup: restic check --quiet — fast, catches structural corruption.
• Weekly: restic check --read-data-subset=1/7 — rotate the subset daily.
• Monthly: a full restic check --read-data during quiet hours.

#Auditing with restic cat config

For deeper audits, peek at the repository metadata:

restic cat config

version: 2
id: 2223e26e6b...
chunker_polynomial: "xxxxxxxx"
compression: "auto"

Note compression: "auto" — confirmation of the default compression from episode 6, and version: 2 shows the repository format version. This is useful when investigating compatibility issues between restic versions.

#Restore Drill: The Real Test

The best verification is an actual restore to another host on a regular basis:

restic restore latest --target /var/restore-test
diff -r /var/restore-test/var/www /var/www
rm -rf /var/restore-test

Testing on a different host validates that the restored files actually work outside the source host — not just matching bytes. Add a "database dump can be restored" step (pg_restore/mysql <) as a drill for episode 10.

#Conclusion

• restic check: verifies repo structure (index, snapshots, referenced blobs).
• --read-data: reads and verifies every blob — proof the data is intact.
• --read-data-subset=1/7: incremental verification for large repos.
• Schedule: --quiet every backup, a subset daily, full monthly.
• restic cat config: audits repo metadata (version, compression).
• A restore drill to another host is the real test; check detects, it does not fix.

In the next episode, episode 12, we move restic into the modern environment: restic on servers/containers — the restic/restic image with volume mounts, the sidecar pattern in Kubernetes, and building a rest-server for multi-host with HTTPS authentication + htpasswd.