4

After years of rsync, I'm giving deja-dup a try. Not so successful, so far:

Every attempt to have it write its backup via ssh results in a local directory tree opened at the directory where the deja-dup frontent got started: for the record: user and server are set with the configuration utility, the backup is supposed to go to the directory /export/dumps/notebookhost/user/deja-dup Using a small directory as source for the backup, for the sake of testing...

result: a local directory of /home/user/sftp:/user/server/export/dumps/notebookhost/user/deja-dup containing the backup (imagine this in a backup schedule of the home directory - each time it got called, it would bloat the homedirectory with backup+homedirectory, until the filesystem boundary is reached)

Calling duplicity from the command-line works as it should - both using scp or sftp - once a keyphraseless public ssh key gets installed at the target host:

 duplicity sampledir scp://user@host//export/dumps/client/home/user/deja-dup/
 duplicity sampledir sftp://user@host//export/dumps/client/home/user/deja-dup/

But even after these methods are tried and verified (and the local mess cleaned), the frontend deja-dup still creates local directory structures starting at "sftp:" Omitting the username in the configuration results in omitting the username in the (local) path. Padding with /-es in strategic places only resulted in %2F-es added to the path.

If "custom location" is selected, the last uri generated for ssh is displayed as:

sftp://192.168.178.12/export/dumps/client/home/user/deja-dup

this location is missing a / to successfully write somewhere else but the users homedirectory, however, it fails the same way as when selected through the "ssh" menu item. I tried to replace sftp with scp and ssh and only got differently named local directories. Quoting the uri does not work, since in that case it gets the path to the local homedirectory preprended. Escaping parts of the uri doesn't work either - the escape character gets inserted into the local directory name literally.

Next try: using dconf-editor to circumvent parsing in the configuration tool.

org.gnome.DejaDup.File path 'sftp://user@host:22//export/dumps/client/home/user/deja-dup/'

It's possible to add single quotes (as in all other strings) around the uri there. Unfortunately, this only results in a local directoryname starting with a single quote, as soon as deja-dup --backup is called...

Bug 908791 Backing up to ftp or sftp, creates "sftp:" or "ftp:" folder in Deja-Dup launch place seems to describe this since Dec 2011, but is not resolved. The package python-paramiko is (has been) installed.

Update:

When trying to access the remove filesystem via sftp in nautilus (enter ^L to access the location bar, entered sftp://user@host/export/dumps/client/user/ as uri, the same weird path /home/user/sftp:/user@host/.. gets constructed and echoed in the error message(/home/user being the current working directory): Unable to find the requested file. Please check the spelling and try again. Unhandled error message: Error when getting information for file '/home/user/sftp:/user@host/...': No such file or directory.

  • This doesn't answer your question, but you might check out "Back in Time" as another alternative, and is rsync based. – Sparhawk May 03 '14 at 11:08
  • I'm not looking for a replacement - I'm quite comfortable using rsync and was looking at deja-dup for encryption and "incremental blob" features. Also, duplicity on its own works as documented. It just seems that deja-dup uses a different method to access the server, as does nautilus. I'm currently documenting a solution to the nautilus problem and will check if this solves the one for deja-dup as well. – Tatjana Heuser May 03 '14 at 11:13
  • Okay, no problem. (I'm not sure what you mean by "blob", but Back in Time backs up "incrementally" by using hard links, preserving directory structure, and I just back up to encfs.) – Sparhawk May 03 '14 at 12:07
  • blob: binary large object as opposed to the file-by-file accessibility of a pure rsync backup. If encryption is not a concern, Back in Time or rsync without frontend are doing the job quite nicely. (And if you have ZFS on the target server, you can use ZFS-based snapshots on the server rather than the hardlink-forests to track your backup to a fixed date, saving both on inodes and space) – Tatjana Heuser May 03 '14 at 12:26

2 Answers2

3

Solved:

The upgrade to 14.04 did not install sshfs. It's not in the dependencies for deja-dup either, and so its absence led to the behaviour described.

sudo apt-get install sshfs

followed by a reboot of the notebook fixed the issue. Now deja-dup --backup called from the shell results in the backup being sent to the correct location on the server as configured.

For further information on debugging the problem see my answer to the nautilus problem.

  • This still helped me with Ubuntu 17.10. While Nautilus did not show the described behavior and was able to connect to my Synology via sftp right away, I had to install sshfs and reboot my machine to finally be able to backup my data with deja-dub. – Nodebody Mar 26 '18 at 18:39
0

The above didnt work for me however i did find a bit of a clunky work around.

the trick i have used is to "mount" the remote folder and trick deja dup in thinking its a local folder.

Im not sure if i can link being a newbie but look up mounting ssh drives and/or doing it via CIFS. i know it wont be secure as SSH but on a small home network it works for me.

Slight edit: this also effect smb as well as ssh so i do not think its limited to just ssh backup but all remote.

  • Did you go into the debugging process I described in my answer to the nautilus problem (linked in my answer above)? You might need t find out which packages might be missing and at which point the process fails. – Tatjana Heuser Jun 04 '15 at 10:36
  • im using Linux mint kde so i dont think i have nautilus installed.. – Stew Fisher Jun 12 '15 at 17:14