A backup becomes evidence when a clean restore can be inspected
A successful backup job answers a narrow question: did that job report success? It does not, by itself, show that the intended files entered the archive, that recovery credentials are available, that a clean destination receives the expected bytes, or that the recovered application state is usable.
A stronger review starts from the restore claim and works backwards. The useful deliverable is not a green icon. It is a bounded record connecting a named source fixture, one archive identity, an isolated destination, observed outputs, differences, and a reviewer’s verdict.
This is a planning method, not a restore report. BorgBackup was not installed or run for this article. No archive, key, repository, private path, or production data was inspected, and no restore result is claimed.
Build a restore evidence chain
Treat recovery as six separate stages. A pass at one stage cannot silently stand in for the next.
| Stage | Question the evidence must answer | What it does not establish |
|---|---|---|
| Source scope | Which exact files and metadata were intended, and from which working-directory shape? | That the archive contains them. |
| Archive identity | Which repository and archive revision is under review? | That chunks are readable or complete. |
| Integrity check | Which check mode completed, and was file data cryptographically verified? | That extraction writes the expected tree. |
| Recovery material | Are the required key material and passphrase roles recoverable through separately governed custody? | That secrets should appear in the evidence record. |
| Isolated extraction | Was extraction directed into a newly created, empty restore root? | That bytes and metadata match the source. |
| Review | Do inventory, hashes, metadata, and application-level checks support the stated verdict? | A general disaster-recovery guarantee. |
The return paths matter. A missing item in the restored inventory goes back to source selection or archive creation. A hash mismatch goes back to archive identity, integrity evidence, or extraction. Ownership or mode differences require an explicit metadata decision. An application that cannot open the recovered state remains unresolved even when file hashes match.
A hand-authored example, not an executed result
Imagine a synthetic fixture with notes/alpha.txt, config/settings.json, and a relative symlink. Its proposed source manifest records paths, file hashes, modes, link target, and a manifest hash. The restore record names a separate empty destination and reserves fields for the resulting manifest.
If the restored text files hypothetically match but the symlink is absent, the record must not say “restore passed.” It should say which byte checks matched, identify the missing link as an exception, and leave the final verdict unresolved until the intended metadata contract is reviewed. This example was deliberately written for explanation; no parser, archive command, manifest comparison, or restore was executed.
Keep tool evidence precise
The current Borg 1.4 documentation separates several useful facts:
borg checkis read-only by default. Its data-verification mode reads, decrypts, decompresses, and cryptographically verifies file data, but it can be expensive. A record should say whether that mode was used rather than merely saying “check passed.”borg extract --dry-runexercises archive reading without writing restored files. It is useful preflight evidence, not an actual extraction.- Normal extraction writes relative to the current working directory. A reviewed exercise therefore needs an explicitly separate, empty restore root and evidence of that boundary.
- Key export and passphrase custody are distinct. The exported Borg key does not include its passphrase, and changing a passphrase does not replace underlying secrets that may already have been compromised.
Repair mode is deliberately outside this method. Upstream documentation describes it as potentially lossy. A public worksheet should not normalize a destructive recovery action as a routine verification step.
Record a bounded verdict
Download the blank restore-proof worksheet. Leave evidence fields blank until an authorized exercise produces them. Use not evaluated where a layer was intentionally omitted; do not convert absence into success.
A useful verdict can be narrower than “pass”:
- Supported: every declared check has bounded evidence and no unresolved exception.
- Supported with exceptions: the record names differences and the exact claim they limit.
- Unresolved: evidence is missing, contradictory, or awaiting human review.
- Failed: a declared acceptance condition was not met.
Even a fully supported file-level record does not prove recovery time, remote availability, retention adequacy, application consistency, or fitness for a particular threat model. Those are separate claims with separate evidence.
Primary sources:
- Borg 1.4 create documentation
- Borg 1.4 check documentation
- Borg 1.4 extract documentation
- Borg 1.4 key documentation
- BorgBackup releases
- BorgBackup security policy
The evidence chain, return paths, fictional fixture, worksheet, and verdict model are original. The linked sources support only the attributed Borg command and custody behavior.