Ask most organizations if they back up their data and the answer is an immediate yes. Ask when they last restored from those backups (under pressure, at scale, with someone timing it), and the room goes quiet.

That gap is where ransomware does its damage. Backups are a checkbox. Recovery is a capability. They are not the same thing, and attackers have spent the last few years making sure you learn the difference at the worst possible moment.

The backups are the target now

Modern ransomware crews don't just encrypt your production systems and hope. They hunt your backups first, because a victim who can restore is a victim who won't pay. The data is blunt: in about 93% of ransomware events, attackers try to hit the backup repositories, and they succeed often enough to change the outcome. Sophos found that when attackers manage to compromise backups, victims are roughly twice as likely to pay the ransom, and their median recovery costs run about eight times higher.

In other words, an untested, reachable backup isn't a safety net. To an attacker, it's just one more thing to encrypt on the way through.

Even when you recover, you don't fully recover

Here's the part that surprises people. Industry data shows that after an attack, organizations recover (on average) only a little over half of the affected data. The rest is simply gone. And a majority are at real risk of reinfecting themselves during the restore, dragging the malware back in with the data. “We have backups” quietly becomes “we got about 57% of it back, and we're not sure the rest is clean.”

What actually makes recovery reliable

The fix isn't more backup. It's recoverable backup. Three principles separate the two:

  • Immutability. At least one copy must be written so that nothing (not an admin, not stolen credentials, not ransomware) can alter or delete it for a set period. This is the heart of the modern “3-2-1-1-0” rule: three copies, two media types, one offsite, one immutable or air-gapped, and zero recovery errors.
  • Verification. A backup you haven't test-restored is a hope, not a plan. The “zero” in 3-2-1-1-0 means every backup is checked and proven restorable.
  • Speed. Recovery time is a business metric. If restoring everything takes a week, a week of downtime is your real exposure, no matter how good the copy is.

This is why purpose-built immutable targets, like Object First's Ootbi appliance for Veeam, have taken off: they make immutability and fast local restore the default instead of a project.

How iConvergence helps

We don't start by selling you more storage. We start with the uncomfortable questions: which systems must come back first, how fast, and have we ever proven we can do it? From there we design backups around recovery objectives (immutable copies, tested restores, and documented recovery-time targets) and then we actually rehearse them, so the first real restore isn't the first restore.

The bottom line

Nobody gets attacked and wishes they'd had more backup jobs. They wish they could recover: fast, completely, and cleanly. Build for that, test it, and make at least one copy impossible to touch. That's the difference between an incident and a catastrophe.

Sources