What Is the 3-2-1-1-0 Backup Rule?

The 3-2-1 rule has guided backup design for decades: three copies of your data, on two different media, with one copy offsite. Ransomware and silent failures pushed the industry to extend it to 3-2-1-1-0. This article explains each number and shows how to apply the rule to real servers, databases and virtual machines.

The rule at a glance

3: three copies

Production counts as one copy. You need two more. The reasoning is probabilistic: if each copy has a small, independent chance of being unavailable when you need it, the chance of losing all three at once becomes very small. The key word is independent. Two backups on the same disk, or two buckets in the same account with the same credentials, can fail together.

2: two different media

The original rule talked about disks and tapes. Today the idea is to avoid a single technology or system as a common point of failure. Examples of combinations:

• a local backup server with disks plus S3-compatible object storage;
• a NAS plus tape or removable disks;
• a Proxmox Backup Server plus a second PBS using different storage hardware.

Different media also usually means different software stacks and credentials, which limits how far one bug or one compromised account can spread.

1: one copy offsite

At least one copy must live in a location that does not share physical risks with production. "Offsite" means a different building or, better, a different region. For cloud workloads, it also means a different provider account, and possibly a different provider, so that an account suspension or a provider-wide incident does not take production and backups at once.

Distance matters: a second room in the same building does not protect against a fire that spreads; a data center two kilometers away may share the same flood plain or power grid.

1: one immutable or offline copy

This addition responds to ransomware. Attackers who gain administrator access look for backups and delete or encrypt them before encrypting production. A copy that cannot be modified or deleted for a defined period, even by an administrator, breaks that strategy.

Ways to achieve it:

• Object storage with S3 Object Lock in compliance mode, which prevents deletion until the retention date.
• Offline media such as tapes or disks that are disconnected and stored elsewhere.
• Pull-based replication where the offsite system fetches backups and the production side holds no credentials to delete them. This is not strict immutability, but greatly reduces the attack surface.

Versioning alone is not immutability: anyone with permission to delete versions can still remove them.

0: zero errors

The last number is about evidence. A backup strategy is only proven when backups are verified and restores are tested without errors. That includes:

• checksums or integrity verification of stored backups;
• monitoring that alerts when a backup fails or does not run;
• regular restore tests of files, databases and whole systems;
• documenting and fixing every error found.

"Zero" does not mean nothing ever fails. It means you find failures during tests, not during incidents.

Applying the rule: three examples

Small business with one Linux server

• Copy 1: the production server.
• Copy 2: nightly encrypted backup to a NAS in the office.
• Copy 3: the same backup uploaded to S3-compatible cloud storage in another region, with Object Lock retention of 30 days.
• Monthly restore test of a few files and the database dump to a laptop or VM.

Proxmox cluster

• Copy 1: guests on the cluster storage.
• Copy 2: local Proxmox Backup Server on separate hardware, with verify jobs.
• Copy 3: offsite PBS that pulls the datastore through a sync job, or an S3-backed datastore in another region.
• Immutability: credentials of the cluster cannot delete offsite snapshots; optional Object Lock on the bucket.
• Quarterly restore of a full VM on another node. See how to back up Proxmox VMs to the cloud.

Docker host with databases

• Copy 1: volumes on the host.
• Copy 2: nightly database dumps and volume archives on a second server.
• Copy 3: encrypted upload to object storage with upload-only credentials.
• Weekly automated restore of the database dump into a test container. See Docker backup best practices.

Common misconceptions

• "RAID is a copy." RAID protects against disk failure, not against deletion, corruption, ransomware or site loss.
• "Snapshots are backups." Snapshots on the same storage system share its failures. They are excellent for fast rollback, but count as at most one copy, and not an offsite one.
• "Sync is backup." File synchronization replicates deletions and encrypted files immediately.
• "The cloud provider backs up my data." Most providers protect their infrastructure, not your data against your own mistakes. Read the shared responsibility model of your provider.

How to start

1. List your systems and count, for each one, how many independent copies exist today and where.
2. Add an offsite copy for anything that has none.
3. Make at least one copy immutable or unreachable from production credentials.
4. Schedule restore tests and track their results.
5. Estimate the storage you will need with our sizing guide.

Backnix is designed to provide the offsite, encrypted copy in this rule, in the region you choose. See cloud storage and backup security for details and current availability.

References

• CISA: #StopRansomware Guide (offline, encrypted backups)
• Amazon S3 User Guide: Locking objects with Object Lock
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems

Topics: 3-2-1 ruleBackup strategyImmutable backup