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.
Best Answer
Solved:
The upgrade to 14.04 did not install
sshfs
. It's not in the dependencies fordeja-dup
either, and so its absence led to the behaviour described.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.