Can You Restore a Borg Repository After Its Cache Directory Is Lost?

Usually yes. Borg can rebuild local cache state from the repository, although the first operation can be slower and still requires the repository key and passphrase.

The decision matters when a client disk fails or its Borg cache directory is deleted while the repository remains intact. The two competing states are rebuildable local cache and missing encryption key, credentials, or damaged repository. 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.

Define the Conditions Behind the Borg Repository Use Without Local Cache Decision

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 client disk fails or its Borg cache directory is deleted while the repository remains intact.

The first candidate is rebuildable local cache. The second is missing encryption key, credentials, or damaged repository. The current Borg cache location 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.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: preserve the repository, provide keys, run a read-only list or info operation, then allow cache rebuild and extract a canary. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use Borg client state 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.

borg list /repo
borg extract /repo::archive path/to/canary

Interpret Pass, Fail, and Exception Results

PASS: archives list correctly and a canary restores after the cache is reconstructed. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: the repository cannot authenticate, checks fail, or keys existed only on the lost client. 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: stop writes, recover keys, and check a copied repository before repair. 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

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when archives list correctly and a canary restores after the cache is reconstructed across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the Borg maintenance windows 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 the repository cannot authenticate, checks fail, or keys existed only on the lost client, 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 immutable backup windows 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 Borg repository use without local cache, the remaining searches usually concern is the borg cache a backup of repository data, what must be stored separately, and should cache loss trigger compact or repair. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: archives list correctly and a canary restores after the cache is reconstructed. 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 the repository cannot authenticate, checks fail, or keys existed only on the lost client. At that point, stop writes, recover keys, and check a copied repository before repair; preserve the evidence before escalating to the platform, storage, or hardware owner.

Is the Borg cache a backup of repository data?

No. It accelerates operations and stores local state; repository archives remain the authoritative backup.

What must be stored separately?

Encryption key material, passphrase recovery, repository URL, and restore instructions.

Should cache loss trigger compact or repair?

No. First prove repository health and rebuild the cache; maintenance is a separate decision.

For Borg repository use without local cache, the practical answer remains conditional: archives list correctly and a canary restores after the cache is reconstructed. When the repository cannot authenticate, checks fail, or keys existed only on the lost client, stop writes, recover keys, and check a copied repository before repair; a partial success that cannot survive the original workload is not compatibility.