Tarsnap
Paranoid backups on S3, EC2, and one developer’s C code
Colin Percival’s Tarsnap is online backup for the truly paranoid: client-side encryption and deduplication, a log-structured filesystem on Amazon S3, and a tiny EC2 footprint for metadata. Solo operator, published architecture, no hype stack.
2006–2008
AWS as building blocks, not a religion
Amazon EC2
Amazon S3
Custom C server
FreeBSD tooling
Percival started Tarsnap in 2006 while already deep in FreeBSD security work. His December 2008 blog post walks through the design: all user data lands in S3; EC2 runs a cache and cleaning processes because S3↔EC2 bandwidth is free.
Incoming writes log to S3 before the server acknowledges the client — S3 is the source of truth, EC2 is replaceable. No venture deck, no sharded hipster database on day one.
Lesson
Pick cloud primitives that match your failure modes. If EC2 dies, replay logs from S3 — design for that on purpose.
2008–2012
Public beta, outage drills, boring recovery
Amazon EC2
Amazon S3
Log-structured backup store
Client-side crypto
Tarsnap reached public beta with architecture documented on daemonology.net and in conference talks (EuroBSDCon slides describe the full client/server split). The client deduplicates and encrypts before upload; the server never sees plaintext.
A July 2012 outage tested the worst case: EC2 power loss and filesystem corruption. Recovery meant replaying operation logs from S3 — slow, scary, and exactly what the design promised. Percival wrote up every lesson.
Lesson
Document your disaster recovery before Twitter documents it for you. “Rebuild from S3 logs” is a feature, not an embarrassment.
2013–today
Still minimal, still paranoid, still solo-scale
Amazon EC2
Amazon S3
scrypt/spiped/kivaloo ecosystem
CLI-first UX
Years later Tarsnap remains a command-line tar frontend with cryptography done right — not a dashboard company. Percival continues publishing on daemonology.net about AWS quirks, FreeBSD on EC2, and backup engineering.
The stack did not pivot to multi-region Kubernetes. It doubled down on correctness, auditability, and a user base that reads source code for fun.
Lesson
Security-sensitive infra rewards boring storage and explicit logs over fashionable orchestration layers.
Sources
- Colin Percival — How Tarsnap uses Amazon Web Services (2008)
- Colin Percival — Tarsnap outage post-mortem (2012)
- EuroBSDCon — From bsdtar to tarsnap (architecture talk PDF)
Facts drawn from public engineering posts and interviews. Numbers are approximate where sources disagree — we're stack advisors, not historians.
Get the right stack for YOUR scale — not theirs
Tarsnap's stack made sense for Tarsnap. Yours won't — and copying theirs is how you end up with a $4k/month bill and three unused Kubernetes clusters.
Plan my stack — free