To backup important files on a Ubuntu 22.04 machine, I run a daily incremental backup via duply. The backup is stored on an external SFTP server, therefore I configured a GPG_KEY in duply, causing duplicity (version 0.8.12) to use private/public key encryption.
My backup chain started in May, and in June my GPG key expired. Therefore, I created a new key pair, and changed the key ID and passphrase in the duply configuration. What I did not consider was, that duplicity would not automatically start a new backup chain (one might expect that doing the incremental backup required to decrypt the list for files already backed up). Instead, older data was encrypted with key pair A, while newer data in the incremental backup chain was encrypted with key pair B. I assume, this is a bug related to https://gitlab.com/duplicity/duplicity/-/issues/147.
Now, I need to restore data from this mixed-key backup chain. duplicity tells me that my passphrase is incorrect and tells me about a key ID that I have never used (although the creation date fits the older key A).
Is there any chance to retrieve data from this backup chain? Should not be impossible ... just decrypt a part of the files with key A and the other part with key B. But how would I do that?
Edit
For some reason, restoring the data had worked a few days later (it seems the data is complete, although no files have been added or changed after the key change).
The only visible changes are (a) that duplicity did not spend a lot of time with copying the signature from the remote storage, the initial backups's signatures file is more then 2 GB large, and (b) it did not reject the old key's (key A) password. duplicity version is still 0.8.12, although some other libraries on the server have been updated in the meantime.
One possible explanation could be that a new backup caused duplicity to cache the signatures, and the program did not feel the need to retrieve encrypted data from the remote storage. It is also possible that other components caused the error, or that there was some unseen error during data transfer from the SFTP server. A mistyped password is highly unlikely, as that had been provided via KeePass in all trials.
