Deja-dup failling on google cloud recovery

Applications
1

Getting both types of recovery errors others have reported when using Gdrive for backup.
Today did fresh backup of user data before installing new SSD drive, followed by reinstall of Ubuntu 22.04

  1. tried recovery of user data with non Snap install of deja-dup. That failed with the known Pydrive apiclient error. Comments suggested that the snap version would work better
  2. installed Snap deja-dup. Now getting to the Gdrive I believe but now getting the known repeating ask for Password.
    Here are top and bottom lines from Debug file:
    System Details:
    OS=Ubuntu 22.04.1 LTS
    Desktop=ubuntu
    Locale=en_US.UTF-8
    Home=/home/fyh
    Version=44.0 (snap)
    Tool Name=duplicity
    Tool Version=1.0.1
    Snap Revision: 553

GSettings:
[org.gnome.DejaDup]
window-width=700
prompt-check=‘disabled’
backend=‘google’

…(skipping log info before today’s backup, then recovery attempt; Did the backup fail?)

INFO 1
. Added incremental Backupset (start_time: Fri Dec 23 15:20:09 2022 / end_time: Wed Dec 28 16:14:55 2022)

DEBUG 1
. Added set Wed Dec 28 16:14:55 2022 to pre-existing chain [Thu Oct 20 10:05:29 2022]-[Wed Dec 28 16:14:55 2022]

NOTICE 1
. Synchronizing remote metadata to local cache…

NOTICE 1
. Copying duplicity-full-signatures.20221020T140529Z.sigtar.gpg to local cache.

INFO 1
. Using temporary directory /tmp/duplicity-2l49he2f-tempdir

DEBUG 1
. Registering (mktemp) temporary file /tmp/duplicity-2l49he2f-tempdir/msrpbw-cgcqnrtp-y

INFO 1
. PyDrive backend: found file duplicity-full-signatures.20221020T140529Z.sigtar.gpg with id 1ytV4iBmLKvbmsNc9piPgz5un01xi0keC on server, adding to cache

DEBUG 1
. Registering (mktemp) temporary file /tmp/duplicity-2l49he2f-tempdir/qbsvml-htfq_iyd-k

DEBUG 1
. Releasing lockfile b /home/fyh/.cache/deja-dup/rnlpfphyhhnsbasbgibjovfjrtuohasa/lockfile

DEBUG 1
. Removing still remembered temporary file /tmp/duplicity-2l49he2f-tempdir/msrpbw-cgcqnrtp-y

DEBUG 1
. Removing still remembered temporary file /tmp/duplicity-2l49he2f-tempdir/qbsvml-htfq_iyd-k

INFO 1
. GPG error detail: Traceback (innermost last):
. File /kjdc/deja-dup/lal/kjf/uxmiubrqj , line 87, in
. with_tempdir(main)
. File /kjdc/deja-dup/lal/kjf/uxmiubrqj , line 70, in with_tempdir
. fn()
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/yrs_hedi.ej , line 1585, in main
. do_backup(action)
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/yrs_hedi.ej , line 1616, in do_backup
. sync_archive(col_stats)
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/yrs_hedi.ej , line 1393, in sync_archive
. copy_to_local(fn)
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/yrs_hedi.ej , line 1341, in copy_to_local
. tbo.aiemgrvkvgrad(wky_idor, jhb.gyoi, rigw=ylg.latuoax)
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/kom.nn , line 452, in GzipWriteFile
. new_block = next(block_iter)
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/yrs_hedi.ej , line 1321, in next
. xduc.efxutjk.sjeei()
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/phf_ldan.hc , line 232, in close
. assert not xduc.efxutjk.sjeei()
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/kom.nn , line 311, in close
. qcei.lfo_wdhqjo()
. File /kjdc/deja-dup/lal/mno/hdnxxkg.k/xyvg-npouumvv/uxmiubrqj/kom.nn , line 278, in gpg_failed
. raise GPGError(msg)
. mxscfjjrw.ibo.ygggjetd: GPG Failed, see log below:
. ===== Begin GnuPG log =====
. gpg: AES256 encrypted data
. gpg: encrypted with 1 passphrase
. gpg: decryption failed: Bad session key
. ===== End GnuPG log =====

ERROR 31 GPGError
. GPGError: GPG Failed, see log below:
. ===== Begin GnuPG log =====
. gpg: AES256 encrypted data
. gpg: encrypted with 1 passphrase
. gpg: decryption failed: Bad session key
. ===== End GnuPG log =====

Let me know if more info is needed?
Thanks, TG

1 Like
2

Hello! That looks like the normal gpg error for entering the wrong password.

So the question is: why does Deja Dup think you are entering the wrong password? I’m assuming you did encrypt your backup with a password. What system/deja-dup-version did you make the backup with?

I don’t yet suspect that a flaw in Deja Dup is preventing this restore, but you can also remove it from the equation by using duplicity directly. It’s a little annoying to drive duplicity while talking to Google Drive, but you can read the man page for options there. I can help talk you through that.

3

Thanks for the look. I agree it’s not a DD flaw but likely related to my general issues with snap and doing a reinstall of Ubuntu 22.04 (new hard drive) and ending up (I think) stranded between two versions of DD.

Same laptop, two user accounts backed up with DD to Gdrive, but apparently one w/ snap version (V. 42.9) and the other with apt install (V. 44)
I plan to reuse the old HD as a backup on a different machine. I can look at the /home/ dirs and see if I can tell which DD versions I used to do the backups before the new HD and new install of Ubuntu.

But here are the clues from the Restore after the fresh install of Ubuntu:

User A, Gdrive restore with Backup FE app (DD V. 44, worked flawlessly
I see that both /usr/bin/deja-dup and /snap/bin/deja-dup are V.44
The log file indicated 'snap V.44, revision 553 was used.

User B, Gdrive restore with Backup FE app (DD V. 42.9, @ /usr/bin/deja-dup) failed with the Pydrive client err

I saw that /snap/bin/deja-dup was V.44, and thought, “it’s failing maybe b/c I backed up with V.44. I also remember a note from mterry that said beware Gdrive protocol was changing in Sept. and things would break.”

So User B again, tried /snap/bin/deja-dup (V. 44) and that did find the Gdrive files, but then went into the PW loop.

I’m willing to do more looking if you have any suggestions where to look. When I originally searched on the errors, I did see others reporting both kinds (PW loop; Pydrive) of errors, so it might help others.

The reason I had multiple versions of DD on different accounts and machines is b/c others suggested removing the snap app as a way to clean up things.

What may help me in the future is a better understanding of whether installing/removing apps (eg DD) from my acct (has admin priv.) will do the same for the other user on the machine. Apparently it doesn’t.

  • Terry

PS
Do you have any strong opinions on whether to stick to snap installs for Ubuntu apps?

4

See if this explains my restore problems after a new HD and reinstall of Ubuntu:

  • Did the HD updates on 2 machines with two user accounts to backup/restore
  • Also at this time I was switching off of Snap installs
  • I assumed switching to flatpak Deja-Dup with my admin level acct would also affect the other user B acct (but not true)
  • after failing to restore user B with DD, I simply used the thumb drive I had
  • then I attempted a new backup - DD knew it was the first backup on the clean system
  • and then it told me it was missing a needed Pydrive python util and offered to install it for me!
  • and then everything worked fine
    So, when doing a first backup, DD can detect if it’s missing the python util. But if it’s doing a restore, it assumes you still have the same working DD and croaked b/c I had switched to a different package of DD.
    Can the Restore catch the error and offer to install the python util? I admit my case is mostly user error.
1 Like
5

Yay! I’m glad that you got things working again!

I’m not sure we got to the bottom of this yet though…

So the prompt to install the pydrive package should only need to happen if you’re using your distro’s version of deja-dup and they don’t provide it automatically. The snap and flatpak releases have it built-in. So they didn’t prompt because they didn’t need it.

So while it might have looked like that was the difference that fixed things, I think it might have been something else. But I’m not sure what that is…

6

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.