When Your Snapshot Is Not a Backup: A Data Recovery Reality Check

2,705 ransomware complaints in 2024, with reported losses of $12,473,156. That's what the FBI's Internet Crime Complaint Center logged last year, but the real number is worse: the FBI itself warns these figures are artificially low because they exclude lost business, downtime, wages, files, equipment, and third-party remediation—and many victims never report at all (FBI IC3 2024 Internet Crime Report). So when you think about data recovery, you can't just hope. You need a plan that works when you're under pressure. And the first step is admitting that your snapshots are not backups.

Snapshots are not backups—repeat after me

If you're relying on VMware snapshots or any point-in-time copy as your recovery strategy, you're playing with fire. Broadcom/VMware states plainly that snapshots are not backups: a snapshot file is only a change log of the original virtual disk, creating a delta disk that stores changes made since the snapshot. If the base disks are deleted, the snapshot files alone are not sufficient to restore a virtual machine (Broadcom KB 318825). Worse, snapshots grow over time. Broadcom recommends not retaining a single snapshot for more than 72 hours, because the file keeps growing and can fill your storage, impacting performance. And while a maximum of 32 snapshots is supported in a chain, for better performance they suggest using only 2 to 3. So if you're keeping snapshots for weeks as your primary recovery method, stop. They're for short-term rollback, not disaster recovery.

Set your RPO and RTO—or guess forever

You can't design recovery without two numbers: Recovery Point Objective (RPO) and Recovery Time Objective (RTO). RPO is 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 online (NIST). NIST SP 800-34 defines RPO as the point in time prior to a disruption to which data must be recovered given the most recent backup, and RTO as the maximum time a system resource can remain unavailable before unacceptable impact. And here's the kicker: your RTO must be shorter than your Maximum Tolerable Downtime (MTD), the total outage your business can stomach. For mission-critical systems, you're often looking at an RTO under 1 hour and an RPO under 5 minutes. Less critical systems can tolerate more. So ask yourself: what's your MTD? If you don't know, you're flying blind.

Imagine you run a hospital's patient records system

Let's make this concrete. Imagine you are the IT director for a mid-sized hospital. Your electronic health records (EHR) system is mission-critical: if it goes down, patient care suffers. You've set an MTD of 4 hours—after that, you're diverting ambulances. So your RTO must be under 4 hours, say 2 hours, to be safe. Your RPO? You can't lose more than 5 minutes of patient data; otherwise, you might miss a critical allergy or medication order. So you need backups that capture changes at least every 5 minutes. NIST SP 800-209 advises that if a standard requires no more than five minutes of data loss, the snapshot interval should be five minutes or less. But snapshots alone won't cut it—you need a full backup strategy. You might use continuous data protection (CDP) that journals changed blocks in real time, plus periodic full backups. And you need to test restores regularly. NIST SP 800-209 recommends testing backups at least monthly for critical data, and for applications with strict restoration speed requirements, performing an end-to-end test restore to a sandbox environment. Have you done that? If not, your plan is just a hope.

The 3-2-1-1-0 rule: your new mantra

You've probably heard of the 3-2-1 rule: 3 copies of data, on 2 different media, with 1 off-site. That's the baseline. But the modern threat landscape demands more: the 3-2-1-1-0 rule adds 1 immutable or air-gapped copy and 0 unverified backups (CISA). Immutability means you can lock data after it's created, preventing alteration or deletion—exactly what you need against ransomware that tries to encrypt your backups (NIST SP 800-209). So for your hospital scenario, you might have: the primary EHR database, a local backup on a different storage array, an off-site copy in the cloud, an immutable copy on tape or object storage with object lock, and zero backups that you haven't verified. That last point is crucial: an untested backup is an assumption. CISA advises maintaining offline, encrypted backups and regularly testing them. If you haven't restored from your backup, you don't have a backup.

Don't forget the air gap

Ransomware has evolved to target backups. NIST SP 800-209 identifies compromising backups as a key risk, noting attackers may interfere with the backup process to gradually poison future copies. They even target network-attached storage and backup appliances. So you need an air gap—a copy that's physically or logically isolated. LTO tape is a classic air gap solution: it's offline by design, and LTO-9 offers up to 45 TB compressed per cartridge, with hardware-based encryption and WORM (Write-Once, Read-Many) functionality (LTO Program). While disk offers faster recovery, it's not offline and not completely secure from ransomware. So use tape for that immutable, air-gapped copy. And remember: if you encrypt backups, protect the keys for as long as you need the data, and don't store keys with the data (NIST SP 800-209).

Test, test, test—or you're just guessing

You wouldn't run a hospital without drills, and you shouldn't run backups without restore tests. NIST SP 800-209 recommends periodic testing, at least monthly for critical data, and keeping an up-to-date recovery catalog that records each copy and the results of anti-malware scans. You should also periodically scan past copies with current anti-malware tools to catch poisoned backups. And don't confuse high availability with backups: NIST SP 800-34 points out that HA systems (99.999% uptime) cannot replace a solid backup strategy because data corruption can propagate through an HA system, making recovery impossible without a separate backup. So if you're relying on replication alone, you're one corruption away from disaster.

Your recovery plan needs a plan

When ransomware hits, you need a checklist. CISA's ransomware response checklist says to reconnect systems and restore data from offline, encrypted backups based on a prioritization of critical services, taking care not to re-infect clean systems. And report the incident to federal law enforcement via IC3 or a local Secret Service field office (CISA). But all that only works if you've prepared. NIST SP 800-34 lays out a seven-step contingency planning process: develop policy, conduct a business impact analysis, identify preventive controls, create contingency strategies, develop the plan, ensure testing and training, and maintain the plan. That's not optional—it's the framework. And remember, your alternate site should be in a geographic area unlikely to be affected by the same disaster, and you should account for transportation time (NIST SP 800-34).

The one thing to remember

If you take nothing else away, take this: an untested backup is not a backup. It's a guess. You must regularly restore from your backups—at least monthly for critical data—and verify that they work. Because when ransomware strikes, you don't want to discover your backups are useless. Test them. Now.

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
• Broadcom KB (VMware snapshot best practices) - https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html
• FBI IC3 2024 Internet Crime Report - https://www.ic3.gov/Media/PDF/AnnualReport/2024_IC3Report.pdf