Use SSHFS With rdiff-backup

An excellent tool to create backups is rdiff-backup. It is based on SSH, and the feature of SSH to execute a command on a remote system, as long as you can log in to this machine with SSH.

Now I've been experimenting with SSHFS, and one of the things it can be used for is rdiff-Backup. Sshfs is a FUSE module, which allows you to mount the remote system. A normal backup looks like (assuming ssh access is ok):

rdiff-backup --preserve-numerical-ids /srv/rdiff/backup/

Now with SSHFS it looks like:

install --directory /srv/rdiff/mounts/
sshfs -o ro /srv/rdiff/mounts/
rdiff-backup --preserve-numerical-ids /srv/rdiff/mounts/ /srv/rdiff/backup/

It looks like this construction has only advantages:

- the backup process is slightly faster. I've done some testing and all of my cases the backup over sshfs was a little bit faster (5 a 10 %).
- with sshfs it is possible to mount the remote system read-only, which increases the security. This is not an optimal security measurement: this readonly flag should not be controlled on this system (where the backup is made) , but on the remote system. I've tried to find out how, but there is no way in the Ssh server to make access read-only. Somebody knowing a way to do it, please let me know.
- it is possible to make more than one backup using only one SSHFS mount. When all backups are done, the sshfs connection with the remote system can be caunmounted.
- there is no need for rdiff-backup to be installed on the remote system.

One possible disadvantage (I'm not sure yet) is that sshfs does not support extended attributes. At this moment [26 august 2007] I'm trying to find out for sure.
September 2007:
I've send an email about this to Miklos Szeredi, the writer of SSHFS. SSHFS lacks support of ACL's because the sftp-server in OpenSSH doesn't support it. According to M. Szeredi "the OpenSSH developers have been reluctant to add support for newer protocol versions".


Share this page:

Suggested articles

4 Comment(s)

Add comment



Thanks for this article on rdiff-backup and sshfs.  I'm already a fan of both but hadn't thought of using them together.

A note on installing sshfs on Debian (and maybe other distrols) that isn't mentioned in the docs or on the program's FAQ.  Your user account must be a member of the fuse group or you'll get

fusermount: failed to open /dev/fuse: Permission denied

So, do:

sudo adduser <username> fuse

newgrp fuse

sudo adduser <username> fuse

newgrp fuse



 you're right about this. The user using sshfs must have enough permissions to write and to read /dev/fuse. There are various ways do that, you name one. Another is to change  the permissions of /dev/fuse:

crw-rw-rw- /dev/fuse

I prefer the latest, fuse is meant to be used by anyone. But that's my opinion. Anyway thanks for your comment,


Stef Bon

the Netherlands 

By: Joost Ringoot


I agree with you stef: " fuse is meant to be used by anyone"

Thanks for pointing somewhat in the right direction.

But I found your suggestion insufficient, further the device /dev/fuse is on my system (centos 5.3) belongs to user and group root.

So the group fuse got nothing to do there.

After poking around a bit(=looking for files that have fuser as group) I found that the solution is undocumented but quite simple: give other excecute rights on the command that performs the actual usermount:
Standard it is like this:
-rwsr-x--- 1 root fuse 23544 Sep  3 21:18 /bin/fusermount
we change it:

chmod +x  /bin/fusermount
-rwsr-x--x 1 root fuse 23544 Sep  3 21:18 /bin/fusermount

 Joost Ringoot

The Universe :-)

By: /dev/kev

I'm somewhat amazed that you found rdiff-backup to be faster over sshfs than rdiff-backup directly over ssh.

When rdiff-backup is running at each end of the ssh link, then the rdiff-backup processes can compute rolling checksums and exchange those to determine which files have changed (and where in the file the changes are). This is the main advantage (and the whole point, really) of the rsync algorithm.

But when using sshfs, rdiff-backup sees only two "local" files. It will then compute these rolling checksums on both files itself, by reading in each file. Surely this causes the entire file to be fetched by sshfs? And surely this will (in general) be slower than with an rdiff-backup process at the other end which is sending only checksums, not the whole file...

About the only time I can figure that sshfs access might be faster is during an initial backup, when none of the files actually exist in the backup, and so there are no rolling checksums to compute and compare.