I've been hacking on a copy of BackupPC_archiveHost to run archives through GPG before saving them to disk.  The reason for this is that, when I say "saving to disk," I mean saving to an Amazon s3 share mounted locally via s3fs.  Apparently the policy makers here don't trust Amazon sysadmins to stay out of their data.  Needless to say, we're preparing for a disaster recovery scenario in case the building, with all our machines and backuppc server inside, burns down to the ground.

Anyway, I thought I had it all figured out, but when I decrypt, gunzip, and untar the resulting file, I get some "tar: Skipping to next header" messages in the output, and, although I do get some files out of the archive, eventually tar just hangs.  I was bouncing some ideas off a colleague of mine, and he suggested I was going about this all wrong: "So you have a nice non-redundant repo, and you want to make it redundant before you push it over the net??? Talk sense man!"

The main question:

He thinks it would be more bandwidth-efficient to tar up and encrypt the pool, which accounts for duplicate files and so forth, and send that over to s3.  I counter that the pool will contain data concerning the last 2 weeks or so of changes, which I'm not interested in for the purposes of disaster recovery, and that transferring over that extra data is less efficient.  Who's right?  And if it's my colleague, which folders should I be interested in?  It looks to me like cpool, log, and pc, as pool is empty for me (I use compression on all backups).