rsync.net supports the use of 'duplicity', which is a compact, elegant tool for
automatically encrypting and storing remote backups in a bandwidth efficient
manner.

A more in-depth discussion of the encryption tools available on rsync.net and
their relative merits and demerits can be found here:

http://rsync.net/products/encrypted.html

-----

1. Install python (v2.2 or higher), GPG, and librsync.  These may already be
   installed on your system.


2. You may use your systems' package management tool(s) to install duplicity.

   OR, you may obtain the duplicity tarball from http://duplicity.nongnu.org/
   and after untarring it, install it with:

   python setup.py install      (to put things in /usr/bin)

   OR:

   python setup.py install --prefix=/usr/local


3. duplicity does not have a facility for passing SSH passwords to the remote
   host.  Therefore you MUST use passwordless SSH connections (with an SSH
   key) to use duplicity.

   Follow these instructions:

   http://www.rsync.net/resources/howto/ssh_keys.txt

   To set up an SSH key for passwordless logins into your rsync.net account.


4. duplicity encrypts its backups with GPG, which means that you must create
   at least one GPG key, which duplicity will use for both encrypting the
   data and signing the encrypted files.

   It is possible to create two different keys (possibly owned by different
   users) and encrypt and sign with different keys, but that is beyond the
   scope of this document.  Please see:

   http://www.debian-administration.org/articles/209

   for more details.

   To create the single GPG key that will be used for both encryption and
   signing, log in as the user who you will run the backups as (most likely
   root) (the important thing is that it is the same user who you used to
   create your SSH keys in step #3).

   Run the command:

	gpg --gen-key

   The default choices should be chosen.  It is up to you how long you want
   the key to last:

   Please select what kind of key you want:
      (1) DSA and Elgamal (default)
      (2) DSA (sign only)
      (5) RSA (sign only)
   Your selection? 1
   DSA keypair will have 1024 bits.
   ELG-E keys may be between 1024 and 4096 bits long.
   What keysize do you want? (2048)
   Requested keysize is 2048 bits


5. Once you have created the key, verify it by running this command:

   gpg --list-keys

   The output should look like:

   /root/.gnupg/pubring.gpg
   ------------------------
   pub   1024D/ABAB2AB3 2007-04-23
   uid                  Home File <home@file.com>
   sub   2048g/12345678 2007-04-23

   Two keys are listed - the "pub"lic key and the private key.  Make a note of
   id of the public key - in this example it is "ABAB2AB3".


6. It is not advised to place your duplicity backups in the root of your rsync.net
   filesystem.  duplicity generates a lot of files and will quickly become
   unmanageable unless subdirectories are created.

   So, choose a directory in your rsync.net filesystem that you would like to place
   your duplicity backups in and create it.  In this example, we will create a
   directory called "backups":

   ssh 1234@usw-s001.rsync.net mkdir backups

   Again, if you run this command as the same user who sent the SSH keys in step #3,
   you should not be asked for a password.  The command will complete without output.


7. Run your first duplicity command:

   duplicity --encrypt-key="ABAB2AB3" /your/files scp://1234@usw-s001.rsync.net/backups

   Although this command will generate a lot of output, it should complete without errors.
   You will be asked for your GPG key passphrase when this backup runs.

   If you see errors, most likely beginning with "Traceback (most recent call last):"
   you should add a -v9 switch to your command:

   duplicity -v9 --encrypt-key="ABAB2AB3" /your/files scp://1234@usw-s001.rsync.net/backups

   and send the output to support@rsync.net.


8. Provided that your first duplicity command ran without errors in step #7, you can
   simply re-run that same command.  Each time you run it duplicity will store all
   the new data that has been produced on your end on your rsync.net filesystem - in
   the form of diffs against the first backup.

   At some point, all of these changes add up - if you continue to run this same
   command over and over, you will have not only all of your data as it currently
   exists, but all of your data as it has existed every time you ran it.  This is
   most likely not what you want, and will use a lot of space.

   So, decide how many days of backups you would like to retain, and add a
   --remove-older-than flag to your command line, instructing duplicity to
   delete backups of your files that are older than X days, etc.

   Please see the duplicity man page:

   http://duplicity.nongnu.org/duplicity.1.html

   For information on the time format of the --remove-older-than flag

   NOTE:  You cannot remove backups that are NEWER than your last full backup.  So if you
          begin performing backups, and updating them with the example shown above, the
	  --remove-older-than flag will do nothing - since it can't remove data that is
	  newer than the last FULL backup.  If you want --remove-older-than to work
	  properly, you will need to periodically do a FULL backup (-f flag) which
	  will allow --remove-older-than to remove items that are older than that full
	  backup.

   NOTE:  duplicity does not allow you to run a backup (full or otherwise) on the same
	  command line as a --remove, or --remove-older-than.  Your --remove directive will
	  need to be run from a separate duplicity command.

   NOTE:  You will need to add the --force directive anytime deletion or overwrite is
	  required.  So you will always need to add the --force directive to any command
	  uses the --remove or --remove-older-than flag.


9. Finally, it is likely that you do NOT want to type in your GPG passphrase
   every time you run duplicity.  Most likely you want to run duplicity out
   of your crontab, unattended.

   You should create a script that exports your GPG passphrase and then runs the
   duplicity command:

	#!/bin/bash
	export PASSPHRASE=yourpassphrase
	duplicity --encrypt-key "ABAB2AB3" /your/files scp://1234@usw-s001.rsync.net/backups

   Make sure to chmod +x the script, and then place that script into your crontab.


10.To verify your backups (we highly recommend that you verify your backups) simply
   reverse the source and destination in your command and add the --verify switch:

   duplicity --verify scp://1234@usw-s001.rsync.net/backups /your/files

   This will not restore the files to your end, but will simply compare and verify them.
   You may wish to add the -v9 switch to your command line to see the full details of the
   verification.


11.To restore your data, as in step #10, we run the duplicity command with the source and
   destination reversed.  However, as duplicity does not allow restoring into an
   existing directory, we must create a new directory to restore things in, and reflect
   that alternate location in our command line:

   mkdir /your/restored/files

   duplicity scp://1234@usw-s001.rsync.net/backups /your/restored/files