BackupToSshfsMount
From RdiffBackupWiki
If you have SFTP-access to a remote machine you do a rdiff-backup against it using SSHFS. This is a good option if the machine in question doesn't have rdiff-backup installed or if it has the "wrong" version installed.
Contents |
SSHFS and FUSE
SSHFS allows you to mount a remote folder, to which you have SFTP-access, as a folder in your local filesystem. Since SSHFS is based on FUSE you can do the mount without being root.
Nowdays SSHFS comes bundled with most Linux-distributions. To my knowledge the same goes for *BSD. You can run SSHFS on OSX using MacFUSE.
SSHFS syntax
This is this syntax of a basic SSHFS-mount:
$ sshfs remoteuser@remotehost:/remote/path /local/mountpoint
And of course, the umount:
$ fusermount -u /local/mountpoint
-o workaround=rename
Due to the difference in how SFTP handles renames compared to POSIX a workaround has to be set in place for rdiff-backup to work properly. It is applied using "-o workaround=rename". If you don't use the workaround rdiff-backup will complain when you try to backup updated files.
Our previous example will now look like this:
$ sshfs remoteuser@remotehost:/remote/path /local/mountpoint -o workaround=rename
Read more about different ways to use SSHFS in the SSHFS FAQ.
Examples
Now let us do an actually backup.
$ sshfs remoteuser@remotehost:/remote/path /local/mountpoint -o workaround=rename $ rdiff-backup /home/myself/Documents /local/mountpoint Warning: hard linking not supported by filesystem at /local/mountpoint/rdiff-backup-data $ fusermount -u /local/mountpoint
Did you notice the warning? This is a good time for me to tell you that SSHFS (well, actually SFTP, or at least current versions of it) doesn't support hard links. On the remote side your hard links will be saved as separate files. When you later restore rdiff-backup will recreate the hard links from its metadata.
If you don't want to see the warning you can add "--terminal-verbosity 1" to your rdiff-backup command. That way rdiff-backup will only show you Fatal Errors and not mere warning. Of course, before you turn the warning off it is most definitely a good idea to verify that your backups and restores works the way they are supposed to.
Here we have our basic restore
$ sshfs remoteuser@remotehost:/remote/path /local/mountpoint -o workaround=rename $ rdiff-backup -r now /local/mountpoint /home/myself/restore $ fusermount -u /local/mountpoint
As you can see, using rdiff-backup against an SSHFS-mount is basically the same as using it against a local folder. The main difference is the way hard links are handled and the requirement of a workaround or two.
Potential issue
There is one potential scenario where you still might have a remaing workaround to apply. This could be depending on OS and filesystem, but seems to at least apply on Linux and ext3. The scenario involves rdiff-backup being run as a normal user with an UID which differs from the UID of the remote user. For some reason this might confuse rdiff-backup in such a manner that it won't be able to do read-operations like as verify, restore, etc.
The workaround against this is to do the SSHFS-mount with a directive to use your local UID. This is archived by doing a "o uid=LocalUID". The example mount now looks like this.
sshfs remoteuser@remotehost:/remote/path /local/mountpoint -o workaround=rename,uid=LocalUID
Performance
Compared to running rdiff-backup the "normal" way through a ssh-tunnel it might cost you some performance using an SSHFS-mount. In those cases when rdiff-backup has to transfer a large amount of files, such as on an initial backup or on a restore, it is pretty much always considerable slower to use an SSHFS-mount. When doing an incremental backup, in other words mostly comparing files, updating metadata and transferring a few files,the relative performance might vary depending on the changes in question, the speed of the link, etc
