The 3-2-1 backup rule, and why a backup you never restored is not a backup

The 3-2-1 rule is the shortest useful summary of backup design. Keep three copies of your data (the live copy plus two backups), on two different kinds of storage, with one copy somewhere else. Each number closes a specific hole, and if you know which hole, you can tell when it is safe to bend the rule and when it is not.

What each number protects against

• 3 copies: a single backup can be corrupt, half-written or deleted by the same mistake that destroyed the original. With two independent backups one bad copy is an inconvenience, not a disaster.
• 2 media types: two copies on the same disk, the same RAID array or the same cloud account share a single failure. A dead controller, a filesystem bug or a compromised account takes both. Different media means a different failure domain: local disk plus object storage, a NAS plus an external drive, a server plus a tape.
• 1 off-site: fire, flood, theft and a ransomware operator who found your NAS all happen in one place. A copy in another building or another provider survives the event that destroys the room.

Modern variants add a digit: 3-2-1-1-0 means one copy is also offline or immutable (it cannot be changed by anything that has your credentials, such as an object-lock bucket or an unplugged drive) and the backups verify with zero errors. The immutable copy is what saves you from ransomware that deliberately encrypts the backups first.

The rule in practice

A small server following the rule could look like this: nightly database dumps on the server itself (copy 1, live data plus local dump), a restic repository on a NAS in another room (copy 2, different media), and the same restic repository synced to an S3-compatible bucket with versioning or object lock (copy 3, off-site and immutable). Proxmox users get the same shape with a Proxmox Backup Server datastore plus a remote sync job.

restic -r /mnt/nas/restic snapshots --latest 1
rclone sync /mnt/nas/restic s3:my-backups/restic --dry-run
rclone check /mnt/nas/restic s3:my-backups/restic --one-way

The first command shows the newest local snapshot, the second previews what would be copied off-site, and the third confirms the off-site copy matches. If you cannot answer “where are my three copies and when was each last written” from memory, write it down next to the scripts.

Why an untested backup does not count

A backup is a promise that data can come back. Until you restore it, the promise is unverified. Common ways backups fail silently:

• The job runs but backs up the wrong path, an empty mount point, or a directory that moved a year ago.
• The dump is written while the database is open, so it is inconsistent and will not import.
• The encryption key or repository password exists only on the machine that just died.
• Retention deleted the snapshot you needed before anyone noticed the original was corrupted.
• The restore tool, its version or the credentials needed to read the backup are not available on a fresh machine.

None of these show up as a failed job. All of them show up in a restore drill. So the strategy is not complete until it includes a schedule for restoring: pick a file or a database at random, restore it to a scratch location, compare it, and write down how long it took. That number is your real recovery time. The companion article Restore drill: prove your backup works in 15 minutes walks through the procedure.

Decide two numbers before you pick a tool

• RPO (recovery point objective): how much data you can afford to lose, which sets how often you back up. A nightly dump means up to 24 hours lost.
• RTO (recovery time objective): how long the service may be down, which sets whether you need a file-level backup, a full image, or a warm standby.

Write both down per system. A wiki can survive a day of lost edits and a few hours of downtime; a billing database cannot. The tools, schedules and copies then follow from those numbers instead of from habit.

Official documentation

• CISA: Data Backup Options (3-2-1 rule)
• restic documentation
• Proxmox Backup Server documentation