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

[zga9uhnq4g]

    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.
    
        thanks,
        Peter

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

Hi,

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.

...Ken

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
    lock.acquire()
KeyboardInterrupt:

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?

    thanks,
    Peter

_______________________________________________
Duplicity-talk mailing list
Duplicity-talk@nongnu.org
https://lists.nongnu.org/mailman/listinfo/duplicity-talk