Why Your Backups Are Not Data Recovery: Test the Restore

Most people think a backup is a recoverable copy of their data. That's wrong. A backup is a file, a snapshot, a tape—an inert thing. Data recovery is the act of turning that inert thing back into a working system. They are not the same, and confusing them is how companies go out of business after a ransomware attack.

Your RPO and RTO Are Not Guesses

Before you back up anything, you must define two numbers: Recovery Point Objective (RPO) and Recovery Time Objective (RTO). NIST defines RPO as the maximum acceptable data loss measured in time—the latest point to which data can be restored. RTO is the maximum acceptable downtime before systems must be back. These are not technical settings; they are business decisions. If you haven't written them down, you haven't made them.

The mistake is to set them after choosing a backup tool. That's backwards. Your backup frequency is dictated by your RPO, not the other way around. NIST SP 800-209 says that if a business or compliance standard requires no more than five minutes of committed data loss, the snapshot interval should be five minutes or less. That's a concrete example, and it's rare to see it followed. Most people take daily snapshots and then claim a 15-minute RPO. They are lying to themselves.

Set RPO and RTO before you buy anything. Write them down. Then design backups to meet them. If your RPO is five minutes, you need continuous data protection, not a nightly job. If your RTO is one hour, you need a hot site, not a cold one. NIST SP 800-34 describes cold sites as just space and power—you might need days to get equipment and restore. That won't hit a one-hour RTO. Know your numbers first.

Snapshots Are Not Backups

Another dangerous assumption: snapshots equal backups. They don't. A snapshot is a point-in-time copy that often uses pointers, not a full physical copy. It's fast and cheap, but it's usually stored on the same system as the original. If the source data is unavailable—say, ransomware encrypted it—the snapshot is often unusable too. NIST SP 800-209 says snapshots are often not usable if the source is gone.

VMware's own documentation is blunt: snapshots are not backups. A snapshot file is only a change log, a delta disk. If the base disks are deleted, the snapshot alone cannot restore a virtual machine. Broadcom/VMware recommends using only 2–3 snapshots in a chain and never retaining one for more than 72 hours. Yet I've seen production VMs with 20 snapshots that have been running for months. That's a performance disaster waiting to happen.

Snapshots have a role, but it's not backup. They're for quick rollback before a patch, not for disaster recovery. If your entire backup strategy is snapshots, you have no backup.

What about cloud? AWS Backup can take continuous backups of S3 buckets, allowing restore to any point in the last 35 days. That's real point-in-time recovery. But it requires S3 Versioning to be enabled, and you must set a lifecycle expiration rule or costs will balloon. The cloud doesn't fix bad design; it just bills you for it.

Test the Restore or Assume the Worst

An untested backup is an assumption. That's not my opinion; it's NIST's. The #StopRansomware Guide from CISA says to regularly test backups. NIST SP 800-209 recommends testing at least monthly for critical data and doing an end-to-end test restore for applications with strict restoration speed requirements. Monthly. Not yearly. Not 'when we have time.'

Why so often? Because ransomware attacks target backups. NIST SP 800-209 notes that attackers interfere with the backup process itself to gradually poison future copies. You won't know your backups are poisoned until you try to restore. And by then, the data is gone.

Here's a concrete scenario: you run a small law firm. Your RPO is one hour, your RTO is four hours. You have nightly backups to a local NAS and a weekly cloud copy. A ransomware attack hits on a Tuesday afternoon. You need to restore from last night's backup—that's about 12 hours of lost work, which violates your RPO. And your cloud copy is from Sunday, so that's worse. You didn't test, so you don't know if the NAS backup is even readable. You're now in a manual recovery that takes two days. That's the real world.

Testing is the only way to know. Set a calendar reminder. Do a test restore to a sandbox environment. Verify you can actually boot. Check that your recovery catalog—which NIST SP 800-209 says you should keep—is accurate. And remember the 3-2-1-1-0 rule: 3 copies, 2 media, 1 off-site, 1 immutable or air-gapped, and 0 unverified backups. The zero is the hard part.

Ransomware Is Coming for Your Backups

The FBI's 2024 IC3 report says ransomware is the most pervasive threat to critical infrastructure. Ransomware complaints rose 9% from 2023, with 2,705 complaints and reported losses of $12.5 million. But that's a fraction of the real cost—the FBI notes reported losses don't include lost business, time, or equipment. The real damage is downtime.

Attackers know backups are your lifeline, so they target them. NIST SP 800-209 identifies compromising backups as a key risk. That's why the 3-2-1-1-0 rule adds an immutable or air-gapped copy. Immutability means data can't be altered or deleted after it's written. That's the property that stops ransomware from encrypting your backups too. Tape is the ultimate air gap—the LTO Program points out that tape is offline and not completely secured from ransomware attacks, which is actually a feature. Disk-based backups are convenient, but they're online and vulnerable.

So what do you do? You follow the 3-2-1-1-0 rule. You keep one copy immutable or air-gapped. You test it monthly. And when the attack comes, you don't panic—you follow a plan. CISA's ransomware response checklist says to report to the FBI IC3 and restore from offline, encrypted backups, prioritizing critical services. But you can't do any of that if you haven't tested.

The most important thing to remember: a backup is not data recovery. Data recovery is the tested act of restoring. Test your restores, or your backups are just expensive paperweights.

Sources

• CISA - https://www.cisa.gov/stopransomware
• 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
• Broadcom KB - https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html
• FBI IC3 2024 - https://www.ic3.gov/Media/PDF/AnnualReport/2024_IC3Report.pdf
• LTO Program - https://www.lto.org/newsbytes-september-2022/