On 2021-08-24 03:21, edgar.soldin---
via Duplicity-talk duplicity-talk-at-nongnu.org |duplicity-talk|
On 24.08.2021 09:35, zga9uhnq4g--- via Duplicity-talk wrote:
Thanks for suggestions Edgar.
I get the same error "gpg: decryption failed: Bad session key" when trying verify/restore my backup from 2020-12-12.
Following the info in the link you mentioned, I tried manually decrypting via gpg. I found that I could decrypt all the incremental backups in the chain (at least all the ones I tried), but decrypting the original full backup failed with "gpg: decryption failed: Bad session key". Thinking back, I think I know what happened. That first full backup was executed interactively from the command-line, and I got prompted for the passphrase as copy/pasted it in. All the backup after that were executed from my backup script (that I schedule to run at 3:30, and there I use the PASSPHRASE environment variable. I was even able to confirm that (sort of) by looking in my .bash_history file. I had just about resigned myself to the fact that the first backup chain was useless, but I just came back after a couple hours, had an idea, and figured out the passphrase for that original full backup. As is common, my passphrase is words separated by spaces (e.g. the quick brown dog jumps),
so when I set PASSPHRASE (for some reason I don't remember) I used backslashes to escape the spaces (e.g. PASSPHRASE=the\ quick\ brown\ dog\ jumps). I discovered that when I run "gpg ... -decrypt ..." and when it prompts for the passphrase I type the passprhase with the backslashes it successfully decrypts.
So, as Edgar suggested, my duplicity backup does have two different passphrases, a first for the original full backup, and a second for everything else. Is there anyway to get duplicity to use the two passphrases correctly, or is my only option to manually decrypt the the 4 files (1 manifest, 2 difftars, and 1 sigtar) with the first passphrase and re-encrypt them with the second passphrase and then replace the 4 original files with the re-encrypted ones?
the manual re-encryption should do the trick. duplicity is not prepared for a user error like that unfortunately. for the future i strongly suggest to set the PASSPHRASE env var or use gpg-agent or even better key based auth, where that error is simply not possible.
Everything below describes my attempt to manually copy the backup from Microsoft OneDrive to Google Drive as Edgar suggested and get duplicity to recognize it. It was unsuccessful, and the behavior was strange and surprising, so I'm only describing it for folks that are curious. Feel free to skip this if your not interested, as it seems like a dead end.
I copied the entire backup folder from Microsoft OneDrive to Google Drive by dragging the folder from Windows Explorer in the Google Drive web page (took a couple hours), but when I tried "duplicity verify" pointing at the newly copied Google Drive folder, it said:
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
followed by a Traceback and ending with the exception:
duplicity.dup_collections.CollectionsError: No backup chains found
The strange thing is that it created a new empty folder in Google Drive, with the same name as the newly copied folder and right next to it. I also tried "duplicity collecton-status" and it said:
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/f509c410dcf8a9acb918e98cb707d4da
Found 0 secondary backup chains.
No backup chains with active signatures found
No orphaned or incomplete backup sets found.
and also created a new empty folder if it didn't already exist. Looking in the Google Drive web UI at the two folders, one created by manually copying a folder into the Google Drive web UI, and one created by duplicity, I can't see any differences. Very strange. I'll go back to trying to get "replicate" to work.
what's your complete duplicity verify command line for the old _and_ what for the new backend? ..ede/duply.net
Duplicity-talk mailing list