The 3-2-1 rule was born in a world of local disk and tape: three copies of the data, on two types of media, with one offsite. It survived because it's easy to remember and because it captures a correct idea — redundancy is only useful when the copies fail for different reasons.

The problem is that, in the cloud, it's trivial to satisfy all three numbers on paper and still have just one copy in practice. A source bucket, a replica bucket in another region and versioning enabled give you three distinct artifacts. If all three live in the same account, answer to the same administrative credential and are governed by the same policies, they share the most likely failure mode. The count says three. The failure domain says one.

What each number protects

It's worth taking the rule apart before applying it.

The 3 (three copies) protects against independent media failure. The premise is probabilistic: if each copy fails on its own, the chance of all of them failing at the same time is the product of the individual chances. The premise collapses entirely when failures are correlated.

The 2 (two media) exists to break that correlation. Two disks from the same batch, on the same controller, with the same firmware, are not two media for practical purposes — they are two instances of the same risk. The rule asks for technologies that don't fail from the same defect.

The 1 (one offsite) protects against the event that hits the entire site: fire, flooding, theft, extended power outage. It's the only part of the rule that deals with a disaster that has a blast radius, rather than with a component.

Note that none of the three numbers mentions permissions, identity or APIs. When the rule emerged, that wasn't an omission: to erase the tape you had to touch the tape.

In the cloud, the boundary that matters is the account

The useful question isn't "how many copies do I have?". It's "what has to go wrong for me to lose all of them?". In the cloud, the answer almost always points to the account — or tenancy, or subscription, depending on the provider.

Within a single account, these events reach every copy at once:

Compromised administrative credential. Whoever has the power to create policy has the power to remove protection and delete. A replica in another region obeys the same root of trust.
Faulty in-house automation. A cleanup script with the wrong prefix, a lifecycle policy applied to the wrong bucket, a terraform destroy in the wrong workspace.
Lifecycle policy. An expiration rule created by one team coexists badly with retention created by another. The data disappears without anyone having deliberately deleted anything.
Account suspension or termination. Non-payment, suspected fraud, contractual dispute. Access drops for everything under that billing identifier.
Deletion of the project or compartment itself. The container disappears along with its contents.

Any one of these events turns three copies into zero. That's why, for 3-2-1 purposes, copies that depend on the same credential and the same policy count as one.

Versioning and replication are not the second copy

Two cases deserve to be named, because they show up often in architecture design.

Versioning keeps previous versions of an object in the same bucket. It protects against overwrites and against simple accidental deletion — the deletion creates a marker, and the old version is still there. It doesn't protect against version deletion by someone with permission to do so, nor against removal of the bucket, nor against a lifecycle rule that expires noncurrent versions. It's a feature within the same infrastructure object, described in the S3 versioning documentation. Count it as local resilience, not as a copy.

Cross-region replication covers regional unavailability and media loss at geographic scale. It doesn't cover an authenticated command: replication is unidirectional for the data, but the control plane is shared. An attacker with permissions in the account edits the replication configuration or deletes the destination bucket. Worse: if replication propagates deletions, it's a damage channel, not a barrier. That's exactly the point addressed in backup is not synchronization — a mirror obeys the source, and whatever obeys the source goes down with it.

What counts as "offsite" when everything is cloud

Translating the three numbers into primitives that exist today:

Two media becomes two control planes. It's not about disk versus tape. It's about the secondary copy not answering to the same set of APIs, the same IAM policy and the same billing mechanism as the primary. A different storage class within the same account is not a second medium: the class changes price and latency, not the control boundary.

Offsite becomes, in increasing order of independence:

Another region, same account. Covers regional physical disaster. Doesn't cover credentials.
Another account with the same provider, with a separate identity. Covers credentials and automation from the production account. Doesn't cover suspension of the parent contract or a provider control plane failure.
Another provider, with a credential that doesn't exist at the source. Also covers account termination and vendor incidents. That's the design described in cross-cloud bucket backup.

There's a simple test to figure out which rung you're on. List every credential capable of deleting the primary copy. Then list those capable of deleting the secondary. If there's an intersection, the set is a single copy as far as risk is concerned. Do the same exercise with the invoice: if both copies disappear when a card is declined, they depend on the same event.

The secondary copy also needs to be writable without being deletable. The identity that writes to the destination should have no permission to delete objects or versions, and the destination should carry immutable retention — the full reasoning is in immutable backup with Object Lock, and the behavior of the retention modes is in the S3 Object Lock documentation.

The 3-2-1-1-0 variant

An extension circulates in the market: 3-2-1-1-0 — the first three positions unchanged, plus one offline or immutable copy, and zero errors in verification. It's not a norm, not a standard published by any technical body, and it doesn't replace risk analysis. It's a handy nickname for two practices that already stand on their own.

The extra 1 recognizes that "offsite" stopped being enough once the remote site became reachable by API. Offline (disconnected media) or immutable (retention nobody can remove before the deadline) are the two ways of making that reach impossible, and they are not the same thing.

The 0 is the most neglected part: verification with a zero-error result. Verifying means reading the data back and comparing it against your own checksum, not checking whether the object exists and has the expected size. And it means actually restoring, timed, with the real identities — the subject of why restore is the part nobody. Add the encryption key to that zero: an independent copy from which nobody can extract the data is noise with retention, the topic of who can open your backup.

The cost of independence

Separating the secondary copy costs money, and the cost has a predictable shape. The typical structure combines per-request charges (LIST, GET and PUT count in their own categories), data egress charges at the source, storage in the chosen class and, in cold classes, minimum billable days and an early deletion fee. I'm not publishing numbers here because price tables change and a wrong price is worse than no price: open your provider's pricing page, for the exact region of the bucket, and add up the five components before turning on the first cycle. What usually escapes that sum is covered in what disappears from the bill of cheap storage.

Checklist

List the credentials that reach each copy. A non-empty intersection means a single copy.
Versioning and replication count as local resilience, not as the three copies.
The secondary copy lives under an identity that doesn't exist in the source account.
Whoever writes to the destination doesn't delete: no DeleteObject, no DeleteObjectVersion.
Immutable retention at the destination, with a period longer than realistic detection time.
Lifecycle policy reviewed together with retention, never separately.
Encryption key stored outside the backup server, with a tested copy.
Verification with your own checksum and at least one full, timed restore.
Separate invoice, or at least a payment method that doesn't go down along with production's.

Three copies that die from the same command are not three. The rule still holds; what changed is what counts as "site".

NubliVault is Nublify's backup product: it packs millions of small files and stores them in a cloud different from the source. How it works · Security