Unable to restore backup from Google Drive

Bug #1875255 reported by Fernando
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Déjà Dup
Won't Fix
Undecided
Unassigned

Bug Description

I first experienced this in a Fedora machine, and now I noticed it when testing Ubuntu Focal Fossa (I do this with new LTS releases in order to report bugs so that I can safely update when the first minor release comes out;)). Let me almost copy what I said in the Fedora bug tracker (https://bugzilla.redhat.com/show_bug.cgi?id=1823023 my first thought was that it may have to do with Fedora packaging, but it doesn't seem to be the case since it's also happening in Ubuntu):

1. The distribution of Linux you're using:

Fedora 31
Ubuntu 20.04

2. The version of deja-dup and duplicity:

In Fedora: 40.6 and 0.8.12, respectively.
In Ubuntu: 40.6 and 0.8.11, respectively.

Just noticed I should upload some files. Let me come back to this later as I have to change machines.

How reproducible:

Trying to restore a remote backup with all my files.

Steps to Reproduce:
1. Sign in with Google in GNOME online accounts.
2. Go to Deja Dup and say restore from Google drive, indicating the correct folder.

Actual results:

It starts searching for backups until it gives up after a long, long time.

Expected results:

I'd expect to find the backup and restore it, after asking for the password.

Additional info:

It seems to me it doesn't pick the Google account from GNOME, nor it asks for it, unlike what happens if I try to start a new backup. In that case, after entering my data, the browser opens so that I authorize Deja Dup to access my google account. I should say that the flatpak and snap packages exhibit the same behavior. In general, I'm able to restore the backup if I download the files from Google and restore from a local folder, also if I mount Google Drive in Nautilus. Restoring directly with duplicity also works. I'm not having any issue in by Ubuntu Bionic machine.

Fernando (fmuro)
description: updated
Revision history for this message
Michael Terry (mterry) wrote :

Ah, thank you for the report. This is a known issue with a recent Google Drive transition behind the scenes. We used to use GNOME's API keys for Google (pre Deja Dup 40.0), which had full read and write access to your Google drive files.

GNOME asked for third parties to stop using their keys. So the Deja Dup team registered our own API keys, more appropriately scoped (Google doesn't like apps using full access). This means that Deja Dup using the new keys can only see files it has written with these new keys.

We do some fanciness to support using both keys if they are available. (Especially to delete old backups before we can't manage them anymore in new keys, after we write new backups under the new keys).

But for restoring, it means that a freshly install Deja Dup will not be able to read Google Drive backups made under a pre-40.x version. Because it stopped using GNOME's keys and can't see those files.

As you notice, there is a workaround - download the backup or mount it separately in Nautilus.

But this issue is unavoidable because of the key transition. And shouldn't be an issue going forward.

Changed in deja-dup:
status: New → Won't Fix
Revision history for this message
Fernando (fmuro) wrote :

Hey, thanks for answering! Your explanation is very reasonable. So, concerning the use of both keys, when I upgrade this machine from 18.04, will I be able to access my current backup repository in Google or should I start over? Concerning the current behavior in a fresh install, I'd suggest to notify the user so as it doesn't look like a bug. Thanks a lot for this piece of software!

Revision history for this message
Michael Terry (mterry) wrote :

> So, concerning the use of both keys, when I upgrade this machine from 18.04, will I be able to access my current backup repository in Google or should I start over?

Deja Dup will detect this case and make a new full backup in Google with the new key (after asking you to allow Deja Dup to access your Google account). And then once it has a new full backup, it will delete some of your old backups made with GNOME's keys (since it still has access to the GNOME keys if you're merely upgrading).

Then a few months later when it makes a second full backup under the new key, it will delete the last backups left under the old key and stop using GNOME's keys.

(This is all because Deja Dup's policy is to always keep at least two full backups around. So we slowly phase out the backups under the old key.)

Revision history for this message
Fernando (fmuro) wrote :

Awesome, thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.