Stop Treating Snapshots Like Backups: Set Real RPO and RTO

You think your snapshots are backups. That's wrong — and it's a dangerous mistake that could cost you everything. Snapshots are point-in-time copies, often just change logs, not independent backups. If your primary storage fails or gets encrypted by ransomware, those snapshots often go with it. It's time to separate backup from snapshot and start setting real recovery goals.

The Myth: Snapshots Equal Backups

Here's the reality: a snapshot is a storage-efficient point-in-time copy that often uses pointers rather than a full physical copy. It's quick and cheap, but it's not a backup. NIST SP 800-209 warns that if the source data is unavailable, snapshots will often not be usable either. Broadcom/VMware is even blunter: VMware snapshots are not backups — a snapshot file is only a change log of the original virtual disk, creating a delta disk. If the base disks are deleted, the snapshot files alone can't restore a VM. So, stop relying on snapshots as your only safety net.

Set Your RPO and RTO Before You Need Them

You can't recover what you don't define. Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time — the latest point to which data can be restored. Recovery Time Objective (RTO) is the maximum acceptable downtime before systems and business functions must be restored. These aren't abstract concepts; they're your recovery targets. 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 copy. RTO is the maximum time a system can be unavailable before unacceptable impact. If you don't set these numbers, you're flying blind.

The 3-2-1-1-0 Rule: Your New Backup Baseline

Forget the old 3-2-1 rule — it's not enough anymore. The modernized 3-2-1-1-0 rule, recommended by CISA, calls for 3 copies of data, on 2 different storage media, 1 copy off-site, plus 1 immutable or air-gapped copy, and 0 unverified backups. The 'immutable' part is critical: NIST SP 800-209 defines immutability as the ability to lock data after creation, preventing alteration or deletion. This protects you from ransomware that tries to encrypt or delete your backups. And the '0 unverified backups' part is non-negotiable: if you haven't tested it, it doesn't count.

Why Testing Your Backups Is Non-Negotiable

An untested backup is an assumption. NIST SP 800-209 recommends testing backups at least monthly for critical data to verify integrity and restorability. CISA advises regularly testing backups, especially against ransomware. And NIST SP 800-53 requires testing backup information at an organization-defined frequency. Yet most organizations never do a real restore test until disaster strikes — and that's when they discover their backups are corrupt, incomplete, or worse. Don't be that person. Schedule a monthly restore test for critical systems, and do an end-to-end test restore to a sandbox environment if you have strict RTO requirements.

Off-Site and Immutable: Your Last Line of Defense

Off-site backups protect against site-level disasters like fire, flood, or theft. NIST SP 800-34 lists criteria for selecting an off-site facility: geographic area, accessibility, security, environment, and cost. But off-site isn't enough if it's writable from your network. That's where immutability comes in. The LTO Program points out that tape provides an inherent air gap — it's offline and not completely secured from ransomware attacks, unlike disk. Tape also offers WORM (Write-Once, Read-Many) functionality. LTO-9 offers up to 45 TB compressed capacity, hardware-based encryption, and a user bit error rate of 10^20, meaning about 12.5 zettabytes of read data between unrecoverable errors. That's a solid air-gapped option for long-term retention.

The Counter-Argument: 'But We Have High Availability'

You might think your high-availability (HA) setup with replication is enough. It's not. NIST SP 800-34 states that HA systems cannot replace a solid backup strategy because a corruption of data on a system may propagate through an HA system, making recovery impossible without a backup separate from the system itself. Replication is not a backup; it's a redundancy mechanism. If someone deletes critical files or ransomware encrypts them, the corruption replicates across all copies. You need a point-in-time backup that can roll back to a clean state.

Bottom Line

Stop treating snapshots as backups. Set concrete RPO and RTO for each data tier, implement the 3-2-1-1-0 rule with an immutable or air-gapped copy, and test your restores monthly. That's your single best move to ensure you can actually recover when disaster strikes.

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
• LTO Program - https://www.lto.org/newsbytes-september-2022/