Local Backups Aren't Dead—But Yours Are Probably Broken

Why do I still need a local backup when everything is in the cloud?

It's a fair question. You've moved your files to the cloud, your email is hosted, and maybe your entire office runs on SaaS. But cloud isn't magic. If you delete a file by accident, or a disgruntled admin wipes a shared drive, or ransomware encrypts your synchronized folder, your cloud copy—if it's just synced—will happily replicate the damage. That's why CISA's guidance still pushes the 3-2-1 rule: three copies of your data, on two different types of media, with one copy off-site. And that rule applies even when one of those copies lives in someone else's data center. You still need a copy that is not the primary working copy, and you still need a copy that is physically or logically separate from your day-to-day systems.

Here's the thing: local backup isn't just about having a second hard drive. It's about having a copy you control, that you can restore from quickly, and that isn't subject to the same failure modes as your primary storage. As NIST SP 800-209 points out, attackers don't just go after your main data—they go after your backups too. If your only backup is in the same cloud account, or on a drive that's always connected and always writable, you're not really backed up.

So yes, keep using the cloud. But also keep a local copy—and make sure that local copy is actually a backup, not just a mirror.

Aren't snapshots and backups the same thing?

No, and this is one of the most dangerous misconceptions out there. A snapshot is a point-in-time copy that often uses pointers, so it's quick and cheap. But it's not a backup, because it usually lives on the same storage system as the original data. NIST SP 800-209 defines a snapshot as a storage-efficient form of point-in-time copy that stores only the changed blocks. If the source data is unavailable—say, the storage array catches fire—the snapshots often aren't usable either.

Even worse, some people think a VMware snapshot is a backup. Broadcom's own guidance is blunt: VMware snapshots are not backups. A snapshot file is just 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. And those snapshots aren't meant to stick around: Broadcom recommends not keeping a single snapshot for more than 72 hours, and using only 2–3 snapshots in a chain, not the maximum of 32. We've seen admins treat snapshots as a backup plan, only to discover that a snapshot chain longer than a weekend slows performance and fills the datastore.

So, treat snapshots as a convenience for quick rollbacks, not as your backup. Your backup is a separate, restorable copy that can survive the loss of the original system.

How do I set a recovery point objective (RPO) that's realistic?

Your RPO is the maximum amount of data you can afford to lose, measured in time. NIST SP 800-34 defines it as the point in time to which data must be recovered after an outage. If you can't lose more than five minutes of transactions, your backup schedule needs to capture data at least every five minutes. That's not a nice-to-have; that's the requirement. NIST SP 800-209 explicitly says that if you're using snapshots as part of your backup scheme, the snapshot interval must match your RPO. If your RPO is five minutes, but you only take hourly snapshots, you're not meeting your objective.

A practical approach: think about what it would cost you to re-enter a day's worth of work. For most small businesses, that's more than you think. In 2024, the FBI's IC3 received 2,705 ransomware complaints with losses of over $12.4 million—and that's just the reported amount, which the FBI notes is artificially low because it doesn't count lost business, time, or equipment. Data loss is expensive, and your RPO should reflect that.

Here's a quick tip: Start with your RPO, then work backward. If you can't tolerate losing more than an hour of work, your backups need to run at least hourly. If you can't tolerate losing more than a day, nightly might be fine—but only if you're sure you can redo that day.

What about recovery time objective (RTO)? Isn't that just a nice number?

RTO is the maximum time you can be down before it hurts. It's not optional. NIST SP 800-34 says your RTO must normally be shorter than your Maximum Tolerable Downtime (MTD)—the total time you can accept for an outage. If your MTD is four hours, your RTO can't be eight. And NIST SP 800-53's CP-10 control requires you to recover and reconstitute systems to a known state within a time you've defined, consistent with your RTO and RPO.

Here's where local backup shines. If your RTO is under an hour, restoring from a local disk or tape is often faster than pulling from the cloud over a slow internet link. Cloud is great for off-site protection, but it's not always fast to restore. That's why you need a tiered approach: keep a local copy for speed, and an off-site copy for survival.

Let's make it concrete. Suppose you run a small law firm. You decide your RPO is 15 minutes and your RTO is 4 hours. That means you need to back up your case files every 15 minutes, and you need to be able to restore them within half a day. A local NAS with frequent snapshots might handle the RPO, but if the office burns down, you need that off-site copy to meet the RTO. So you replicate to a cloud bucket or ship a tape off-site weekly. The point is, you design your backups to meet those numbers, not just to 'have a backup.'

Is the 3-2-1 rule still enough, or do I need the new 3-2-1-1-0?

The classic 3-2-1 rule—three copies, two media types, one off-site—has been the gold standard for years. But ransomware changed the game. CISA now promotes a modernized 3-2-1-1-0 rule: add one immutable or air-gapped copy, and ensure zero unverified backups. That extra '1' is your defense against an attacker who tries to delete or encrypt your backups along with your production data. NIST SP 800-209 defines immutability as the ability to lock data after it's created, so it can't be altered or deleted. That's a powerful shield against ransomware that waits weeks before triggering, hoping to compromise your backups first.

For local backup, immutability can be achieved with WORM media, like LTO tape with WORM functionality, or with a disk that supports object lock or similar. The LTO Program notes that LTO tape provides an inherent air gap—it's offline when not in use, so it's not reachable from the network. That's the gold standard for immutable, offline backup.

But immutability alone isn't enough. The '0' in 3-2-1-1-0 means zero unverified backups. An untested backup is an assumption, as NIST likes to say. You have to actually restore from your backups, on a regular basis, to know they work.

How often should I test my backups, and what should I test?

More often than you think. NIST SP 800-209 recommends testing backups at least monthly for critical data, and doing a full end-to-end test restore to a sandbox environment for applications with strict restoration speed requirements. That's not just checking that the backup job ran—it's actually restoring a file, a database, or a whole VM, and verifying it's usable.

In addition, NIST SP 800-53's CP-9(1) control requires you to test backups at a frequency you define, to verify media reliability and information integrity. So you can set your own schedule, but it has to be documented and followed. We can't stress this enough: a backup that hasn't been restored is not a backup. It's a hope.

One warning: if you're using a cloud backup service, remember that the first backup is often full, but subsequent ones are incremental. That means if you need to restore, you might have to piece together many incremental changes. Test that process, not just the final full restore. And if you're using tape, test by doing a trial restore from a random tape, not just the most recent one.

What's the single most important thing to remember about local backup?

Local backup is not dead, but it has to evolve. You need a copy that is fast to restore, a copy that is off-site, and a copy that is immutable or air-gapped. You need to know your RPO and RTO, and you need to test your backups until you're sick of it. Because when ransomware hits—and it will, eventually—your backup is your only lifeline. The FBI's 2024 IC3 report calls ransomware the most pervasive threat to critical infrastructure, with complaints rising 9% from 2023. Don't be a statistic. Make sure your backups are real, tested, and ready.

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
• 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/