[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: Sun, 22 Aug 2021 22:47:34 -0700
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

Thanks for the hints Ken.  I did find lots of info talking about changes between gpg1 and gpg2, and when I "duplicity" to the search term, I found a bunch of duplicity-specific stuff basically saying the same thing, including https://askubuntu.com/questions/1057627/duplicity-fails-with-bad-session-key-error with an answer from Edgar.  I followed the links he mentioned, and tried the workarounds described in https://superuser.com/questions/984977/duplicity-restore-failing-no-secret-key, but they didn't help, so either I didn't do them correctly or my problem is different.

I'm skeptical that it could be a gpg1 versus gpg2 issue, since I started using duplicity 2020-12-12 and based on /var/log/apt/history.log, I had the gnupg and gpg* packages at version 2.2.20-1.  Later, on 2021-06-25, I upgraded these packages to version 2.2.27-2, but AFACT I never used a version earlier than 2.2.20.

I did some further testing using both "duplicity verify" and "duplicity restore" for the "latest" backup which succeed, and then using "--time 2020-12-12" to access my first backup which failed with the "Bad session key" error from gpg.  I then used --time to try verify/restore backups from 2021-08-01, 2021-07-01, 2021-06-01, etc., then narrowed failure down to a single day.  It appears that I can verify/restore all backups after 2021-02-10, but verify/restore fail for the backups on or before 2021-02-09.  I just figured out that I added "--full-if-older-than 1M" to the duplicity backup command in my backup script on 2021-02-08, so it took effect on the backup on 2021-02-09. so "duplicity collection status" shows
Last full backup date: Wed Aug 11 02:01:44 2021
Collection Status
Connecting with backend: BackendWrapper
Archive dir: /root/.cache/duplicity/770219317cf70c5a3236e3cb0d9a212c

Found 7 secondary backup chains.
Secondary chain 1 of 7:
Chain start time: Sat Dec 12 12:42:09 2020
Chain end time: Mon Feb  8 03:31:07 2021
Number of contained backup sets: 57
Total number of contained volumes: 58
 Type of backup set:                            Time:      Num volumes:
                Full         Sat Dec 12 12:42:09 2020                 2
         Incremental         Mon Dec 14 03:30:55 2020                 1
         Incremental         Sun Feb  7 03:30:51 2021                 1
         Incremental         Mon Feb  8 03:31:07 2021                 1

Secondary chain 2 of 7:
Chain start time: Tue Feb  9 03:31:06 2021
Chain end time: Wed Mar 10 03:31:24 2021
Number of contained backup sets: 30
Total number of contained volumes: 31
 Type of backup set:                            Time:      Num volumes:
                Full         Tue Feb  9 03:31:06 2021                 2
         Incremental         Wed Feb 10 03:31:06 2021                 1
Since, as you can see my backups run at 3:30, specifying "--time 2021-02-09" (as I did in the testing I described above) is actually accessing the backup set  from 2021-02-08, so my guess is that any access to the first backup chain (Secondary chain 1 of 7)  is producing the "Bad session key" error from gpg.

So now my real question is, is there any way to replicate my backup, but skip secondary chain 1 of 7.  The man page says "When --time time is given, only backup sets older than time will be replicated", which seems like the opposite of what I need.  Is my only option to run "duplicity remove-older-than 2021-02-09" and then do the replicate?

I would also still be interested in any suggestions for how I can make the backups from 2021-02-09 and before accessible again.


On 2021-08-21 13:53, Kenneth Loafman kenneth-at-loafman.com |duplicity-talk| wrote:

You might Google (not Bling)  "gpg: decryption failed: Bad session key".

It seems to have to do with gpg1/gpg2 differences.  You might try on a real Linux system and see if it works.


On Sat, Aug 21, 2021 at 3:38 PM zga9uhnq4g--- via Duplicity-talk <duplicity-talk@nongnu.org> wrote:
I've been using the Debian duplicity package version 0.8.20-1 in Windows Subsystem for Linux on Windows 10 Pro for 8 months to backup "important" windows files to my Microsoft OneDrive account, but it is running low on space so I want to switch my Google Drive account that has 3X space.

When I ran "duplicity replicate"  I got an error saying "gpg: decryption failed: Bad session key", but duplicity didn't exit.  I let it run over night, and finally interrupted it.
# duplicity replicate onedrive://Backup/finance.duplicity-direct gdrive://530054400480-6t6b9ul7l43hh8s1epq6cuehvd3ie2a2.apps.googleusercontent.com/finance.duplicity/?myDriveFolderID=1avphlf2LSwSmib6JaZIQRpXfPrAqsptu
Last full backup date: none
GnuPG passphrase for decryption:
Replicating b'duplicity-full-signatures.20201212T204209Z.sigtar.gpg'.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256.CFB encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====

^CException ignored in: <module 'threading' from '/usr/lib/python3.9/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 1428, in _shutdown
Duplicity did create the finance.duplicity folder in Google Drive, but it is empty.

I then ran "duplicity verify" and confirmed I can successfully read the OneDrive backup repository.
# duplicity verify onedrive://Backup/finance.duplicity-direct /mnt/d/home/pcanning/Finance
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Wed Aug 11 02:01:44 2021
GnuPG passphrase for decryption:
Verify complete: 817 files compared, 0 differences found.
Can anyone help me figure out why "duplicity replicate" is failing, and suggest how I might fix it?


Duplicity-talk mailing list

reply via email to

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