Your backups are fine and one account suspension deletes all of them

Everybody knows the 3-2-1 rule. Three copies of the data, on two different media, one of them offsite.

Here’s how it gets implemented now: primary database in a cloud region, automated snapshots in the same account, cross-region replica in the same account, plus object storage backups in the same account, with a lifecycle policy into cold storage in the same account.

Five copies. Feels like overachievement. It is one identity, and if that identity is disabled, every one of those copies becomes unreachable simultaneously.

The failure mode nobody models

Disaster recovery planning models hardware failure, region outage, ransomware, and human error. It does not model account termination, and account termination is now the correlated failure that takes out everything at once.

Payment card expires and the retry logic gives up. Automated fraud detection flags unusual API activity. A billing dispute escalates. Somebody reports your account for a terms violation, correctly or otherwise. A compromised admin credential is used to close the account. In several of those cases the response is automated, immediate, and the appeal process is a web form with a multi-day response time.

That is not a rare event. Search for it and you’ll find a steady stream of businesses describing exactly this, usually in the past tense, usually with a note about which data didn’t come back.

The provider is not being malicious. Their systems are working as designed. The design just doesn’t have your recovery time objective in it.

Read the rule properly

“Two different media” was written when a copy meant a physical object — a tape, a disk, a thing somebody could carry. Two media meant two independent failure domains, and the physicality made independence obvious.

The modern translation dropped the independence and kept the number. Object storage and block storage in the same cloud are not two media. They’re two products behind one identity, one billing relationship, and one terms-of-service enforcement system.

The correct modern reading is two providers, or one provider and something you physically possess. The question isn’t “is the data in two places” — it’s “name every single event that takes out all copies.” If any answer is a single company’s decision, you have one copy with extra steps.

What I underrated

I’ve been the guy saying “just keep tapes.” And for a large archive, tape is still absurdly good — offline by construction, immune to every online attack, and the economics at scale are not close.

What I underrated is the restore path. A tape you’ve never restored from is a guess. The drive needs to exist and work, the software needs to still read the format, and someone needs to know the procedure. I’ve seen a tape restore fail because the only drive that could read the cartridges had been decommissioned two years earlier, and nobody checked because the backup job was green the whole time.

The green backup job is the trap in every one of these stories. It tells you writes are succeeding. It tells you nothing about whether reads produce the data.

The version that actually works

A second provider, funded separately. Different vendor, different payment method, different email domain for the account. If your primary is a hyperscaler, the second can be a cheap object-storage provider — you’re paying for independence, not features. The cost is a rounding error against the loss.

Immutability, enabled. Object lock, retention policies, whatever your provider calls write-once storage. This is the ransomware control, and it’s the one that matters, because modern ransomware operators specifically hunt and delete backups before triggering encryption. A backup your production credentials can delete is not a backup from an attacker’s point of view — it’s an inventory.

Credentials that are not your normal credentials. The backup account’s keys should not be reachable from a compromised production environment, and the production environment should have write-only access at most. If the same identity can read production and delete backups, you have designed a single point of failure and given it API access.

A restore test, on a calendar, with a name attached. Quarterly, to a clean environment, with someone timing it. Not “can we list the files.” Can we bring the service up from nothing, and how long did it actually take? The number you get will be two to five times your documented RTO, every time, and that discovery is the entire value of the exercise.

Keys and credentials stored outside the thing they unlock. The number of encrypted backup sets whose keys live in the password manager that was in the account that got suspended is not small.

The one-question audit

Skip the whole framework. Ask one thing at your next planning meeting:

“Name a single event that makes all our copies unavailable at the same time.”

If anyone can answer in under ten seconds — and they usually can, and it’s usually “the cloud account” — you don’t have three copies. You have three files.