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

[edgar . soldin]

hey Peter,

On 23.08.2021 07:47, zga9uhnq4g--- via Duplicity-talk wrote:
> 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.

the solution, issue/workaround described is an upgrade from gpg 2.0 to 2.1+ . 
but the error actually just says "wrong or no password given"

my guess is that you managed to modify the password used to gpg encrypt your 
backup between chains.

what is the exact error when trying to restore your backup from 12.Dec.2020 ?

> 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.

sounds reasonable

> 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 am not really sure why replicate as functionality was added to duplicity, 
especially that way (recompressing,reencrypting), but what you can easily do is 
just move/copy the files on the backup repo to another backend and change the 
target for duplicity (use e.g. rclone).

the backup files are named pretty conclusively, so sorting them by name should 
allow you to identify chains/backups. when you did that you can e.g. simply 
move the "broken" chain into another folder, out of the way and replicate 
should magically work. but again, no need to replicate at all if you want to 
keep encraption/compression as is. simply copy the files and run a verify 
against the new backup repo after and you are all set!

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

as asked above.  what's the exact error? if it is still "gpg: decryption 
failed: Bad session key" then you could try to find out if it's a duplicity bug 
or gpg issue (wrong passphrase, passphrase not routed to process) by fetching a 
gpg volume from the offending chain and simply trying to decrypt manually via 
gpg to /tmp or such just to pinpoint the issue. see 
https://wiki.gnome.org/Apps/DejaDup/Help/Restore/WorstCase#Restoring_by_Hand

good luck.. ede/duply.net