Earlier I wrote about remote encrypted backups with duplicity [1];
for the last while I have been using that method to back up my
CVS repository to my shell account at Dreamhost.

A few weeks ago Dreamhost started sending me nastygrams saying I
either had to remove these encrypted backups or start paying
$.20/GB/month for that "non-web" space, even though I was using
less than 20% of my 600+GB disk quota. That was pretty annoying
since I had explicitly asked them about this and was informed
that doing so would be OK as long as I didn't use the space to
store illegal content.

So I decided to try using Brackup [2] again to encrypt and store
my data in Amazon S3 instead. It was a bit of a pain to get all
the dependencies installed but once I had done that Brackup
worked really well and I'm pretty impressed with it overall.

Advantages over duplicity include:

 - if brackup is interrupted, it seems really good about
   continuing where it left off the next time you run it.

 - brackup tracks the state of its backups in sensible
   human-readable files.

 - brackup only needs access to your private key when restoring
   data from an encrypted backup; duplicity inexplicably
   requires it (and requires you to enter your passphrase) when
   backing up data as well. (as far as I can tell, anyway)

 - brackup spawns a number of child processes to parallelize the
   process of encrypting (and uploading?) files.

Brackup seems to have a bug in the way it handles temporary
files: my /tmp filled up with thousands of encrypted files while
it was uploading my 55 GB of data to S3, and at the rate it was
going it would have filled up my /tmp before it finished so I ran
this in another window:

   while true ; do find /tmp -type f -user gerald -newer /tmp/gpg-Cx83lJ/
   -name "??????????" -mmin +60 | xargs rm ; sleep 5m ; done

(I first used -mmin +10 but that caused brackup to fail and exit
when it went looking for one of those temp files more than 10
mins after it was created; nothing bad seems to have happened
with +60)

Brackup does erase all those temp files on its own before finishing,
so maybe the large number of files was simply due to the large
number of files I was backing up at once (about 200k of them).
And I'm not completely sure my find | rm was needed at all.


I didn't keep notes on what I had to install to get brackup
running, but here is a list of various debian packages I
installed in the process (thanks to /var/log/dpkg.log):

   libdbd-sqlite3-perl
   make
   liblog-log4perl-perl
   libxml-namespacesupport-perl
   libxml-sax-perl
   libxml-libxml-common-perl
   libxml-libxml-perl
   libxml-simple-perl
   libnet-amazon-perl
   libclass-accessor-perl
   libdata-flow-perl
   libxml-parser-perl
   libxml-xpath-perl
   libxml2-dev
   zlib1g-dev
   libxml2-utils
   libxml-perl
   gcc
   gnupg-agent
   pinentry-curses

(not all of these are actually needed; in particular I think I was
barking up the wrong tree with a bunch of the libxml-* ones.)

There were a few perl libraries required for which there are no
debian stable packages; I installed those from CPAN. I think they
should be pretty easy to find. That took me longer than it should
have because I didn't have a C compiler installed and cpan kept
spitting out inscrutable errors instead of something useful like
"hey bozo, you need a compiler to compile stuff"

Now I plan to cancel my Dreamhost account; their $.20/GB/mo for
backup disk space isn't much more than amazon's $.15 but they
lied to me so they don't deserve my money. (also, I wasn't using
my account there for anything besides storage, so no sense paying
the $16/mo or whatever base rate +$.20/GB/mo)

[1] http://impressive.net/archives/fogo/[email protected]

[2] http://code.google.com/p/brackup/
   http://search.cpan.org/~bradfitz/Brackup/

--
Gerald Oskoboiny <[email protected]>
http://impressive.net/people/gerald/