---
title: "The 3-2-1 backup rule when everything is a managed service"
description: "Three copies, two media, one offsite. The rule was written when you owned the hardware. Here is what each clause means when you own none of it, and which one still matters most."
url: "https://saved.sh/blog/the-3-2-1-rule-in-a-cloud-stack"
date: "2026-08-08"
author: "saved.sh"
tag: "Engineering"
---

The 3-2-1 rule is the most quoted advice in backups: **three copies of your data,
on two different media, with one offsite.**

It was written for a world of tape drives and a fireproof safe, and it is still
mostly right. But two of its three clauses need translating before they mean
anything to a team whose entire infrastructure is somebody else's computer.

## Clause by clause [#clause-by-clause]

**Three copies.** Translates cleanly. Your production data plus two more. This
one never needed updating.

**Two different media.** Meaningless as written. You do not have media. You have
one object storage API, and choosing between two storage classes inside it is
not what the original rule was protecting against. The intent behind "two media"
was *do not let one failure mode take both copies*, and in a cloud stack the
equivalent axis is not media, it is **account and provider**.

**One offsite.** This is the clause that survived intact, and it is the one most
often faked. "Another region in the same account" is not offsite. The failure
that takes a modern company's data is almost never geographic.

<Figure caption="The modern axis is not media. It is which credentials and which organisation can reach each copy.">
  <DestinationsFan />
</Figure>

## The translation [#the-translation]

| Original     | What it protected against             | Cloud equivalent                                              |
| ------------ | ------------------------------------- | ------------------------------------------------------------- |
| Three copies | Any single copy being lost or corrupt | Production, plus two independent copies                       |
| Two media    | One technology failing across both    | Two **accounts**, ideally two **providers**                   |
| One offsite  | The building burning down             | One copy outside the blast radius of your primary credentials |

So the working version for a cloud-only stack:

**Three copies, in two accounts, with one under credentials your production
environment does not hold.**

That last clause is the whole rule now. Everything else is commentary.

<Stats>
  <Stat value="3" label="Copies" />

  <Stat value="2" label="Accounts, not media" />

  <Stat value="1" label="Set of credentials production cannot reach" />
</Stats>

## Why the credential boundary replaced the physical one [#why-the-credential-boundary-replaced-the-physical-one]

The 1980s threat was fire, flood and theft, and geography was a good proxy for
independence. Two buildings genuinely did not fail together.

Today the overwhelmingly common cause of total data loss is a compromised or
misused credential, and geography is no proxy at all. An access key with
`s3:DeleteObject` on your backup bucket has exactly the same reach whether that
bucket is in the next rack or the next continent. A Terraform state that manages
both regions destroys both regions with one command.

So the question to ask about each copy is not where it is. It is: &#x2A;*which
credentials can delete this, and does anything in production hold them?**

If the answer is "the same key that runs my application", you have one copy
wearing three hats.

## A realistic 3-2-1 that people actually maintain [#a-realistic-3-2-1-that-people-actually-maintain]

The version that survives contact with a small team:

1. **Production data.** Copy one, free.
2. **Provider snapshots**, automatic, inside the provider. Fast recovery for
   ordinary mistakes. Copy two, nearly free, and not independent.
3. **A portable dump in a bucket in a separate account**, with Object Lock in
   governance mode and credentials that exist nowhere in production. Copy three,
   and the only one that satisfies the real rule.

Three copies. Two accounts. One outside the blast radius. It is achievable in an
afternoon and it is dramatically better than what most teams have.

<Aside title="The test that replaces the fireproof safe" tone="accent">
  Take the credentials your production environment holds. List everything they can
  delete. If your backups are on that list, you have two copies and a rounding
  error, however many regions they are spread across.
</Aside>

## Where we fit [#where-we-fit]

Copy three is the one we exist to make easy, and we make it deliberately
independent: it lands in a bucket you own, under credentials we hold no copy of,
encrypted before it leaves the machine that produced it.

We also do not need delete permission on your bucket and do not ask for it by
default. If you never grant it, expired copies simply stay where they are and we
cannot remove them. That is the correct default for a copy whose entire purpose
is being outside everyone else's reach, including ours.

## The one-line version [#the-one-line-version]

Three copies, two accounts, one set of credentials your production environment
has never seen. If you get only the third clause right, you have most of the
value of the rule.