Cloud Platform
The 3-2-1 rule is old, widely quoted, and still routinely misapplied. It says: keep three copies of your data, on two different types of media, with one copy off-site. Most organisations that believe they follow it are actually running one copy in two places, which is a very different thing.
Where the rule gets misread
"Three copies" means three, including the original
Your production data is copy one. So the rule asks for two backups, not three. Teams that read it as "three backups" over-engineer; teams that read it as "production plus one backup" under-engineer. The second reading is far more common and far more dangerous.
"Two media types" means genuinely different failure modes
Two volumes on the same storage array are not two media types. Neither are two folders on the same file server. The point is that a failure which destroys copy one should have no mechanism to destroy copy two. Ask what single event could take out both — a controller failure, a bad firmware update, an encryption event, an administrator mistake — and if you can name one, you have one media type wearing two hats.
"One off-site" means outside the blast radius
A backup in the same building is off-server, not off-site. A backup in the same city is fine for hardware failure and useless for a regional incident. Match the distance to the risk you're actually insuring against.
The modern amendment: many teams now run 3-2-1-1-0 — three copies, two media, one off-site, one immutable or offline, and zero errors on restore verification. The immutable copy exists specifically because ransomware operators now hunt for backup systems first, and delete or encrypt them before touching production.
Why backups fail in practice
In our experience the failure is rarely the backup software. It's one of these:
- Nobody ever restored. The job reported success for four years. The first restore attempt reveals the application-consistent snapshot was never actually application-consistent.
- Scope drift. A new server, database, or volume was added in 2024 and never got into the backup selection. Nobody noticed because nothing failed.
- Retention math. Retention was set to 30 days. The corruption started 45 days ago and was only discovered last week. Every retained copy is already poisoned.
- Credential coupling. The backup system authenticates with the same domain admin account as everything else, so an attacker who owns the domain owns the backups too.
- Restore time was never measured. The data is intact and it takes eleven days to bring back. Technically recovered; commercially irrelevant.
Two numbers you must be able to state
- RPO — recovery point objective. How much data can you afford to lose, measured in time? If backups run nightly at 1am and you fail at 4pm, your real RPO is fifteen hours. Is that acceptable to the business? Have you asked them, in those words?
- RTO — recovery time objective. How long can you afford to be down? This is the number that determines architecture. An RTO of four hours and an RTO of four days buy completely different systems.
If you can't state both numbers for each critical system, you don't have a backup strategy — you have backup software.
A restore test that actually tests something
Quarterly, pick one production system at random. Restore it to an isolated network. Then have someone who did not perform the restore verify that the application starts, the data is current to the expected point, and the integrations reconnect. Time the whole thing and write the number down.
Compare that number to your stated RTO. The gap between them is your real exposure, and it's usually the most useful figure your infrastructure team will produce all year.
