duplicity "GnuPG error: decryption failed"

TL;DR

Duplicity decryption failed almost always means the passphrase or key presented at restore does not match the key that encrypted the backup, or the agent and gpg setup picks the wrong keyring. Confirm which key encrypted the set, export the passphrase correctly for unattended runs, and test by decrypting a single volume file manually before retrying the restore.

duplicity "GnuPG error: decryption failed"

Use this when

• Duplicity restore or verify fails with GnuPG error decryption failed.
• The backup was made on another machine or by another user.
• Unattended restores fail while interactive ones prompt and succeed.

Not for this skill when

• The backend cannot be reached at all. Fix transport before cryptography.
• The passphrase is confirmed correct but volumes are corrupt. That is data damage, not key mismatch.

Steps

1. Identify the encrypting key from the backup metadata or the original job configuration and list keys in the current keyring. Verify: the needed key fingerprint is known and present or missing
2. Import the correct private key or set the passphrase environment for the restoring user, confirming the gpg agent configuration allows batch use. Verify: the key appears in the secret key listing for that user
3. Download one small volume from the backup set and decrypt it manually with gpg to prove the key works outside duplicity. Verify: manual decryption succeeds
4. Run duplicity verify on the set, which exercises decryption across volumes without writing restored files. Verify: verify completes or names a specific bad volume
5. Run the full restore with the corrected key setup. Verify: the restore completes and files are readable

Variant phrasings

duplicity decryption failed wrong passphrase

The passphrase-cause phrasing.

duplicity gpg decryption failed restore key

The keyring variant.

duplicity PASSPHRASE restore failed

The environment variable wording.

Compatibility: Duplicity 2 and 3 with GnuPG 2.4, local, S3 and SFTP backends, symmetric passphrase and public key encryption.

Why it happens

Duplicity encrypts each volume with GnuPG before upload, so restore success depends entirely on presenting the same secret later. Keyrings are per user, agents cache passphrases differently for interactive and cron contexts, and a similar-looking passphrase with a trailing space or different encoding fails silently into this generic error.

Edge cases / pitfalls

• Test restores after any key rotation. Rotating without re-encrypting or keeping the old key breaks old sets.
• Store the passphrase or key backup with the backup set documentation, protected separately from the data.
• A manual gpg decrypt that asks for a different key id reveals the set was encrypted to another recipient.

Provenance

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

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

Thread query: duplicity "GnuPG error: decryption failed"

TL;DR: Duplicity decryption failed almost always means the passphrase or key presented at restore does not match the key that encrypted the backup, or the agent and gpg setup picks the wrong keyring. Confirm which key encrypted the set, export the passphrase correctly for unattended runs, and test by decrypting a single volume file manually before retrying the restore.