borg extract failed archive does not exist after repository was renamed

Not specified by the original author.

TL;DR

Borg addresses archives as repository, archive name pairs, so after a repository rename or move, the archive list lives under the new location and old scripts pointing at the old path see an empty or missing repository: list the archives in the repository at its current location, confirm the archive name's exact spelling, and update the extract command's repository path. The archive exists; the address being used for it does not.

borg extract failed "archive does not exist" after repository was renamed

Use this when

• The job or restore fails with this symptom: borg extract failed with archive does not exist after the repository was renamed.
• You are working on a borg extract after the repository was renamed or relocated 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

• An archive genuinely deleted by a prune under the old name, where the fix is restoring from a replica repository.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. List the repository at its current path and record the archives it actually contains. Verify: the real archive inventory is known
2. Compare the failing command's repository path and archive name against that inventory, including case and suffixes. Verify: the addressing difference is pinpointed
3. Update scripts and configs that embed the old repository path to the new location. Verify: all references use the current address
4. Run the extract again and confirm files restore from the named archive. Verify: the extract completes successfully

Variant phrasings

borg extract archive does not exist repository renamed

The verbatim phrasing.

borg archive not found after repo move update path fix

The path phrasing.

borg extract failed old repository location archive list

The inventory phrasing.

Compatibility: Borg backup repositories and archive addressing after renames

Why it happens

Renaming a repository changes every address pointing into it while changing none of its contents. Tools and scripts that memorised the old path report missing archives because, at the path they are querying, there is nothing, and the error is about the address, not the archive.

Edge cases / pitfalls

• Archive names with timestamps make near matches easy to confuse; list, then copy the name exactly.
• If the old path now hosts a new empty repository, borg may have initialised one there; check before assuming data loss.

Provenance

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

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

Thread query: borg extract failed "archive does not exist" after repository was renamed

TL;DR: Borg addresses archives as repository, archive name pairs, so after a repository rename or move, the archive list lives under the new location and old scripts pointing at the old path see an empty or missing repository: list the archives in the repository at its current location, confirm the archive name's exact spelling, and update the extract command's repository path. The archive exists; the address being used for it does not.

Not specified by the original author.

TL;DR

Extract exactly the selected archive, to its own directory, after checking available sandbox space against that archive's size: the agent filled the disk because it extracted every version it could see. List archives, choose the one the task names, estimate its extracted size from the archive's statistics, confirm the sandbox volume holds it with headroom, and extract only that archive, cleaning the sandbox as part of the job's end state.

agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one

Use this when

• The job or restore fails with this symptom: agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one.
• You are working on an agent extracting Borg archives for a restore test 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

• An investigation that genuinely needs two versions side by side for comparison, where the fix is extracting the two named ones after a space check, not all of them.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Review the extraction step and confirm it iterates all archives rather than addressing the selected one. Verify: the over-extraction mechanism is confirmed
2. Rewrite extraction to take an explicit archive name and refuse to run without one. Verify: extraction is addressed, not enumerated
3. Add a pre-extraction space check comparing the archive's stored size estimate with sandbox free space. Verify: space failure becomes a clean pre-check
4. Extract the selected archive into its own sandbox directory and verify the expected files are present. Verify: the intended version restores successfully
5. Add sandbox cleanup on job completion so extracted data does not accumulate across tests. Verify: the sandbox returns to its free baseline

Variant phrasings

agent filled sandbox disk extracting every borg archive version

The verbatim phrasing.

agent borg extract all versions selected archive space check fix

The selection phrasing.

restore sandbox disk full borg extraction loop agent

The disk-full phrasing.

Compatibility: Agent extraction of Borg archives into restore sandboxes

Why it happens

Extraction loops over archives are a natural shape for generated code, and each version of a large dataset is nearly a full copy, so the loop's cost is the whole repository's history written to one disk. Selection exists precisely to avoid paying that, and the space check converts a disk-full crash into a controlled refusal.

Edge cases / pitfalls

• Deduplicated archives share chunks in the repository but not on extraction; extracted size is the honest planning number.
• A sandbox shared across parallel tests needs per-test quotas or directories, not one common pool.

Provenance

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

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

Thread query: agent filled the restore sandbox disk by extracting every Borg archive version instead of the selected one

TL;DR: Extract exactly the selected archive, to its own directory, after checking available sandbox space against that archive's size: the agent filled the disk because it extracted every version it could see. List archives, choose the one the task names, estimate its extracted size from the archive's statistics, confirm the sandbox volume holds it with headroom, and extract only that archive, cleaning the sandbox as part of the job's end state.

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.