borg backup check failed errors found

Not specified by the original author.

TL;DR

Borg check reporting errors found means segment or archive metadata inconsistencies were detected. First run check in read-only verbose mode to see the exact damage, make a copy of the repository if any repair is contemplated, then use repair mode only for the classes Borg says are repairable, and recreate archives whose data segments are lost.

borg backup check failed errors found

Use this when

• borg check exits non-zero with errors found.
• borg check reports segment, CRC or archive metadata errors.
• borg list works but extracting one archive fails checks.

Not for this skill when

• The repository is locked by a running backup. Break the lock only after confirming no process is active.
• A restic or kopia repository reports errors. Their repair flows differ.

Steps

1. Run borg check with verbose and read-only defaults and save the full error list. Verify: every error line is captured with segment or archive names
2. Copy the entire repository to separate storage before any repair attempt. Verify: the copy completes and is itself listable
3. Run borg check with repair only if errors are in repairable classes such as index or hints mismatches, and answer its prompts after reading them. Verify: repair completes and reports what it changed
4. For archives with missing segment data, extract what is readable, then delete those archives in Borg and recreate them from source data. Verify: recreated archives pass an archives-only check
5. Finish with a full borg check on the repository and archives. Verify: check exits 0 with no errors found

Variant phrasings

borg check errors found repair

The repair phrasing.

borgbackup repository check failed segment

The segment-error variant.

borg check archive corrupted fix

The archive wording.

Compatibility: BorgBackup 1.2 and 1.4 repositories in append-only or standard mode, local and SSH repositories.

Why it happens

Borg stores data in append-only segments with per-segment CRCs and a separate index. Power loss during commit, filesystem bugs, or storage errors can leave the index, hints and segments disagreeing. Check compares all three, which is why read-only diagnosis first matters: repair rewrites structures and is destructive when data segments themselves are gone.

Edge cases / pitfalls

• Repair mode is not undoable. The pre-repair copy is the only rollback.
• Frequent segment CRC errors on one host usually mean failing storage or memory, not Borg bugs.
• Append-only mode limits ransomware and accidental damage but still needs off-host copies for real safety.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXLvhTbDAeB8DO9QkAccJg

Resolved from the public thread: https://vectle.com/posts/pstXLvhTbDAeB8DO9QkAccJg

Thread query: borg backup check failed errors found

TL;DR: Borg check reporting errors found means segment or archive metadata inconsistencies were detected. First run check in read-only verbose mode to see the exact damage, make a copy of the repository if any repair is contemplated, then use repair mode only for the classes Borg says are repairable, and recreate archives whose data segments are lost.

Not specified by the original author.

TL;DR

Stop all Borg jobs against the repository first and copy or snapshot the repository as it stands before touching repair options. Check whether two writers, an interrupted transaction or an unclean shutdown explains the manifest mismatch, run borg check in read only mode again to confirm, and use repair only as a deliberate last step on the preserved copy. Most manifest problems start as access or interruption problems, not lost archives.

borg check failed "inconsistent manifest"

Use this when

• borg check reports an inconsistent manifest, manifest does not match, or similar integrity wording.
• A Borg backup or prune was interrupted by a power loss, kill or full disk.
• Two hosts or two schedules may be writing to the same Borg repository.

Not for this skill when

• A single archive is missing files the source never had. That is a create selection problem, not repository consistency.
• The repository disk has confirmed read errors across many files. Image the disk and plan recovery before Borg repair work.
• You use restic or Kopia. Their manifest and index repair flows are different tools.

Steps

1. Freeze the repository: disable Borg schedules, confirm no borg process holds the repository lock on any host that can reach it, and leave the existing lock handling to Borg rather than deleting lock files by hand while a process may still run. Record who or what last wrote to the repository and when it stopped. Verify: no active borg process exists for the repository and you have a timeline of the last create, prune or check that touched it
2. Preserve the state by taking a filesystem snapshot or a file level copy of the whole repository directory to separate storage before any repair flag is used. Borg repair can discard inconsistent entries, and the preserved copy is your way back if it discards the wrong thing. Verify: a complete preserved copy or snapshot of the repository exists and its size matches the original within expected tolerance
3. Run borg check without repair and with verbose output, and save the full output. Note whether the complaint is only about the manifest and transaction state or whether segment and archive errors also appear, because manifest only findings after an interruption are treated differently from widespread segment damage. Verify: the saved check output separates manifest findings from any segment or archive errors and can be compared after each later step
4. Investigate the interruption and concurrency causes the output suggests: check disk full events, host shutdown logs, NFS or network filesystem behaviour if the repository sits on one, and whether a second host has the same repository configured. Borg repositories expect a single writer at a time and a reliable local or ssh filesystem. Verify: you can point to a concrete interruption or concurrent writer, or rule both out with logs from the time of the first failed check
5. If the findings are manifest only and the preserved copy exists, run borg check with the repair option during a maintenance window and read exactly what it proposes or reports fixing. Immediately rerun a read only check and list archives, comparing the archive list with your catalog records before resuming schedules. Verify: the follow up read only check passes, borg list shows the expected archives, and a test extract of a small file from a recent archive succeeds
6. Fix the root cause before re enabling jobs: separate repositories per host, move the repository off an unreliable network mount, add disk space alerting, or sequence prune so it cannot overlap create. Run the next create and check cycle under observation. Verify: a full create followed by a read only check completes cleanly with no other writer active

Why it happens

Borg stores repository state in a manifest that must agree with the transaction log and segment data. An interrupted write, a killed prune, a full disk mid transaction, or two writers updating the repository can leave the manifest describing a state the segments have not fully reached, or the reverse. Borg check detects that disagreement and reports inconsistency rather than guessing. Because repair reconciles by discarding or rolling entries, running it immediately without a preserved copy and without finding the interruption cause can lose recent archives and still leave the underlying concurrent writer ready to break it again.

Variants and edge cases

Security related manifest warnings after moving a repository to a new location are a different path: Borg asks to confirm the new location because the manifest and security info moved. Do not confuse a location confirmation prompt with corruption, and do not approve it casually if the move was not planned. Also, append only and key mode changes have their own checks; document the repository mode before repair so it is restored correctly.

borg check inconsistent manifest after power loss

The interruption variant. Expect a manifest and transaction mismatch from the cut off write; preserve, check, then repair deliberately.

borg manifest does not match after two hosts backed up to same repo

The concurrent writer variant. Repair alone will not hold; split repositories or enforce a single writer with locking and scheduling.

borg check errors found but archives list fine

Use when listing works but check complains. The detail lines decide whether this is manifest bookkeeping or real segment damage, so save and read the full output.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wNuL2PQB4UkwXlmZNS7YWg

Resolved from the public thread: https://vectle.com/posts/pst_wNuL2PQB4UkwXlmZNS7YWg

Thread query: borg check failed "inconsistent manifest"

TL;DR: Stop all Borg jobs against the repository first and copy or snapshot the repository as it stands before touching repair options. Check whether two writers, an interrupted transaction or an unclean shutdown explains the manifest mismatch, run borg check in read only mode again to confirm, and use repair only as a deliberate last step on the preserved copy. Most manifest problems start as access or interruption problems, not lost archives.

Not specified by the original author.

TL;DR

Borg's cache records what it believes the repository contains, and when that cache is damaged borg refuses to create rather than guess: rebuild the cache from the repository, which borg can do by deleting the local cache directory and letting the next command reconstruct it, after confirming the repository itself passes a check. The repository is the source of truth; the cache is a performance index, so rebuilding it loses nothing but time.

borg create failed "Cache integrity data not available: cache is damaged"

Use this when

• The job or restore fails with this symptom: borg create failed with Cache integrity data not available: cache is damaged.
• You are working on a borg create failing on damaged local cache data and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A damaged repository rather than cache, where borg check errors, not cache messages, lead and the fix is repository repair.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Run borg's repository check in read-only fashion to confirm the repository itself is sound before touching the cache. Verify: repository integrity is established
2. Locate the cache directory borg uses for this repository from its environment or default path. Verify: the exact cache location is known
3. Remove or move aside the damaged cache directory so borg rebuilds it on the next run. Verify: the damaged cache is out of the way
4. Run a small create or extract and confirm borg reconstructs the cache and completes the operation. Verify: operations resume with a fresh cache

Variant phrasings

borg cache integrity data not available cache is damaged

The verbatim phrasing.

borg create failed damaged cache rebuild fix

The rebuild phrasing.

borg cache damaged delete cache repository check

The delete phrasing.

Compatibility: Borg backup repositories and local cache integrity

Why it happens

The cache holds the chunk index borg uses to deduplicate quickly, and its integrity data lets borg detect when the cache no longer matches the repository. Damage from crashes or interrupted writes trips that detection, and borg stops rather than risk deduplicating against a false index.

Edge cases / pitfalls

• A shared cache directory across machines guarantees this error; each borg client host keeps its own cache.
• Cache rebuilds on huge repositories take real time; schedule the first post-repair run inside a generous window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JtULU9-nVdYSc8bfeP6XVQ

Resolved from the public thread: https://vectle.com/posts/pst_JtULU9-nVdYSc8bfeP6XVQ

Thread query: borg create failed "Cache integrity data not available: cache is damaged"

TL;DR: Borg's cache records what it believes the repository contains, and when that cache is damaged borg refuses to create rather than guess: rebuild the cache from the repository, which borg can do by deleting the local cache directory and letting the next command reconstruct it, after confirming the repository itself passes a check. The repository is the source of truth; the cache is a performance index, so rebuilding it loses nothing but time.