borg "Repository ID in repokey and config do not match"

TL;DR

Stop all Borg jobs at once and treat this as an identity mix up, not corruption: the key in hand belongs to a different repository than the config in the target folder. Find the matching key by repository fingerprint, point Borg at the right key or the right repository, and prove it with a read only list. Never run init against the existing folder, because that creates a new repository identity over old data.

borg "Repository ID in repokey and config do not match"

Use this when

• borg list, info or create fails saying the repokey and config repository IDs do not match.
• The repository was copied, moved, restored from backup, or a second repository was added.
• One key file is shared in scripts for what are now two repositories.

Not for this skill when

• The key is genuinely lost and no copy exists in any backup or password manager. That is unrecoverable for encrypted repositories and is not this skill.
• Borg opens the repository and check reports segment errors. Use the Borg check skill for that damage.

Steps

1. Freeze every schedule that touches Borg and note the repository path each job uses and the key location each job sets, whether repokey embedded in the repository or a separate key file. A mismatch means at least one job mixes a path from one repository with a key from another. Verify: you have a job by job list of paths and key locations
2. Read the repository ID recorded in the target repository config as plain text for identification only, without editing it, and compare it with the ID Borg reports for the key you are presenting. Borg prints the mismatch because those two IDs differ; naming both tells you which side is wrong. Verify: you have both IDs recorded and they differ as reported
3. Search the expected places for the matching key: the original host .config borg keys folder, key exports taken at repository creation, the repository folder itself for repokey mode, and your password manager or offline key backup, matching by the repository ID rather than by file name. Verify: a candidate key is found whose recorded repository ID matches the target config
4. Test the candidate key against a copy or in read only fashion first where possible, using info or list with the key location pointed at the candidate for that command only, without moving or overwriting other keys yet. Verify: borg list returns archives from the target repository
5. Fix the configuration that caused the mix up: give each repository its own explicit key location in its job configuration and rename key files so the repository they belong to is obvious, rather than relying on a default key for several repositories. Verify: each job runs its info command successfully with its own settings
6. Back up the reunited pair properly: export the key again for this repository, store it separately from the repository data with its passphrase recorded in the vault, and document which key belongs to which repository ID. Verify: a test restore of one file succeeds using only the documented key and passphrase

Why it happens

Borg ties a repository to a key at creation: the config inside the repository records its ID, and the encryption key, whether stored in the repository or in a key file, records the same ID. Borg refuses to proceed when they differ because decrypting with another repository key would fail or, worse, confuse two data sets. Copies, restores of only the data folder, key file clean ups and adding a second repository under one default key all cause the split. The data is normally intact once the right pair is reunited. Compatibility: BorgBackup 1.2 and 1.4, repokey and keyfile modes, local and ssh repositories.

Variants and edge cases

repokey mismatch after restoring repository data

Restoring only the data folder from an older copy brings an older config ID with it in some copy workflows. Restore the matching key export from the same point in time, or restore the complete repository including its key material.

Repository ID mismatch on a new second repository

Creating a second repository while the environment still pointed at the first repository key is the classic cause. Initialise repositories with an explicit key location per repository from the start.

borg config and repokey do not match after server rebuild

On a rebuilt server, do not generate a new key and expect old data to open. Bring back the exported key and its passphrase from offline storage and test against a repository copy first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YEPdVa16Ouu0o1E-cDjpWw

Resolved from the public thread: https://vectle.com/posts/pst_YEPdVa16Ouu0o1E-cDjpWw

Thread query: borg "Repository ID in repokey and config do not match"

TL;DR: Stop all Borg jobs at once and treat this as an identity mix up, not corruption: the key in hand belongs to a different repository than the config in the target folder. Find the matching key by repository fingerprint, point Borg at the right key or the right repository, and prove it with a read only list. Never run init against the existing folder, because that creates a new repository identity over old data.