How to Tell Whether a Backup Failure Comes From the Repository or Source Files

Test repository reads independently from a small stable source, then test suspect source paths to a fresh disposable repository.

The decision matters when a backup stops with read, checksum, permission, pack, or index errors. The two competing states are repository or destination damage and source-file read, permission, or change errors. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Separate Repository Or Destination Damage From Source-File Read, Permission, Or Change Errors

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce a backup stops with read, checksum, permission, pack, or index errors.

The first candidate is repository or destination damage. The second is source-file read, permission, or change errors. The current Restic troubleshooting sequence defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Run One Controlled Discriminator

Use this discriminator: run repository check and a canary restore, then back up a fixed readable test set and separately inspect source errors. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use independent Restic workflow to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

restic check
restic restore latest --include /canary --target /tmp/restore-test

Interpret Which Branch the Evidence Supports

PASS: repository checks or restores fail across sources, or only specific source paths fail while the repository stays healthy. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: network and memory faults affect both tests, so reproduce locally before declaring either side damaged. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: freeze destructive maintenance, copy logs, and protect the last good repository state. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Apply the Matched Action and Reproduce the Original Failure

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when repository checks or restores fail across sources, or only specific source paths fail while the repository stays healthy across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the Restic pack sizing to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if network and memory faults affect both tests, so reproduce locally before declaring either side damaged, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the verification frequency so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For backup failure isolation, the remaining searches usually concern can a successful repository check prove source coverage, should the repository be repaired immediately, and what source errors are easy to miss. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: repository checks or restores fail across sources, or only specific source paths fail while the repository stays healthy. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when network and memory faults affect both tests, so reproduce locally before declaring either side damaged. At that point, freeze destructive maintenance, copy logs, and protect the last good repository state; preserve the evidence before escalating to the platform, storage, or hardware owner.

Can a successful repository check prove source coverage?

No. It proves repository properties, not that every intended source file was readable or included.

Should the repository be repaired immediately?

Not before making a safety copy where practical and confirming the failure class.

What source errors are easy to miss?

Permission denials, disappearing files, unreadable sectors, sparse files, and application-consistency problems can be hidden in summaries.

The diagnosis is finished when the same workload makes the evidence follow repository or destination damage or source-file read, permission, or change errors, and the matched action removes the original symptom without creating a second one. If neither branch stays repeatable, keep the logs and saved state intact; uncertainty is a reason to escalate, not to stack more fixes.