The 3-2-1 Backup Rule, and Where It Stops Being Enough

Keep three copies of your data, on two different types of media, with one of them offsite. That is the whole rule, and it has survived thirty years of changing technology because each number answers a different way of losing data.

Go back to the fire escape from the backup and recovery guide. Three copies is having more than one way out of the building. Two media types is making sure both routes are not built from the same material that fails in the same fire. One offsite is accepting that the whole building might be gone.

What each number is protecting you from

Three copies covers the ordinary case: a disk dies, a file gets deleted, someone overwrites a spreadsheet. Production plus two backups means one backup can be broken or mid-rotation and you are still covered.

Two media types covers correlated failure. Two backup sets on the same storage array share a controller, a firmware version and a power supply. When that shared thing fails, both copies fail together, and you learn that you never had two copies at all.

One offsite covers the site itself: fire, flood, theft, or a building you cannot get into. This is the number people most often satisfy on paper and not in practice, usually with a drive that lives in the same room as the server.

Where the rule stopped being enough

The rule assumes failures are accidental. Ransomware is not accidental, and it specifically looks for backups.

If your backup server is domain-joined and reachable with the credentials the attacker already stole, then your three copies are three targets. Attackers routinely delete or encrypt backup repositories before touching production, precisely so that paying is the only option left.

This is why most current guidance adds two conditions to the original three:

• One copy immutable or offline. Storage that cannot be modified or deleted for a defined retention window, or media that is physically disconnected. The point is a copy that stolen credentials cannot reach.
• Zero errors on restore test. Not “the job reported success” but a documented restore that produced working data; running a restore test that produces evidence has its own article.

What to actually check this week

Open your backup configuration and answer three questions honestly. Where does each copy physically live? Which credentials can delete each one? When did someone last restore from each, and what did they restore?

If the third question has no answer, you have a backup schedule rather than a backup strategy. That gap is worth more attention than any change to the schedule itself.