Your Backup Is a Lie Until You Test It: A Field Report

You think you're protected because you have backups. You're not. Most people discover this the hard way, in the middle of a ransomware attack, when they try to restore and find their backups are corrupted, incomplete, or simply gone. It's a harsh truth: a backup you've never tested is just a collection of files that might as well be a paperweight.

Imagine This: You're the IT Admin for a 50-Person Firm

You've been diligent. You have a NAS in the server room, a nightly backup job that copies everything to an external drive, and you even have a cloud backup subscription. You've heard about the 3-2-1 rule—three copies, two different media, one off-site—and you think you're following it. (CISA calls this the 3-2-1 rule.) But you've never actually restored from any of these backups. You've never timed the restore. You've never even verified that the files open. Then one Tuesday morning, a user clicks a phishing link, and within hours, every file on the network is encrypted. A ransom note appears. Your heart sinks.

Step One: Don't Panic, But Do Report

Your first move isn't to restore. It's to contain and report. CISA's ransomware response checklist is blunt: report the incident to federal law enforcement via the FBI's IC3 or a local Secret Service field office, and you can also contact CISA for assistance. Yes, reporting might feel like a distraction when you're in crisis mode, but it's a critical step for legal and forensic reasons. Meanwhile, you need to figure out what you're dealing with. Which systems are down? What's most critical? This is where your priorities come into play.

Step Two: Know Your RPO and RTO Before You Need Them

Here's the thing: you should have defined your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) months ago, not during the incident. RPO is the maximum data loss you can tolerate—how far back you're willing to go. RTO is how long you can afford to be down. NIST defines these as the fundamental metrics for recovery. For your firm, you might have decided that losing more than 15 minutes of work is unacceptable (RPO of 15 minutes) and that you need to be back online within 4 hours (RTO of 4 hours). But your backup strategy probably doesn't match those numbers. If your nightly backup only captures data as of midnight, your RPO is actually 24 hours, not 15 minutes. That's a big gap.

NIST SP 800-209 suggests that point-in-time copies like snapshots should be configured to meet your RPO. If you need to lose no more than five minutes of data, your snapshot interval should be five minutes or less. But you don't have that. You have a single nightly backup. So your RPO is effectively 24 hours, and you're about to lose an entire day's work.

Step Three: The Restore That Was Never Tested

Now you're at the restore step. CISA advises restoring from offline, encrypted backups, and to do it based on a prioritization of critical services. You have your external drive, which is offline—good. But as you start the restore, you realize the latest backup is from last night, but it's a full backup. You also have incrementals from the past week. You remember that to restore, you need the last full backup plus every incremental since then. (That's the definition of incremental backups.) You start with the full backup, and it's slow. The external drive is USB 2.0, so it's crawling. You're looking at hours just to copy the data back.

And then you hit a snag: the incremental from yesterday is corrupted. You didn't test it. You didn't verify it. You just assumed it was fine. Now you're stuck. You can only restore to the last good incremental, which is from two days ago. That's a 2-day RPO, not the 15 minutes you thought you had. And your RTO? You're already at 6 hours and not done. You're blowing past your target.

Step Four: The Real Lesson—Immutability and Testing

Here's where the modernized 3-2-1-1-0 rule comes in. It adds one immutable or air-gapped copy and zero unverified backups. (CISA.) Immutability means data that can't be altered or deleted, as NIST SP 800-209 defines it. If you had an immutable copy, ransomware couldn't have encrypted it. And if you had tested your backups—actually done a restore to a sandbox environment—you'd have known that incremental was bad before you needed it. NIST SP 800-209 recommends testing backups at least monthly for critical data and doing end-to-end restores for applications with strict restoration speed requirements. You didn't test. That was your mistake.

Quick Tip

Set a calendar reminder: the first Sunday of every month, test one restore. Not just a file copy—a full restore to a test environment. Time it. Document it. You'll sleep better.

Step Five: What Tier Are You? It Matters

Not all data is equal. NIST suggests organizing your data protection plan by tiers, with different RPO/RTO for each. Your email server might need an RTO under an hour and an RPO under five minutes. Your marketing archive might be fine with a daily backup and a 24-hour RTO. But you treated everything the same. That's inefficient and dangerous. If you had tiered, you'd have spent more resources on the critical stuff and less on the rest.

What I'd Actually Do

Here's my blunt advice: Stop treating backups as a set-and-forget task. Implement the 3-2-1-1-0 rule—not just the old 3-2-1. That means you have three copies, on two media, one off-site, plus one immutable or air-gapped copy, and zero unverified backups. (CISA.) For the immutable copy, consider object storage with versioning or a tape you write once and store in a safe. And for the love of all that is holy, test your backups monthly. Not quarterly, not yearly. Monthly. NIST SP 800-209 says at least monthly for critical data. Take that seriously.

Also, define your RPO and RTO in writing, and make sure your backup schedule matches. If you can't afford to lose more than five minutes, you need snapshots every five minutes, not a nightly backup. And if you can't be down for more than a day, you need a faster restore path than digging out a USB drive.

You don't have to wait for a ransomware attack to learn this. Test now. You'll thank me later.

Sources

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