A backup job that exits zero is a claim, not a result. It says the process reached the end. It does not say the repository opens, the data is readable, or the application can come back. The only evidence is a restore you have performed.

The commands here use restic because its verbs are explicit: check, restore, forget, prune. The same questions apply to Borg, Kopia or an appliance.

What the job proves

A successful run proves the client could read its source and write its target. That is narrow. The repository can still contain a damaged pack file. The source can be a database copied while it was running. The target can be a USB disk on the same shelf as the server. The password can be in a note on the machine that died.

restic separates the cheap check from the expensive one. A plain restic check verifies snapshots, trees and blobs without reading every pack file. Adding --read-data reads every pack file; --read-data-subset=10% reads a sample. The documentation is clear that --read-data downloads all pack files, so it is not a free background task.

Know which question each command answers, and run the one that catches the failure you are exposed to. The most thorough check is not automatically the right weekly task.

The restore drill

Pick a file you would miss: a photo, a config file, a database dump, a document with a checksum. List the snapshots, find the file, and restore it to a temporary path:

restic -r /srv/restic-repo snapshots
restic -r /srv/restic-repo ls SNAPSHOT_ID
restic -r /srv/restic-repo restore SNAPSHOT_ID --target /tmp/restic-drill --include /srv/app/config.yml

Replace SNAPSHOT_ID with the ID from restic snapshots. latest only works when the newest snapshot is the one that contains the file; in a repository with more than one host or job, it often is not. Confirm the path with restic ls SNAPSHOT_ID before restoring.

The include path is the path inside the snapshot, not the path on the current machine; restic ls prints the paths as the repository sees them. Compare the restored file with the live copy or a checksum you recorded before the failure. Open it. A byte-identical file that no application can parse is still a failed restore.

Then repeat the drill with the copy you would actually need after a disaster. That usually means the offsite repository, not the local one. Restoring from the local disk tests the easy path. The offsite restore tests the path you will use when the disk, the host or the room is gone.

Restore the service directory into a throwaway VM or container, point it at the restored data, and start it. Look for the missing environment file, the changed file ownership, the hard-coded path and the order in which the services have to start. A checksum will not find those.

If the service has a database, restore it through its own dump or export path. A file-level copy of a live database is not a consistent application backup.

The failures worth designing around

The first is a second copy that is not independent. Another directory on the same disk is not a second copy. A NAS in the same room is better, but it shares the power, the network and the fire. Three copies, two kinds of media, one offsite is still a useful shorthand; independence matters more than the numbers.

The second is a backup the compromised host can delete. If the client runs on the host and its credentials can remove snapshots, ransomware with the same access can remove them too. An append-only or immutable target, or a separate host that pulls the backup, changes that. Read restic’s append-only caveats before assuming a retention policy protects you.

The third is the recovery kit. The repository password, the storage credentials, the exact restic version, the repository URL and the restore notes need to live somewhere other than the machine being backed up. A backup you cannot decrypt is a large random number. Test the kit on a machine that is not the backup host.

The fourth is retention. forget removes snapshots; prune removes the data only those snapshots referenced. The documentation recommends check after pruning and warns that prune locks the repository, so keep it out of the backup window. A policy like --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune is a starting point, not a universal answer. The right policy still has a copy old enough to survive the mistake you have not noticed yet.

What to automate

Automate the cheap checks and one small restore. A weekly check --read-data-subset=10% samples a random tenth of the pack files; damage in the unsampled rest can go unnoticed, so treat it as a smoke test. A monthly or quarterly --read-data is the deeper pass. A weekly restore of one known file, logged and alerted on failure, is worth more than another dashboard.

Measure the restore: the time, the lookups, the missing kit items. Write those answers down. The next drill gets faster, and the gaps stop being surprises.

The backup job starts the recovery path; the restore finishes it. A copy you have never restored is a hope with a cron entry.

Source: the restic documentation on checking a repository, restoring from a snapshot, and removing snapshots.