The Misconception That Snapshot Equals Backup
We've all heard it: "We take snapshots every hour, so we're covered." That's a dangerous lie. Snapshots are not backups in the traditional sense. They're point-in-time copies that rely on the same underlying storage. NIST SP 800-209 warns that if the source data is unavailable, snapshots often won't be usable either. So if your primary storage dies, your snapshots may die with it. That's not a backup; that's a false sense of security.
But snapshots aren't useless. They're a critical part of a modern data protection strategy. The problem is that most teams set snapshot intervals based on convenience, not on a real Recovery Point Objective (RPO). And that's where the lie creeps in.
What Is RPO, Really?
RPO is the maximum acceptable data loss measured in time. NIST defines it as the point in time, prior to a disruption, to which data must be recovered. In plain English: if your RPO is 15 minutes, you can afford to lose at most 15 minutes of changes. If your last good backup is 20 minutes old, you've violated your RPO.
Here's the kicker: RPO is not part of Maximum Tolerable Downtime (MTD). NIST SP 800-34 makes that clear. MTD is about how long you can be down; RPO is about how much data you can lose. They're separate, and you need to set both. But for this article, we're zeroing in on RPO because it's the one most often ignored.
How Snapshots Fit Into Your RPO
Snapshots are storage-efficient point-in-time copies. They use pointers and only store changed blocks, so they're fast and take up little space initially. That's why they're tempting as a backup solution. But NIST SP 800-209 advises that when you use snapshots as part of a backup scheme, they must be configured to meet the RPO of the target datasets. If your RPO is five minutes, your snapshot interval must be five minutes or less.
Too often, we see teams with an RPO of 15 minutes but hourly snapshots. That's a direct contradiction. The math is simple: if you take snapshots every hour, the most data you can lose is an hour's worth, not 15 minutes. So your RPO is actually an hour, no matter what you wrote in your plan.
The Real-World Cost: A Concrete Example
Let's put this in a scenario. Suppose you run an e-commerce platform that processes orders. Your compliance team says you must not lose more than five minutes of committed transactions. That's your RPO. NIST SP 800-209 says your snapshot interval should be five minutes or less. So you set up snapshots every five minutes. Good.
But here's the trap: snapshots are stored on the same array as your production data. One night, a ransomware attack encrypts your primary storage. NIST SP 800-209 notes that ransomware has evolved to target storage components, including NAS and backup appliances. If your snapshots are on the same system, they're likely encrypted too. You lost your five-minute RPO because you had no other copy.
That's why the 3-2-1 rule exists. CISA recommends 3 copies, 2 different media, 1 off-site. And the modernized 3-2-1-1-0 adds 1 immutable or air-gapped copy and 0 unverified backups. Snapshots can be your fast recovery point, but they can't be your only recovery point.
Setting Snapshot Intervals That Actually Work
So, how do you set snapshot intervals correctly? First, determine your RPO for each data tier. NIST SP 800-209 recommends organizing your data protection plan by type of data (e.g., Tier 1, Tier 2) and specifying tiering, frequency, and number of copies for each tier. For mission-critical systems, NIST suggests an RPO under 5 minutes. That means snapshots every 5 minutes or less.
For less critical systems, you might have an RPO of an hour, so hourly snapshots are fine. But you also need to consider retention. NIST SP 800-209 gives examples like 48 hourly snapshots or 30 daily backups. That's a lot of snapshots, and they'll eat storage. But that's the cost of meeting your RPO.
Here's a practical approach:
- Classify your data into tiers based on criticality.
- Assign an RPO to each tier (e.g., Tier 1: 5 minutes, Tier 2: 1 hour).
- Set snapshot intervals to match or be shorter than that RPO.
- Store snapshots on a separate system or at least a different logical unit.
Quick tip: Don't rely on snapshots alone for ransomware recovery. They're point-in-time, but if an attacker gains access to the same storage, they can delete them. NIST SP 800-209 warns that attackers may interfere with the backup process itself to gradually poison future copies. So you need an immutable or air-gapped copy.
Testing: The Only Way to Know Your RPO Is Real
You can set snapshot intervals all day, but if you never test a restore, you're just guessing. NIST SP 800-209 recommends testing backups at least monthly for critical data. And for applications with strict restoration speed requirements, do an end-to-end test restore to a sandbox environment. That's not just a nice-to-have; it's a requirement.
CISA also advises to regularly test backups. Untested backups are an assumption, and high availability is not a substitute. So, once a month, pick a critical system, spin up a sandbox, and restore from your snapshots. Time it. If it takes longer than your RTO, you've got a problem. If the data is older than your RPO, you've got a problem.
And don't forget to scan your backups for malware. NIST SP 800-209 suggests keeping a recovery catalog and periodically scanning at least a subset of past copies with current anti-malware tools. A poisoned backup is worse than no backup.
Bottom Line
Set your snapshot intervals to match your RPO, not your storage budget. If your RPO is five minutes, take snapshots every five minutes. But don't stop there. Store those snapshots off-site or make them immutable, and test them monthly. The single best move you can make today is to audit your current snapshot intervals against your stated RPO and fix the mismatch. Your backup is only as good as your last verified restore.
Sources
- CISA (data backup guidance) - https://www.cisa.gov/stopransomware
- NIST (contingency planning) - https://csrc.nist.gov/glossary
- NIST SP 800-209 (Storage Infrastructure Security) - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
- NIST SP 800-34 Rev. 1 (Contingency Planning Guide) - https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
- CISA ransomware response checklist - https://www.cisa.gov/stopransomware/ive-been-hit-ransomware
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!