Redoubt: secure offsite backups

Main Features

• Encryption: All files are encrypted using well known and configurable encryption algorithms such as AES (Rijndael). It will be possible to encrypt every file with a different key and even the original filenames are not visible in the archive.

• Secure connection: SSL is the default transport mechanism between clients and backup servers to prevent eavesdropping, tampering, and message forgery.

• Redundancy: Your files can be backed up on one server, or, if you prefer to have better odds restoring your data, you can use one of the following options:
  • Mirroring: this option lets you store a copy of your files on as many servers as you want. As long as you have access to at least one of them you can restore your files.
  • n-1 out of n servers: Using a RAID like error correction algorithm you can distribute your files among several servers, and restore them if at most one of the servers is no longer accessible. You need at least 3 servers for this option to work.
  • 2 out of 4: Your data is stored on 4 different servers. If you can access at least two of those servers your files can be restored.
  • others: If other options (like 2 out of 3, ...) seem to be important, they can be easily added.

• Multiple Policies: The configuration allows you to specify which files are more important than others. More important files can be backed up more often than less important ones. This way you can preserve some bandwidth and avoid overloading your network pipe.

• Server options: If you offer your friends to host a backup server you can specify the upload and download bandwidth each of your friends can use and vary it during the day. This way you can avoid that one of them takes up all the bandwidth on your DSL/Cable line. Additionally you can define the maximum number of bytes each friend can use on your system.

• Multiple Backups: You can specify how many versions of each file should be kept on the server. (So you can restore older versions of any file.)

• Small Bandwidth: The client-server protocol has been optimized for backups in order to use as little bandwidth, server CPU cycles, and space as possible. Restoring single files is inexpensive too, but restoring the full backup is slightly more expensive on the server side since it must generate file listings to be sent to the restoring computer.

• CD Support: Eventually it will be possible to burn CD's that can be sent to the backup server in order to preserve bandwidth when creating the first full backup (and vice versa: in order to restore a full system the backup server can burn CD's). Those CD's can also be used independent of the backup server, which means that only incremental backups are stored on the servers.

• Reusing Technology: To simplify the implementation we decided to use Apache as a backup server (using CGI scripts for the prototype and eventually an Apache module). This means that we will also use the standard HTTP and HTTPS protocol.