Description of problem:Deja-Dup fails to create or restore a back-up Version-Release number of selected component (if applicable):38.4 How reproducible:easy Steps to Reproduce: 1.Run "backups" 2.specify back-up location 3.create a backup Actual results:nothing -the gui opens, there is a window claiming a back-up is being created. Return 24 hours later same windows, same information, it's still creating a backup however the details panel was blank and remains blank Expected results:A backup starts, the item being backed up is visible in the details pane which proceeds until all items are complete Additional info: there are also a number of previous Fedora 28 back-ups on this NAS if I try to restore one the GUI reports "no back-ups found"
I'm using 38.4 on GNOME 3 on f29 and it's working. 1. What Desktop Environment? 2. How are you connected to the NAS, ssh, smb, nfs, etc? 3. Does a duplicity backup to the same location work?
1.It's whatever version of Gnome that's shipped with Fedora 29 - 3.1 maybe 2. The backup storage is connected using NFS (it appears as any other external drive in the file manager) the permissions are OK I can transfer files to and from the device OK 3. And, again, I start the back-up software the GUI opens it does everything it did when I was using Fedora 28 except after a day it has been stuck at 'preparing' nothing is being written to the drive. 4. There are a number of back-ups on this location if I try the reverse and have a restore attempt Deja-Dup reports that there are no back-ups despite there being almost 1Tb of archives there. So Deja-Dup is neither backing up nor restoring
Ok, but can you backup or restore to the storage with duplicity directly?
Yes, I can create a backup using CLI/Duplicity not with GUI/Deja-Dup
Interesting. Can you backup or restore to another remote filesystem, or to a file:// location locally?
I have now installed a HDD to a spare SATA channel, formatted to ext4 and have run duplicity there's now a back-up on that drive. However Deja-Dup will sit there spinning, seemingly forever, doing nothing when I select that mounted drive as the storage location.
What's your Storage Location configuration?
well, it's a 2TB HDD formatted to Ext4 and is mounted at mnt/Back-up. I can easily move files into that HDD using nautilus or the CLI, I can delete them. Doesn't matter if I'm root or just 'me' I've just had another try with Deja-Dup, left it running for 48 hours Nothing
I'm wondering if your settings are corrupted. Make a note of all your deja-dup paths, settings, etc, close deja-dup, and run: dconf reset -f "/org/gnome/deja-dup/" Then open deja-dup. It should be reset to defaults. See if setting it back up allows it to work.
It didn't change the behaviour in any way that I could see, I did have to re-assign the storage location, but after that ... When I try to create a back-up "Back-Ups" (Deja-Dup Backup Tool) spends anywhere from 24 to 48 hours preparing to backup, there are no details in the 'details pane' there is no activity or changes at the other end - where the backup is being stored. If this were any other issue it would be trivial to re-install the OS and start again but, well, I will lose all my data and that's sort of dumb - to throw that away to try to have an application that protects against data loss
Bizaare. I've logged this upstream, so someone with more in-depth knowledge can weigh in. In the mean time, I'm going to look at 39.0, and I'll post a link for f29 x86_64 if you'd like.
https://fedorapeople.org/~limb/deja-dup/
so ... Since my last comment, I have removed the storage drive from the MoBo and dropped it into an external case connected to an MX Linux computer with Deja-Dup installed. that computer detected the back-up and restored the files into the appropriate directories. I applied some academic rigour and repeated this using an old laptop I had sitting around running Ubuntu 18.something.0 this machine, too, restored documents to the Documents directory, pictures to the Pictures directory and etc etc etc. I understand MX is probably a 'skinned' version of Ubuntu but - what the heck ? Why do you reckon it's my Fedora machine failing, even after a complete re-install of Fedora 29 ?
Dang. And you tried my 39.0 build?
I skipped 39.0 and have now installed 40.1 with as much success as every other version it failed with no error message but I did manage to make a note of this. Traceback (innermost last): File "/snap/deja-dup/168/bin/duplicity", line 1560, in <module> with_tempdir(main) File "/snap/deja-dup/168/bin/duplicity", line 1546, in with_tempdir fn() File "/snap/deja-dup/168/bin/duplicity", line 1385, in main action = commandline.ProcessCommandLine(sys.argv[1:]) File "/snap/deja-dup/168/lib/python2.7/site-packages/duplicity/commandline.py", line 1127, in ProcessCommandLine globals.backend = backend.get_backend(args[0]) File "/snap/deja-dup/168/lib/python2.7/site-packages/duplicity/backend.py", line 223, in get_backend obj = get_backend_object(url_string) File "/snap/deja-dup/168/lib/python2.7/site-packages/duplicity/backend.py", line 209, in get_backend_object return factory(pu) File "/snap/deja-dup/168/lib/python2.7/site-packages/duplicity/backends/giobackend.py", line 54, in __init__ from gi.repository import Gio # @UnresolvedImport File "/snap/deja-dup/168/usr/lib/python2.7/dist-packages/gi/repository/__init__.py", line 25, in <module> from ..importer import DynamicImporter File "/snap/deja-dup/168/usr/lib/python2.7/dist-packages/gi/importer.py", line 33, in <module> from .module import get_introspection_module File "/snap/deja-dup/168/usr/lib/python2.7/dist-packages/gi/module.py", line 57, in <module> from .types import File "/snap/deja-dup/168/usr/lib/python2.7/dist-packages/gi/types.py", line 28, in <module> from ._constants import TYPE_INVALID File "/snap/deja-dup/168/usr/lib/python2.7/dist-packages/gi/_constants.py", line 23, in <module> TYPE_NONE = _gi.type_from_name('void') AttributeError: 'module' object has no attribute 'type_from_name'
Now I can't work out what my problem is. I went to the Deja-Dup website, followed the "easiest way" instructions (ran 'snap install Deja-Dup -- classic' in terminal) didn't work because I didn't have Snap Store installed, installed that and re-installed the latest version of Deja-Dup
Well, since 40.0 was a dud I went back to the version currently available in the Fedora Software catalogue which is 38.4 and then had another crack at restoring from a know good back-up (I know it's Ok because I restored the data to a different PC running MX Linux) and blow-me-down It failed again... Failed to read /home/saywot/.cache/deja-dup/tmp/duplicity-Rorbxf-tempdir/mktemp-rl_UqP-1: (<type 'exceptions.IOError'>, IOError('CRC check failed 0xe04db144 != 0x91167f75L',), <traceback object at 0x7ff21ea65a28>) This bug doesn't seem to have progressed in 8 weeks, - I'm sort of stuck because all my data back-ups have been created by Deja-Dup and if I can't create or restore then the suggestion to "just re-install the OS" seems a bit foolhardy
So now, in desperation, I've tried 39.0 and .... The programme can see the drive it can see the back-up folder -it can identify the date of the last back-up but nothing worthwhile happens after I click on the "restore" option The 'Restoring' window opens up there's some activity happening (a blue bar moves across from left to right and back again) whilst some preparing takes place, but after 45 minutes I'm pretty sure that we've reached the ed of the line.
A. Does rm -rf /home/saywot/.cache/deja-dup/ help at all? B. If you try this under a new local user account, does it work?
A. after running " rm -rf /home/saywot/.cache/deja-dup/ " Then running Deja-Dup for 6 hours (because it's a first-time back-up) I am finally greeted with an error message saying BackUp Failed Failed to read /home/saywot/.cache/deja-dup/tmp/duplicity-EudL7o-tempdir/mktemp-zKuZK3-1: (<type 'exceptions.IOError'>, IOError('CRC check failed 0x701a1600 != 0x5f660fc2L',), <traceback object at 0x7f1601589a28>)
Does dmesg indicate any disk errors?
I got tired of waiting for this bug to be resolved. Completely wiped the Fedora 29 installation. Brand new, freshly updated Fedora 30 install Only one thing extra installed apart from the default applications - Deja-Dup Ran it, trying to restore my data and you'll never guess - it failed Failed to read /home/tony/.cache/deja-dup/tmp/duplicity-nf8HgH-tempdir/mktemp-62HNtZ-1: (<class 'zlib.error'>, error('Error -3 while decompressing: invalid stored block lengths',), <traceback object at 0x7f88d7846cf8>)
"Does dmesg indicate any disk errors?" No
Can you restore that data from another machine?
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.