[Top][All Lists]

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

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

From: zga9uhnq4g
Subject: Re: [Duplicity-talk] decryption failure in duplicity replicate
Date: Wed, 25 Aug 2021 01:26:22 -0700
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

Okay, I tried re-encrypting the 2020-12-12 files and copying them back to OneDrive, but when I ran "duplicity verify --time 2020-12-12 ..." I got
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Aug 11 02:01:44 2021
Invalid data - SHA1 hash mismatch for file:
 Calculated hash: bcac07d8b88aeff2b928090c35db072fe1444f47
 Manifest hash: 0529e8d2384b24dec4d771f50dacca7d585188f8
So must have done something wrong.  The command I used to reencrypt was
gpg2 --symmetric --cipher-algo AES256 $file
Do I need to give more or different option to gpg?

    Peter Canning

On 2021-08-24 03:21, edgar.soldin--- via Duplicity-talk duplicity-talk-at-nongnu.org |duplicity-talk| wrote:
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
Duplicity-talk mailing list

reply via email to

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