BackupToEncfsAcrossSshfs
From RdiffBackupWiki
If you want to keep your backups private, while backuping to a server controlled by someone who is not you, one option is using a EncFS-mount across SSHFS. That way all encryption is done at your end and rdiff-backup can be used (almost) the same way as it could with a local destination.
Contents |
EncFS and SSHFS
EncFS and SSHFS are both file systems based on FUSE, allowing them to be mounted by a non-root user.
SSHFS mounts a remote directory locally, using regular SSH. EncFS makes the content of a directory encrypted, in this case; our SSHFS mount, by it accessing through a special mount point.
You might want to read the page BackupToSshfsMount. It will give you a short introduction to SSHFS, as well as explain the reasons behind some of the options we will be using.
Basic walkthrough
First run
The first time you run rdiff-backup onto a EncFS mount, across SSHFS, it might look something like this. In the following example we will be using the root-account, saving us some potential issues regarding UID mapping, which will be dealt with later on.
Before anything else, we need our SSHFS mount.
root@localhost:~# sshfs remoteuser@somehost:/some/path /mnt/sshfsmount/ -o workaround=rename Password:
Next, we have our initial EncFS-mount. Mounting EncFS from an empty directory will prompt an initiation.
root@localhost:~# encfs /mnt/sshfsmount/ /mnt/encfsmount/ Creating new encrypted volume. Please choose from one of the following options: enter "x" for expert configuration mode, enter "p" for pre-configured paranoia mode, anything else, or an empty line will select standard mode. ?> Standard configuration selected. Configuration finished. The filesystem to be created has the following properties: Filesystem cipher: "ssl/blowfish", version 2:1:1 Filename encoding: "nameio/block", version 3:0:1 Key Size: 160 bits Block Size: 512 bytes Each file contains 8 byte header with unique IV data. Filenames encoded using IV chaining mode. Now you will need to enter a password for your filesystem. You will need to remember this password, as there is absolutely no recovery mechanism. However, the password can be changed later using encfsctl. New Encfs Password: Verify Encfs Password:
Unless you know what you are doing, please use the standard mode. (In particular avoid using External IV chaining, as enabled in paranoia mode, since this will interfere with the performance of rdiff-backup)
Now let us doing our first backup, followed by some verifications.
root@localhost:~# rdiff-backup --no-hard-links /important/research/ /mnt/encfsmount/ root@localhost:~# rdiff-backup --list-increments /mnt/encfsmount/ Found 0 increments: Current mirror: Sun Aug 10 00:12:53 2008 root@localhost:~# rdiff-backup --verify /mnt/encfsmount/ Every file verified successfully.
When done, unmount.
root@localhost:~# fusermount -u /mnt/encfsmount/ root@localhost:~# fusermount -u /mnt/sshfsmount/
Remember to unmount in the right, that is; reversed, order.
Future runs
Having it all set up, a normal run will look something like this.
root@localhost:~# sshfs remoteuser@somehost:/some/path /mnt/sshfsmount/ -o workaround=rename Password: root@localhost:~# encfs /mnt/sshfsmount/ /mnt/encfsmount/ EncFS Password: root@localhost:~# rdiff-backup --no-hard-links /important/research/ /mnt/encfsmount/ root@localhost:~# fusermount -u /mnt/encfsmount/ root@localhost:~# fusermount -u /mnt/sshfsmount/
Technical issues
UID mapping
If you running your backups as a local non-root user, whose UID differs from the UID of the remote user, you will actively have to map those UIDs. This is not an issue if you run SSHFS by itself, but rdiff-backup and (especially) EncFS will get confused otherwise. This mapping is done by feeding -o uid=LocalUID to SSHFS. The SSHFS mount might then look something like this
user@localhost:~$ sshfs remoteuser@somehost:/some/path ~/mnt/sshfsmount/ -o workaround=rename,uid=1000
(In some special cases you might also have to specify the local GID.)
Run silent
If you are going to script your backup you won't be able to enter any passwords manually. The SSHFS mount is dealt with, like any other automatic SSH connection, by applying a passphrase-free SSH key. When it comes to EncFS you can use the -S option, which allows the password to be fed from stdin.
user@localhost:~$ echo "S3cr3tP4s5w0rd" | encfs -S ~/mnt/sshfsmount/ ~/mnt/encfsmount/
Versions and environment
These instructions are tested in a Linux environment, using the ext3 file system and OpenSSH. They should also apply to environments similar enough. Please add details to this page regarding your environment.
Specifically the following versions of FUSE, SSHFS, EncFS and rdiff-backup have been used.
andreas@hawat:~$ sshfs --version SSHFS version 1.9 FUSE library version: 2.7.2 fusermount version: 2.7.2 using FUSE kernel interface version 7.8 andreas@hawat:~$ encfs --version encfs version 1.3.2 andreas@hawat:~$ rdiff-backup --version rdiff-backup 1.2.0
Why not?
There are, at least, two potential reasons why you might not want to use this approach.
- It could be a tad tot creative to rely on for something as important as backups.
- Considering it involves double layers of mount points the performance may very well take its toll.
In any case, you should test this approach rigorously before you rely on it for real. Of course, that goes for any backup solution.
