What I Would Do If I Ran Tarsnap

Interesting article. I'd actually not heard of Tarsnap before, one question (to those who use it), why would a geek use it over:

  tar -cf - / --exclude='/proc/*' --exclude='/dev/*' [..] | \
      xz -z | \
      openssl enc -aes-256-cbc -e -salt | \
      > /mnt/your/networked/google/drive/backup.$(hostname -a).$(date "+%Y%m%d-%H%M%S").aes.tar.xz

I spent a while going through https://www.tarsnap.com/ and I didn't find any flexibility tarsnap offers over it. To make it work unattended, it's trivial to generate a unique key per backup for openssl (use a tmpfs) and then gpg encrypt the key and email it to sys admins or whatever mailing list before killing the tmpfs.

I could understand the appeal to less tech savvy users if there were a gui, or it featured cross platform support beyond those supported by tar, <insert compression tool>, openssl/aespipe/gpg/<insert encryption tool>, or the storage was super cheap.

So what's the value proposition here?

Data deduplication, incremental backups.

Heh apologies, my fault for trying to be clever, the mechanism I actually use is incremental and deduplicated. I substituted it for tar to simplify.

I actually use ZFS (filesystem), so my backup flow is closer to:

  TSTAMP="backup-$(date "+%Y%m%d-%H%M%S")"
  zfs snapshot -r $TSTAMP
  zfs send $TSTAMP | \
      xz -z | \
      openssl enc -aes-256-cbc -e -salt | \
      > /mnt/your/networked/google/drive/backup.$(hostname -a).$TSTAMP.aes.tar.xz

The underyling ZFS filesystem is deduplicated at filesystem level, and snapshots are incremental. THere're a few other minor differences (the dest is another ZFS host which syncs to Google drive, and I nuke the local snapshot after send because RAID 1+0 space is more expensive than RAID1 .. )

To answer my own question: deduplication :)

I had not considered multiple backup sources, mine is deduplicated per host, am I to understand tarsnap is deduplicated across all hosts sharing a set of keys?