The 3-2-1 rule and why two more numbers got added to it

Why this matters

You make backups in case of a disaster. But a disaster rarely hits one spot: an entire server burns down, ransomware works through every disk it can reach, a provider locks an account completely. The 3-2-1 rule answers a simple question: where should copies live so that one disaster can't reach all of them at once?

The classic formula

The 3-2-1 rule was formulated before the cloud went mainstream, and it still holds up:

• 3 copies of the data, counting the original;
• on 2 different types of media or in two different storage systems;
• 1 copy off-site.

The logic is simple: one disaster shouldn't be able to reach all the copies at once.

Why three, not two

Two copies look good enough right up until the first disaster. A disk dies, you restore from the only backup you have, and at that point you're left with no buffer: while the restore is running, there's no second copy at all.

Add a typical case where the backup turns out to be corrupted, and it becomes clear why you need a third instance. The third copy buys you the right to one mistake.

Why two different media types

Identical devices fail in identical ways. Disks from the same batch die around the same time, a buggy file system corrupts data across all its volumes, and a bug in a controller's firmware takes down the whole array.

So copies get spread across different kinds of storage: local disks and object storage, the server's file system and a NAS, one provider's cloud and another provider's cloud.

In a cloud world, "two media types" reads as "two independent systems": a VM's disk and an object storage bucket are different systems even if they physically sit in the same data center.

Why one copy off-site

Fire, flooding, a long power outage, equipment seizure, a provider locking an account. All of these take out an entire site along with its local copies.

An off-site copy lives in a different data center, a different region, with a different provider, or on a disk that gets physically driven away. What matters isn't distance by itself, but the absence of a shared point of failure: shared power, a shared network, a shared account.

A word on accounts specifically. If both storage locations sit under the same cloud account, then locking that account or someone hijacking access to it makes both copies unavailable at once. Formally they're in different regions; in practice they depend on the same thing.

The added numbers: 3-2-1-1-0

Ransomware changed the threat model, and two more positions got added to the rule.

One: an immutable or offline copy

1 copy must be immutable or offline. In object storage that's object lock; on tapes and removable disks it's simply being disconnected from the network.

The point is that an account with permission to delete backups will sooner or later get compromised. An immutable copy has to survive even an administrator whose access was stolen.

There's a detail here that's often missed: immutability comes in different strengths. S3 Object Lock has two modes:

• governance. A user with the s3:BypassGovernanceRetention permission can delete the object or remove the lock by sending the x-amz-bypass-governance-retention:true header. The AWS console sends this header by default, so an administrator deletes such an object with the ordinary button.
• compliance. No one can delete or overwrite the object, including root, until the retention period expires. The period can't be shortened, and the mode can't be changed. The only way around it is to delete the entire AWS account.

One more S3 detail: Object Lock only works in a bucket with versioning enabled, and it protects a specific object version. A plain DELETE without a version number succeeds and places a delete marker on top. The object disappears from the listing, while the protected version stays in place and can be restored.

Azure Blob Storage works on similar logic. A time-based retention policy is first created unlocked. It already forbids deleting or overwriting data, but the policy itself can be shortened or removed. After it's locked, the policy can no longer be deleted or shortened, only extended.

So "we turned on object lock" isn't an answer by itself. The question is which mode it's turned on in, and who can change that mode.

Zero: an unverified copy doesn't count

0 errors on verification. A copy only counts as a copy after it passes verification: checksums match, and a test restore succeeds.

These two checks catch different things. A checksum (SHA-256, for example) shows that the file hasn't changed since the checksum was computed. It catches an archive that got corrupted in storage or in transit. But if the backup job archived an empty folder or a broken file, the checksum is honestly computed from that already-bad archive and will match on verification. Only a restore catches a copy like that: unpack it, start the database, or compare it with the working data.

Here's what a checksum check looks like when the archive is corrupted:

orders-2026-10-08.tar.gz: FAILED
sha256sum: WARNING: 1 of 1 computed checksums did NOT match

What this looks like in practice

A small service:

• working data on the server (copy one);
• a nightly backup to the same provider's object storage (copy two, a different storage system);
• a weekly export to another provider's storage with object lock enabled for 30 days in compliance mode (copy three, off-site and immutable);
• a monthly test restore with a checklist entry (that's the zero).

It's not an expensive setup, yet it covers a disk failure, deletion, losing a provider, and ransomware.

Common mistakes

• Counting a backup as one of the three copies when it's never been restored from. Until it's been verified, you don't know whether there's any data in it at all.
• Keeping both copies under the same cloud account, even in different regions. A locked account or a stolen admin key takes out both.
• Turning on Object Lock in governance mode and treating the copy as undeletable. A user with s3:BypassGovernanceRetention will delete it from the console.
• Checking only checksums. An empty or incomplete archive with a correct checksum won't be caught.
• Copying a backup to a NAS that's mounted on the same server with write access. Ransomware on the server will encrypt that too.

What you'll need for the tasks

• docker exec -it <container> sh to open a shell inside the container;
• ls -l for file sizes;
• sha256sum -c <file>.sha256: check the archive against the recorded checksum (run from the folder where the archive lives);
• tar -xzf <archive> -C <folder>: unpack a .tar.gz into the given folder;
• cmp <file1> <file2>: compare two files byte by byte, silent if they're identical.

Next we'll break down what a backup is actually made of: full, incremental, and how much of it to keep.