It is said that there are two kinds of people in the world: those that have lost a hard drive, and those that are going to lose a hard drive. Several weeks ago, I lost a huge hard drive and a lot of data. I was able to retrieve most, but not all of them.

Remote backups?

Now I regularly do complete incremental backups of my computers on external hard drives. But in case of big trouble (fire, theft...), this is just useless. The solution is to do additional backups on a remote server.

Last week, I decided to use rsync.net for that. I must say I am very pleased by this service: it's not that cheap (but affordable, especially when you are entitled to the student/teacher/Open Source developer discount), but it seems to be very solid, and the support is very competent and quick to answer any question. So now I am backing up 10+ GB of pictures using unison¹, and the next step is to store more sensitive data: all my e-mails.

Here is what I want for my e-mails:

• store them all. Currently there are about 7 years of e-mails from 3 different accounts, fetched on my laptop using offlineimap.
• store them safely. I consider this to be sensitive data, so I want them to be encrypted with GnuPG.
• sync them efficiently. I don't want to have to upload 1.5 GB just to store 5 more MB of mail, I want something that works a bit like rsync.

I considered different approaches:

• rsync + sshfs + EncFS or eCryptFS: too complicated, probably too slow.
• rsyncrypto: too complex (I don't want to have an extra certificate just for that), does not seem to be maintained, has annoying dependencies (needs to patch gzip).
• duplicity: nice, but I don't need incremental backups.

So in the end I just wrote my own script to do just what I want =]

Introducing seb: Simple Encrypted Backup

How does it work?

seb is a simple Python 3 script that performs backups quite efficiently. It produces a bunch of packs, which are encrypted tarballs, which can then be uploaded to the remote host.

A pack contains a fixed number of files (250 in my case, which is reasonable given that most of my mails are only a few kilobytes). When running seb, it finds which files were added, modified or deleted since its last run. Packs are then updated to reflect these local changes. seb tries to be a little smart here: instead of creating new packs, it will first try to add new files to packs that have less than 250 files.

All the needed internal data are saved in a single file, a dictionary that is serialized using Python's pickle module. File modifications are detected using their modification times only; this can be an issue, but computing file hashes seems overkill here: mails are not supposed to change once they are sent and received...

Performance

seb is quite quick. The longest part of the backup is by far uploading data to the remote server.

Some statistics:

How to use?

1. Download seb: https://gist.github.com/821667
2. Read the doc: ./seb --help
3. Use: ./seb ~/mail /path/to/backup_fs

Here's a tip: on the first run, use a local directory as the destination, and then upload its content to your remote backup site (using scp or rsync for example). On the subsequent runs (where there will be much less data to transfer), you can mount your remote backup site using sshfs and use this mount point directly as your destination folder. It works fine for me.

How to restore a backup?

1. Grab all the packs.
2. Decrypt each pack with gpg and extract it with tar.
3. That's all.

After I joined the FSFE Fellowship a few months ago, I received a nice OpenPGP smartcard. Now I'm using it for real, and I like it!

I've decided to buy two OpenPGP card readers on Kernel concepts:

• Gemalto PC Express card for my laptop
• SCM SCR-335 for my workstation

Both are very easy to get working on Arch Linux: just install ccid and pcsclite from the AUR, restart udev, start pcscd (/etc/rc.d/pcscd start), plug your reader in, and you're good to go.

The next step is to create a key to be used with the card. There is a good tutorial on this topic on the FSFE Wiki. Only one step can be greatly enhanced: step 12, "Removing the master key from the keyring". Here is a much easier version:

1. Backup your public key: gpg --armor --export 559C215F > publickey.asc
2. Remove your private and public key from your keyring: gpg --delete-secret-and-public-key 559C215F
3. Import your public key: gpg --import publickey.asc
4. Edit your key and set its trust level to Ultimate: gpg --edit-key 559C215F, trust, 5, save, quit
5. Make GPG check your smartcard and recreate the secret key stubs by itself: gpg --card-status

That's it! Now you can return to the tutorial and test your card.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And don't forget to have fun!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJL8+C0AAoJEMPdciX+bh5InokH/17+dG0bYU05dTqHVOIDUKch
dGJ75jnO3cci9UcZeqghyH0Odi1uPpidRLWKjd1EogHNo24fb6/CwyL+6yUgW/RF
No0YOKG2r6dJGqpD91v5afd70JSkwMo66CRBpsou5TM6b6bG2p6dHVg3r2pJOKwJ
WoMbrsgHAAX7pGpAjhjREMLTIADwh5+5d1aQJx3qTjWNh908PVm+KN1iT9eryBWE
UJb98O6Zj02I4OTX3VsBmC29FyjfISBJ7LIElZQFTV7I3BIE+FDK9H9Hnb/3psF+
G/VOgHPILzd+BxuUzo4PGVne2GMPHv6vmm+yQlgvuz5Bnn/duU8gWVc+erDC2xQ=
=K7tA
-----END PGP SIGNATURE-----

Many thanks to the people involved in this thread on the GnuPG mailing list for the tip!