This version of the backup script should not be used anymore, the page is kept for the archive.

The encfs based backup script must be considered insecure. The encryption employed is severely affected by snapshots. Snapshotting encfs trees will produce different file revisions that are encrypted with identical cypher streams. Differences in the plain text of revisioned data can be easily derived from the encrypted data, producing cryptographic attack vectors on the backup.

Please use the duplicity based backup script supplied under TechDocs/OfficeBackUp.



... as of 2015-12-07 (svn rev. 187)

Setup and Use

Software Requirements

Technical Idea


Recovering entire hard disks is often impractical. Especially since a Backup should protect against accidental deletion as well as provide disaster recovery. It is preferable to have a form of backup where files can be accessed discretely at different versions, without reassembling container files from differential and incremental backup systems.

Traditionally this functionality has been provided by the hard link feature in Unix file systems. Tools like GNU cp and rsync (with the --link-dest option) facilitate versioning of entire folder trees without wasting too much additional disk space. However modern file systems like btrfs and zfs provide deduplication even at block level and enable explicit readonly snapshots.

Idea: We use rsync to efficiently transfer data to a btrfs subvolume on the backup server. After each synchronisation run, we trigger a readonly btrfs snapshot on the storage. A job on the backup server can perform additional maintenance works like the deletion of expired backups.


Encryption should be handled on the machine of the end user, not on the backup server. Backup encryption should happen automatically, regardless of whether the user has set up local encryption on the workstation. Encfs is a tool that provides transparent directory encryption. With the --reverse option it is able to provide an encrypted representation of a clear text folder. We can sync this encrypted representation to the backup storage easily.


Some security practices in EncFS were shown to be problematic. The most acute attack vector, which requires a legitimate user to modify data after the storage has been tampered with is not provided by the backup script. Encryption parameters on the backup server are never used for read/write operation. Each backup run overwrites encryption parameters and encrypted data with the version from the workstation. When data is restored, the original encryption parameters from the backup server are discarded. The gravest remaining issue in the EncFS version released with Debian Jessie is the availability of different revisions of encrypted data on the backup server. For details see the full security audit:


All data transfer to and from the backup server is done via SSH. For storing a backup rsync is used, for recovering we use sshfs. Each backup user has a separate system account on the backup server. Authentication to the server is performed via ssh public key. The backup program generates its own ssh keypair and sets up encfs parameters. The same passphrase is used for the ssh key and all backup directories. In fact the passphrase check in the script is based on the ability to decrypt the ssh key with the provided secret. Should one of the backup directories already contain an encfs setup, this will lead to an error if the encryption passphrase is different from the passphrase used otherwise in the backup script.

Setup on Backup Server

The user homes on the backup server must be stored in a btrfs file system. The backup server must provide btrfs utilities, ssh public key logins for each user, rsync, and the sftp subsystem. The latter is by default included in OpenSSH but not in Dropbear. Users do not require special access to create subvolumes and snapshots. Deletion of subvolumes however can only be done with root privileges. Users logging in via ssh must be able to run rsync, the sftp service, the btrfs tool, and ls (to check for available backups when restoring).

The backup server in the Berlin office is a RaspberryPi model 1B+ running raspbian wheezy. The system was installed via the Raspbian unattended installer. As storage device we use an external hard disk attached to the computer and running 24/7. Backup users currently have full shell access. Old backup subvolumes should be removed by a cron job running on the server, but this is currently not the case.

TechDocs/OfficeBackUp/encfs (last edited 2016-08-25 14:12:19 by paul)