| 2018-11-23 03:09:06 |
ethanay |
bug |
|
|
added bug |
| 2018-11-23 03:09:53 |
ethanay |
summary |
restore from backup does not recognize backup directory |
restore from backup does not recognize custom backup directories |
|
| 2019-01-05 02:18:29 |
Michael Terry |
deja-dup: status |
New |
Confirmed |
|
| 2019-01-05 03:11:13 |
Michael Terry |
deja-dup: importance |
Undecided |
Critical |
|
| 2019-01-05 03:46:54 |
Michael Terry |
tags |
|
restore |
|
| 2019-01-05 03:51:04 |
Michael Terry |
summary |
restore from backup does not recognize custom backup directories |
Restoring on a fresh install does not find backup files |
|
| 2019-01-05 03:52:44 |
Michael Terry |
deja-dup: status |
Confirmed |
Fix Committed |
|
| 2019-01-05 14:41:40 |
Michael Terry |
summary |
Restoring on a fresh install does not find backup files |
Restoring from new location does not find backup files |
|
| 2019-01-05 14:41:51 |
Michael Terry |
bug task added |
|
deja-dup (Ubuntu) |
|
| 2019-01-05 14:42:15 |
Launchpad Janitor |
deja-dup (Ubuntu): status |
New |
Confirmed |
|
| 2019-01-05 15:20:25 |
Michael Terry |
deja-dup: status |
Fix Committed |
Fix Released |
|
| 2019-01-12 00:04:05 |
Launchpad Janitor |
deja-dup (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2019-01-12 01:57:20 |
Michael Terry |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-01-12 01:57:20 |
Michael Terry |
bug task added |
|
deja-dup (Ubuntu Cosmic) |
|
| 2019-01-12 01:57:20 |
Michael Terry |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-01-12 01:57:20 |
Michael Terry |
bug task added |
|
deja-dup (Ubuntu Bionic) |
|
| 2019-01-12 02:40:16 |
Michael Terry |
description |
1. I back up my computer to my external hard drive
2. I reinstall my new distro
3. I install deja-dup and duplicity
4. I open deja-dup, and select restore
5. I select my external hard drive and the restore directory
6. Deja-dup fails with "no backup found" message and creates a new backup directory on the hard drive
This indicated to me that deja dup ignored the restore directory I entered, and instead used the default directory, which did not exist, hence restore fails because the backend is told to look in the wrong place for the backup! This seems like more a user interface issue than an issue with the backup.
Here is the workflow I had to use to restore my backup:
1. Set storage location to "local folder" and then manually navigate to the folder on my external hard drive. If I did not do this specifically, then backup would fail. Selecting the external hard drive directly as the device and entering the folder in the "folder" field also fails.
2. Select restore and again use "local folder" and manually navigate to the folder on my external hard drive. If I instead try to use the hard drive device listed and enter the backup folder in the "folder" field, the restore also fails.
This issue occurs on both Ubuntu 18.04.1 and ElementaryOS Juno.
lsb_release -d
Description: elementary OS 5.0 Juno
dpkg-query -W deja-dup duplicity
deja-dup 37.1-2fakesync1
duplicity 0.7.17-0ubuntu1
gsettings list-recursively org.gnome.DejaDup > /tmp/deja-dup.gsettings
cat /tmp/deja-dup.gsettings
org.gnome.DejaDup last-restore '2018-11-23T01:39:44.556645Z'
org.gnome.DejaDup periodic true
org.gnome.DejaDup periodic-period 1
org.gnome.DejaDup full-backup-period 90
org.gnome.DejaDup backend 'local'
org.gnome.DejaDup last-run '2018-11-23T01:39:44.556645Z'
org.gnome.DejaDup nag-check ''
org.gnome.DejaDup prompt-check '2018-11-22T12:34:36.095106Z'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup include-list ['$HOME']
org.gnome.DejaDup exclude-list ['/home/ethan/.local/share/Trash']
org.gnome.DejaDup last-backup ''
org.gnome.DejaDup allow-metered false
org.gnome.DejaDup delete-after 0
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.Rackspace container 'ethan-laptop'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder 'ethan-laptop'
org.gnome.DejaDup.OpenStack authurl ''
org.gnome.DejaDup.OpenStack tenant ''
org.gnome.DejaDup.OpenStack username ''
org.gnome.DejaDup.OpenStack container 'ethan-laptop'
org.gnome.DejaDup.GCS id ''
org.gnome.DejaDup.GCS bucket ''
org.gnome.DejaDup.GCS folder 'ethan-laptop'
org.gnome.DejaDup.Local folder '/media/ethan/porta_500gb/m1330'
org.gnome.DejaDup.Remote uri ''
org.gnome.DejaDup.Remote folder 'ethan-laptop'
org.gnome.DejaDup.Drive uuid '1919a422-d154-4e19-b551-f74b56cf1f0e'
org.gnome.DejaDup.Drive icon '. GThemedIcon drive-harddisk-usb drive-harddisk drive'
org.gnome.DejaDup.Drive folder 'm1330'
org.gnome.DejaDup.Drive name 'porta_500gb'
org.gnome.DejaDup.GOA id ''
org.gnome.DejaDup.GOA folder 'ethan-laptop'
org.gnome.DejaDup.GOA type 'google'
org.gnome.DejaDup.File short-name ''
org.gnome.DejaDup.File type 'normal'
org.gnome.DejaDup.File migrated true
org.gnome.DejaDup.File name ''
org.gnome.DejaDup.File path ''
org.gnome.DejaDup.File uuid ''
org.gnome.DejaDup.File icon ''
org.gnome.DejaDup.File relpath @ay [] |
[Impact]
When a user tries to restore a backup on a fresh Ubuntu install, deja-dup will not be able to find their backup at first.
A workaround is to set the current backup location on the fresh install to the old backup location. But that's not at all an obvious path. A user would not normally try that.
[Test Case]
1. Back up some files to a temporary dir.
2. gsettings reset-recursively org.gnome.DejaDup
3. Try to restore from that temporary dir.
Notice that deja-dup will complain about waiting for Google Drive to be set up (even though your backup drive has nothing to do with Google).
[Regression Potential]
The proposed patch mostly affects the restore dialog. Any regressions would likely be in that flow.
[Original Report]
1. I back up my computer to my external hard drive
2. I reinstall my new distro
3. I install deja-dup and duplicity
4. I open deja-dup, and select restore
5. I select my external hard drive and the restore directory
6. Deja-dup fails with "no backup found" message and creates a new backup directory on the hard drive
This indicated to me that deja dup ignored the restore directory I entered, and instead used the default directory, which did not exist, hence restore fails because the backend is told to look in the wrong place for the backup! This seems like more a user interface issue than an issue with the backup.
Here is the workflow I had to use to restore my backup:
1. Set storage location to "local folder" and then manually navigate to the folder on my external hard drive. If I did not do this specifically, then backup would fail. Selecting the external hard drive directly as the device and entering the folder in the "folder" field also fails.
2. Select restore and again use "local folder" and manually navigate to the folder on my external hard drive. If I instead try to use the hard drive device listed and enter the backup folder in the "folder" field, the restore also fails.
This issue occurs on both Ubuntu 18.04.1 and ElementaryOS Juno.
lsb_release -d
Description: elementary OS 5.0 Juno
dpkg-query -W deja-dup duplicity
deja-dup 37.1-2fakesync1
duplicity 0.7.17-0ubuntu1
gsettings list-recursively org.gnome.DejaDup > /tmp/deja-dup.gsettings
cat /tmp/deja-dup.gsettings
org.gnome.DejaDup last-restore '2018-11-23T01:39:44.556645Z'
org.gnome.DejaDup periodic true
org.gnome.DejaDup periodic-period 1
org.gnome.DejaDup full-backup-period 90
org.gnome.DejaDup backend 'local'
org.gnome.DejaDup last-run '2018-11-23T01:39:44.556645Z'
org.gnome.DejaDup nag-check ''
org.gnome.DejaDup prompt-check '2018-11-22T12:34:36.095106Z'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup include-list ['$HOME']
org.gnome.DejaDup exclude-list ['/home/ethan/.local/share/Trash']
org.gnome.DejaDup last-backup ''
org.gnome.DejaDup allow-metered false
org.gnome.DejaDup delete-after 0
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.Rackspace container 'ethan-laptop'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder 'ethan-laptop'
org.gnome.DejaDup.OpenStack authurl ''
org.gnome.DejaDup.OpenStack tenant ''
org.gnome.DejaDup.OpenStack username ''
org.gnome.DejaDup.OpenStack container 'ethan-laptop'
org.gnome.DejaDup.GCS id ''
org.gnome.DejaDup.GCS bucket ''
org.gnome.DejaDup.GCS folder 'ethan-laptop'
org.gnome.DejaDup.Local folder '/media/ethan/porta_500gb/m1330'
org.gnome.DejaDup.Remote uri ''
org.gnome.DejaDup.Remote folder 'ethan-laptop'
org.gnome.DejaDup.Drive uuid '1919a422-d154-4e19-b551-f74b56cf1f0e'
org.gnome.DejaDup.Drive icon '. GThemedIcon drive-harddisk-usb drive-harddisk drive'
org.gnome.DejaDup.Drive folder 'm1330'
org.gnome.DejaDup.Drive name 'porta_500gb'
org.gnome.DejaDup.GOA id ''
org.gnome.DejaDup.GOA folder 'ethan-laptop'
org.gnome.DejaDup.GOA type 'google'
org.gnome.DejaDup.File short-name ''
org.gnome.DejaDup.File type 'normal'
org.gnome.DejaDup.File migrated true
org.gnome.DejaDup.File name ''
org.gnome.DejaDup.File path ''
org.gnome.DejaDup.File uuid ''
org.gnome.DejaDup.File icon ''
org.gnome.DejaDup.File relpath @ay [] |
|
| 2019-01-12 02:42:28 |
Michael Terry |
attachment added |
|
cosmic.debdiff https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1804744/+attachment/5228566/+files/cosmic.debdiff |
|
| 2019-01-12 02:44:36 |
Michael Terry |
deja-dup (Ubuntu Bionic): status |
New |
In Progress |
|
| 2019-01-12 02:44:44 |
Michael Terry |
deja-dup (Ubuntu Cosmic): status |
New |
In Progress |
|
| 2019-01-12 03:02:03 |
Michael Terry |
attachment added |
|
bionic.debdiff https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1804744/+attachment/5228569/+files/bionic.debdiff |
|
| 2019-01-14 17:36:05 |
Brian Murray |
deja-dup (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2019-01-14 17:36:18 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-01-14 17:36:20 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-01-14 17:36:23 |
Brian Murray |
tags |
restore |
restore verification-needed verification-needed-cosmic |
|
| 2019-01-14 17:38:34 |
Brian Murray |
deja-dup (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-01-14 17:38:39 |
Brian Murray |
tags |
restore verification-needed verification-needed-cosmic |
restore verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2019-01-16 23:01:37 |
Michael Terry |
tags |
restore verification-needed verification-needed-bionic verification-needed-cosmic |
restore verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2019-01-30 21:32:28 |
Launchpad Janitor |
deja-dup (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-01-30 21:32:33 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-03-18 16:10:49 |
Sebastien Bacher |
tags |
restore verification-done-bionic verification-needed verification-needed-cosmic |
restore verification-done verification-done-bionic verification-done-cosmic |
|
| 2019-03-19 14:58:06 |
Launchpad Janitor |
deja-dup (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
