deja-dup reports Restore Failed no backups to restore

Asked by Eric Gunther on 2019-02-17

Hi,

having trouble with deja-dup.
deja-dup --version
reports 37.0
but installation reports 37.1
zypper if deja-dup
Version : 37.1-lp150.1.9

I recently did a fresh install of openSUSE leap 15. I had done a non-encrypted backup of my files to an external USB HD previously using deja-dup. I went to recover them and first I was prompted to configure my google account (which I don't have), and I thought I couldn't restore without that... So I tried using duplicity from here:
https://wiki.gnome.org/Apps/DejaDup/Help/Restore/WorstCase
That didn't work*. I got a number of errors and duplicity put a number of new directories in my /run/media/eric/ directory. Then after messing with deja-dup for a bit I found that I could try to use it but after assigning the LocalFolder location it reported "Restore Failed no backups to restore".

Then I thought maybe the naming convention of the drive, "Seagate\ Backup\ Plus\ Drive" had something to do with it so I copied the entire directory into another directory in my home directory. Did not work.

I see that this may have been a bug, but I don't think the SUSE maintainers have seen it, and although it may be fixed I don't have that version available.

https://bugs.launchpad.net/deja-dup/+bug/1804744

https://answers.launchpad.net/deja-dup/+question/674573

https://answers.launchpad.net/deja-dup/+question/678601

---------------------------------------------------------------------------------------

* More info on duplicity attempt, I don't remember exactly what happened the first time but when I copied the directory over to this disk (/home/eric/restore), this is what I get

> duplicity restore file:///home/eric/restore/backup-jan-2019/ /home/eric/restore/duplicity-attempt/
Local and Remote metadata are synchronized, no sync needed.
Traceback (innermost last):
  File "/usr/bin/duplicity", line 1555, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1541, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1393, in main
    do_backup(action)
  File "/usr/bin/duplicity", line 1419, in do_backup
    action).set_values()
  File "/usr/lib64/python2.7/site-packages/duplicity/collections.py", line 710, in set_values
    self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib64/python2.7/site-packages/duplicity/collections.py", line 836, in get_backup_chains
    add_to_sets(f)
  File "/usr/lib64/python2.7/site-packages/duplicity/collections.py", line 824, in add_to_sets
    if set.add_filename(filename):
  File "/usr/lib64/python2.7/site-packages/duplicity/collections.py", line 105, in add_filename
    (self.volume_name_dict, filename)
 AssertionError: ({1: 'duplicity-full.20190123T095353Z.vol1.difftar.gz', 2: 'duplicity-full.20190123T095353Z.vol2.difftar.gz', 3: 'duplicity-full.20190123T095353Z.vol3.difftar.gz', 4: 'duplicity-full.20190123T095353Z.vol4.difftar.gz', 5: 'duplicity-full.20190123T095353Z.vol5.difftar.gz', 6: 'duplicity-full.20190123T09

with a list of the files for a few pages...

while 'ls' yields this, with redundant info omitted

> ls -la ~/restore/backup-jan-2019/
total 54588036
drwxrwxrwx 4 eric users 69632 Feb 16 07:30 .
drwxr-xr-x 5 eric users 70 Feb 19 03:47 ..
-rwxrwxrwx 1 eric users 20184249 Jan 23 06:13 duplicity-full.20190123T095353Z.manifest
-rwxrwxrwx 1 eric users 52414518 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1000.difftar.gz
-rwxrwxrwx 1 eric users 52411043 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1001.difftar.gz
-rwxrwxrwx 1 eric users 52405728 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1002.difftar.gz
-rwxrwxrwx 1 eric users 52369831 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1003.difftar.gz
-rwxrwxrwx 1 eric users 52413113 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1004.difftar.gz
-rwxrwxrwx 1 eric users 52399323 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1005.difftar.gz
-rwxrwxrwx 1 eric users 52385769 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1006.difftar.gz
-rwxrwxrwx 1 eric users 52388825 Jan 23 06:07 duplicity-full.20190123T095353Z.vol1007.difftar.gz
-rwxrwxrwx 1 eric users 52381525 Jan 23 06:08 duplicity-full.20190123T095353Z.vol1008.difftar.gz
-rwxrwxrwx 1 eric users 52394563 Jan 23 06:08 duplicity-full.20190123T095353Z.vol1009.difftar.gz
-rwxrwxrwx 1 eric us

-----------------------------------------------------------------------------------

I have looked at the gsettings and get this.

eric@70:~/.config/dconf> gsettings list-recursively org.gnome.DejaDup
org.gnome.DejaDup last-restore ''
org.gnome.DejaDup periodic true
org.gnome.DejaDup periodic-period 7
org.gnome.DejaDup full-backup-period 90
org.gnome.DejaDup backend 'drive'
org.gnome.DejaDup last-run '2019-02-16T12:26:15.961265Z'
org.gnome.DejaDup nag-check '2019-02-16T12:26:15.962460Z'
org.gnome.DejaDup prompt-check '2019-02-08T20:43:27.724839Z'
org.gnome.DejaDup root-prompt true
org.gnome.DejaDup include-list ['$HOME']
org.gnome.DejaDup exclude-list ['$TRASH', '$DOWNLOAD']
org.gnome.DejaDup last-backup '2019-02-16T12:26:15.961265Z'
org.gnome.DejaDup allow-metered false
org.gnome.DejaDup delete-after 0
org.gnome.DejaDup.Rackspace username ''
org.gnome.DejaDup.Rackspace container '70'
org.gnome.DejaDup.S3 id ''
org.gnome.DejaDup.S3 bucket ''
org.gnome.DejaDup.S3 folder '70'
org.gnome.DejaDup.OpenStack authurl ''
org.gnome.DejaDup.OpenStack tenant ''
org.gnome.DejaDup.OpenStack username ''
org.gnome.DejaDup.OpenStack container '70'
org.gnome.DejaDup.GCS id ''
org.gnome.DejaDup.GCS bucket ''
org.gnome.DejaDup.GCS folder '70'
org.gnome.DejaDup.Local folder 'restore/backup-jan-2019'
org.gnome.DejaDup.Remote uri ''
org.gnome.DejaDup.Remote folder '70'
org.gnome.DejaDup.Drive uuid '4E20996020994FB7'
org.gnome.DejaDup.Drive icon '. GThemedIcon drive-harddisk-usb drive-harddisk drive'
org.gnome.DejaDup.Drive folder '70'
org.gnome.DejaDup.Drive name 'Seagate Backup Plus Drive'
org.gnome.DejaDup.GOA id ''
org.gnome.DejaDup.GOA folder '70'
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 []

So, how do I get my backup?
Is there a work-around?

Thanks,

snaok

Question information

Language:
English Edit question
Status:
Solved
For:
Déjà Dup Edit question
Assignee:
No assignee Edit question
Solved by:
Eric Gunther
Solved:
2019-02-20
Last query:
2019-02-20
Last reply:
2019-02-19
Michael Terry (mterry) said : #1

Hello! I’m so sorry that you’re hitting this problem. Looks like an error with duplicity when it is trying to gather its list of volume files. Is there a pair of files that have the same “vol67” or whatever volume number with a different file suffix ending? Two of the same vol files might be confusing it?

Eric Gunther (snaok) said : #2

Hi,

Thank You that did it. I had some files that I had tried to uncompress in previous attempts.

Although, it seems that deja-dup is still having trouble. I am good for now though.

Eric Gunther (snaok) said : #3

Update: I followed the instructions here; https://bugs.launchpad.net/deja-dup/+bug/1804744

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.

and I got deja-dup to recognize the backup... I think its also because I removed some erroneous files. I'm going to mark this as solved.

Thanks,

snaok