encrypted backup restore fails password correct

TL;DR

Stop retyping the password and check everything around it: the key version that encrypted that restore point, whitespace or keyboard layout changes in how the password is entered, and whether the backup header or key file is damaged. Test the same password against a different restore point from the same era, and against the escrowed key file, to separate a password problem from a key or data problem.

encrypted backup restore fails password correct

Use this when

• Restore or decrypt fails with a wrong password, decryption failed, or unable to decrypt message while the operator is confident the password is right.
• The password works on newer backups but not on an older restore point, or the reverse.
• A key file, recovery key, or escrow copy exists alongside the password.

Not for this skill when

• The password and all keys are genuinely lost with no escrow. That is unrecoverable by design and needs a data loss process, not troubleshooting.
• The backup is unencrypted and fails checksum. That is corruption, not decryption.

Steps

1. Freeze attempts: some products and key services lock or delay after repeated failures. Record the exact error, the restore point date, and the product version before trying variants. Verify: the error text and restore point are documented and no lockout is triggered
2. Confirm which key encrypted this point: check the job key history, key rotation dates, and whether the backup was re-encrypted or exported under a different key. Try the escrowed key or recovery key for that era, supplied through the vault or key file, not by typing variants. Verify: the key identifier recorded for the restore point matches the key you are presenting
3. Eliminate entry artefacts: paste the password from the vault into a test field that can reveal characters, check for trailing spaces, smart quotes from a copied document, and keyboard layout differences on the restore host. Verify: the entered value matches the vault value character for character with no added whitespace
4. Test across points: attempt a metadata decrypt or test restore of another point encrypted with the same key, and of a point from a different date. Verify: results separate one bad point from a wrong key for a whole era
5. Inspect the backup header and key material integrity: run the product check or verify on the archive, confirm the header and key data blocks read without errors, and try the restore on a host with the same or newer product version that supports the original algorithm. Verify: any header, algorithm, or version mismatch is named explicitly
6. If decryption succeeds with the escrowed key, rotate properly: document which key opens which era, re-escrow and test every key version, and update the restore runbook so the era to key mapping is recorded. Verify: a test restore from the oldest retained era decrypts with its documented key

Why it happens

A correct password can fail for reasons that have nothing to do with the password itself. Keys rotate: the password that protects todays job may unlock the key store, while an old restore point was encrypted under a previous key that was later replaced, and some products need that historical key present. Entry artefacts are common in incident conditions - passwords copied from tickets or documents pick up trailing spaces or changed characters, and a restore host with a different keyboard layout silently changes special characters. The encrypted header itself can be damaged, or the archive can use an algorithm or key derivation setting that an older or different restore tool does not support, both of which surface as the same generic decryption failed message as a genuinely wrong password. Products deliberately make these errors identical to avoid leaking information, so systematic isolation, not repeated typing, is the only way through.

Variants and edge cases

password works in console, fails from command line

Shell quoting, escaping, and environment handling commonly mangle special characters in passwords passed as arguments. Supply the password through the vault, a protected file, or an interactive prompt for the test, and compare results before concluding the key is wrong.

restore fails after product upgrade

Upgrades can drop or change support for older algorithms, key derivation counts, or archive formats. Check the vendor upgrade notes for encryption changes and test the old point with a restore host on the version that created it, in isolation.

key file present but rejected

The key file may belong to a different repository, era, or export, or may itself be truncated or copied in a text mode that altered it. Compare its identifier and hash with the escrow record, and never edit a key file to try to fix it. Edge cases: hardware and cloud key services add their own failure modes - a key that exists but is disabled, scheduled for deletion, or in a different region presents exactly like a wrong password from inside the backup product, so check key state in the key service directly. Also record character encoding when passwords are stored in documentation systems; a single smart quote has defeated more than one real restore. The standing lesson is to test decryption per key era on a schedule: discovering at restore time that only current era keys are escrowed and tested is discovering it at the worst possible moment.

Provenance

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