deja-dup suddenly refuses to restore single files

[Oliver Joos]

Binary package hint: deja-dup

I use deja-dup to backup my $HOME through gvfs-ftp to a NAS running vsftp. Sometimes I restore single files (also to test deja-dup ;-). A few days ago deja-dup began to fail restoring single files.

The dialogue says (translated from German): "Error while creating folder: File exists". I restarted Nautilus in a terminal to see its messages => see attachment "nautilus.log"

ProblemType: Bug
Architecture: i386
Date: Mon Jan 4 01:09:29 2010
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/deja-dup
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Package: deja-dup 10.2-0ubuntu1.1
ProcEnviron:
 PATH=(custom, user)
 LANG=de_CH.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-16.53-generic
SourcePackage: deja-dup
Uname: Linux 2.6.31-16-generic i686

[Oliver Joos (oliver-joos)]

I invoked duplicity manually with the same arguments as deja-dup did. That showed a Traceback (see attachment). The problem seems to be with deja-dup reading from a gvfs-location.

I then installed ncftp and invoked duplicity manually with the url "ftp://server" instead of "file://home/oliver/.gvfs/FTP on server". Then duplicity worked and extracted my file to /tmp/!

So I think my server and duplicity are ok, and the problem is around deja-dup using gvfs to access the backup. (Or it is the year-2010-problem :o).

[Michael Terry (mterry)]

Hrm... With at least duplicity 0.6.05 and deja-dup 11.0, Deja Dup will use duplicity's native gvfs support, which would probably work better. If you were feeling slightly adventurous, you could try the Deja Dup PPA [1].

As for your actual error, it seems that duplicity is having a tough time reading a certain file from gvfs. It might help to see what that file is. You can get a more verbose report from Deja Dup by doing the following and reproducing the error:

DEJA_DUP_DEBUG=1 deja-dup | tail -n 200 > /tmp/deja-dup.log

which will give the last 200 lines of the debug log. Can you attach that? It might shed some light.

[1] https://launchpad.net/~deja-dup-team/+archive/ppa

[Oliver Joos (oliver-joos)]

Thanks! I will try that from PPA.

As you asked I generated the deja-dup.log. Then I inspected the Traceback and added another log.info() into "duplicity/backends/localbackend.py:get()":

    def get(self, filename, local_path):
        """Get file and put in local_path (Path object)"""
        source_path = self.remote_pathdir.append(filename)
        log.Info("Get file '%s' and put in local_path '%s'" % \
            (str(source_path), str(local_path))) # <-- ADDED!
        local_path.writefileobj(source_path.open("rb"))

The attached log file was generated with this line added! The paths look ok to me. From nautilus I can read the file where duplicity has problems.

[Oliver Joos (oliver-joos)]

I has something to do with gvfs-ftp or its use by duplicity. If I mount the backup folder of the server with NFS and reconfigure deja-dup to use /media/server/duplicity/ then everything works as expected.

[Michael Terry (mterry)]

Did the PPA version seem to work?

[Oliver Joos (oliver-joos)]

I tried the even newer package in Lucid 10.04 alpha 2 and it worked! I was able to restore my old backup again. Then I checked Karmic again and after deleting ".cache/deja-dup" it worked again too! (I really thought I tried this before)

I guess I damaged ".cache/deja-dup" when I tried to force deja-dup to connect through ftp. This still does not work nice in 10.04 alpha 2! After I changed the backup location to use ftp, I was no more able to restore single files. And after the third attempt nautilus crashed in Lucid (ok, it's alpha...).

For me this bug is kind of solved. But deja-dup could try harder if it is no more able to restore files. E.g. it could try to delete and rebuild ".cache/deja-dup" on its own.

Here are the versions in Lucid 10.04 alpha 2 I used:
deja-dup (13.5-0ubuntu1)
duplicity (0.6.06-2ubuntu1)
librsync1 (0.9.7-7)
python-boto (1.9b-1ubuntu2)