Your Backup Strategy Is Broken: Recovery Is the Only Metric That Matters

We've been lied to by the backup industry. They sell us features—deduplication, compression, fancy dashboards—but the only thing that matters is whether we can get our data back when the building is on fire or the ransomware hits. And let's be honest: most of us don't know. We've tested restores once, maybe twice, and then we go back to trusting the green checkmarks. That's not a backup strategy; that's a hope.

The 3-2-1 Rule Is a Starting Point, Not a Finish Line

Everyone knows the 3-2-1 rule: three copies of data, on two different media, one off-site (CISA). It's solid advice, but it's been diluted into a checkbox. The real problem isn't having three copies—it's that those copies are often just different versions of the same weak point. If you have three copies on the same NAS, you have zero copies when the NAS dies. And if you're not testing restores, you don't know if those copies are even usable. The modernized 3-2-1-1-0 rule adds an immutable or air-gapped copy and zero unverified backups (CISA). That's the shift we need to embrace: it's not about how many copies you have, it's about how many you can actually restore.

RPO and RTO Are Not Executive Buzzwords—They're Your Life Preserver

When a system goes down, you need to know two numbers: how much data you can afford to lose (RPO) and how fast you need to be back (RTO). NIST defines RPO as the point in time to which data must be recovered, and RTO as the maximum acceptable downtime (NIST SP 800-34). These aren't abstract concepts; they drive concrete decisions. For mission-critical systems, you might set an RPO of five minutes and an RTO of under an hour (NIST). That means you need continuous data protection or snapshots every five minutes, not a nightly backup. And here's the kicker: your RTO must be shorter than your Maximum Tolerable Downtime (MTD), or you're setting yourself up for failure (NIST SP 800-34). If you can't articulate these numbers for your systems, you're not ready for an incident.

Snapshots Are Not Backups—Stop Pretending They Are

Snapshots are great for quick rollbacks, but they're not a substitute for real backups. NIST SP 800-209 is blunt: snapshots are storage-efficient point-in-time copies that often store only changed blocks, and if the source data is unavailable, the snapshots are often useless too. That's a critical distinction. If your primary storage dies, your snapshots die with it. They're not off-site, they're not immutable, and they won't help you when ransomware encrypts the whole array. Use snapshots for what they're good at—fast recovery of a single file or a quick test—but don't put your entire recovery plan on them. The same document advises that snapshots be configured to meet your RPO, but that's a technical detail, not a strategy.

Testing Isn't a Chore—It's the Only Way to Know You're Safe

The strongest counter-argument I hear is: "We don't have time to test restores regularly." I get it. We're all stretched thin. But consider this: NIST SP 800-209 recommends testing backups at least monthly for critical data, and performing end-to-end test restores for applications with strict RTOs. That's not a suggestion; it's a requirement if you want to avoid a disaster. And let's be honest—an untested backup is just a collection of bits. CISA's ransomware response checklist explicitly tells you to restore from offline, encrypted backups, and to prioritize critical services. If you haven't tested that process, you'll be fumbling in the middle of an incident. The time you spend testing is nothing compared to the time you'll lose explaining to your boss why you can't restore the database.

What I'd Actually Do

Here's my concrete recommendation: stop buying more backup features and start designing for recovery. First, define your RPO and RTO for each tier of data—mission-critical gets sub-hour recovery, less critical gets a daily backup (NIST). Second, implement a 3-2-1-1-0 strategy: three copies, two media, one off-site, one immutable or air-gapped, and zero unverified backups (CISA). For the immutable copy, use object lock or a tape that you physically take off-site—don't rely on a cloud vendor's promise. Third, test your restores monthly, at minimum. Automate a test restore to a sandbox environment for your top five applications. And when you test, don't just check that files exist—validate that the applications work. Finally, keep an up-to-date recovery catalog and scan at least a subset of past backups with current anti-malware tools to catch poisoned copies (NIST SP 800-209). If you do all that, you'll be ahead of 90% of organizations. If you don't, you're gambling with your data.

Sources

• CISA - https://www.cisa.gov/stopransomware
• NIST - https://csrc.nist.gov/glossary
• NIST SP 800-34 Rev. 1 - https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
• NIST SP 800-209 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
• CISA ransomware response checklist - https://www.cisa.gov/stopransomware/ive-been-hit-ransomware