duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] decryption failure in duplicity replicate


From: edgar . soldin
Subject: Re: [Duplicity-talk] decryption failure in duplicity replicate
Date: Tue, 24 Aug 2021 12:21:46 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1

hey Peter,

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:
> 
>     Collection Status
>     -----------------
>     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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]