Ask a business owner if they’re backed up and you’ll almost always hear “yes.” Ask when they last restored from those backups, and the room goes quiet. That gap — between having backups and having recoverable backups — is where companies fail after ransomware or disaster.
Lie #1: “The backup ran, so we’re covered.”
A green checkmark means the job completed, not that the data is recoverable. Backups fail silently all the time: corrupted files, incomplete application-consistent snapshots, databases captured mid-write. The only evidence that matters is a restore that actually brings data back and opens cleanly.
Lie #2: “One copy is enough.”
One copy is a single point of failure. The industry standard is 3-2-1: three copies of your data, on two different media types, with one copy offsite. NIST’s contingency-planning guidance (SP 800-34) is built on the same principle of redundancy and geographic separation. If your only backup shares a building, a power supply, or a network with production, one event can take both.
Lie #3: “Our backups are on the network, so they’re safe.”
Backups on the same network as production, using the same credentials, are exactly what ransomware looks for first. Attackers deliberately locate and encrypt or delete backups before triggering the main payload — because a victim with good backups doesn’t pay.
Lie #4: “We sync to the cloud, so we’re backed up.”
File-sync tools like OneDrive, Dropbox, and Google Drive are not backups. They mirror your files — which means they faithfully replicate deletions and ransomware encryption to the cloud copy within seconds. Version history buys you a little room, but it isn’t designed as a recovery system and it won’t survive a determined attacker or a bulk encryption event.
Lie #5: “If something happens, we’ll just restore.”
Restoring is slower than people imagine. Bandwidth, hardware availability, restore order, and application dependencies all add hours or days. Without a documented recovery runbook and defined recovery-time objectives, “we’ll just restore” becomes a week of downtime while the business bleeds revenue.
Define your RTO (how fast you must be back) and RPO (how much data you can afford to lose) per system — then test whether your current backups can actually meet them. Most can’t, and it’s far better to learn that during a drill.
How do you tell if you’re believing one of these lies?
Answer one question honestly: When did you last successfully restore production data from a backup as a formal test? If the answer is “I’m not sure” or “more than a year ago,” you don’t have a verified backup — you have an assumption. Fix that before ransomware or a failed drive forces the test for you.
Not sure where you stand?
Score your ransomware readiness across 20 categories in 15 minutes. Free, no obligation.