❯ The 3-2-1 Backup Rule for Small Teams That Actually Works

2026-09-09 · Ops, Founder ·3 min read

by Jonas Reyes — the builder's desk, Side Quest Studios September 10, 2026

The 3-2-1 backup rule that small teams can actually keep

A backup you have never restored from is a hope, not a backup. The 3-2-1 rule survives because it is simple enough to remember and realistic enough to keep.

The rule

Three copies, two media, one offsite. Each number removes a different way of losing everything:

3 copies of anything you cannot lose — the original plus two backups. Two is the minimum that survives a single mistake, because a deleted file replicates to the other copy before you notice.
2 different media — e.g. the live disk and an external or object store. Two copies on the same disk are one failure away from both being gone. This is the number people quietly skip: a second folder on the same machine is not a second copy.
1 offsite — somewhere that survives your building, your host, or your account being locked. Offsite is what saves you from the failure mode where the whole provider disappears at once.

The original 3-2-1 explainer is worth five minutes; the rule has not needed updating for years, which is the point.

Where small teams actually fail

Not the copying — rsync(1) and object storage make copying easy. Teams fail at knowing the backup works.

Three failure modes recur, and all three are silent:

The job stopped running. A cron entry that was edited, a credential that expired, a disk that filled. The schedule looks fine in the config and has not fired in eleven weeks.
The job runs and produces nothing. It exits 0 and writes an empty archive, because the path moved. Exit codes report that the program did not crash — not that you got your data.
The backup is unreadable. It produced bytes, but the encryption key is gone, or the archive is truncated, or the tool version that wrote it no longer matches the one reading it.

The most expensive kind of confidence is a job that has run nightly for a year and would not restore a single byte. Nobody notices until the day it matters, which is exactly the day you cannot fix it.

The schedule that holds

Automate the copy — nightly, offsite, unattended. If it needs a person, it will stop the first week that person is busy. rclone covers most object stores with one config file.
Have the job report a size and an age, not just an exit code. "Backup completed: 4.2 GB, 12 minutes, target 6 hours old" is a sentence you can alert on. "exit 0" is not.
Alert on the absence, not just the failure. The dangerous case is the job that never started; a heartbeat is the only thing that catches it.
Run one real restore drill, on purpose, this quarter. Not ls the backup directory — restore a file to a scratch machine and open it. Put it in the calendar like a meeting.

What to actually back up

Most teams back up too much and restore too little. The things you cannot re-derive: the database, the uploaded files, the configuration, and the secrets store. Everything else — containers, dependencies, build artifacts — you can rebuild from source in minutes. Backing up 200 GB of caches makes the job slow, the storage expensive, and the failure list long enough that nobody reads it.

Try it once

Write down the three things you would lose if the disk died right now, then check when each was last backed up. If you cannot answer from memory, neither can anyone else on the team.

bash bash (80x24)

# is the job still running at all?
$ systemctl list-timers --all | grep -i backup

# does the newest archive look like a real size?
$ ls -lh /backups/ | tail -5

Those two commands answer "still running?" and "still producing?" in about four seconds. Run them monthly.

The part 3-2-1 does not cover

The rule protects against losing data. It does not protect against losing it quietly. Ransomware that encrypts your live copy will happily encrypt the mounted backup drive too, which is why the offsite copy should be append-only or versioned — something that a compromised machine cannot rewrite. Versioning is what turns "3 copies of a corrupted file" into "the version from before Tuesday".

The point is not paranoia. It is that the day you need a backup is the worst possible day to discover you do not have one.

References

AI-assisted, curated for Side Quest Studios.