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

Features

• The backup tool is run manually on a desktop machine via a graphical user interface
• The stored backup data is encrypted, encryption is done on the local workstation
• Recovery of single files (i.e. no need to unroll the complete backup to a clean disk)
• Backup run for single folders (e.g. the "FSFE"-folder of employees), not for an entire hard disk

Limitations

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

• Filenames are generally encrypted (as is content) but the names of topmost directories in the backup are still recognizable

• Do not use the tool to backup your home directory as a whole doing so will lead to a hangup. Use the program to backup selected directories within or outside your home folder.

• Changing the backup password is currently not possible from the GUI (and can be a bit tedious on the CLI)

Setup and Use

Software Requirements

• sshfs
• encfs
• zenity
• rsync
• ssh

Technical Idea

Storage

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

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.

Drawbacks

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: https://defuse.ca/audits/encfs.htm

Authentication

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.