Shaun Stockman, Senior Director of Business Development, Americas at Ontrack.
Shaun works with insurance carriers and incident response teams on ransomware recoveries after the backups have already been wiped out, which happens more often than most IT teams expect.
When ransomware takes out your backups along with production data, recovery shifts to the storage layer itself. That means snapshots, deduplication data, and fragments left behind after a delete command runs. I've sat in on calls with adjusters and DFIR teams where the first reaction was "the backups are gone, we're done." I get why people think that. But gone from the console isn't the same as gone from the disk.
Key takeaways
- Attackers target backup repositories in 96% of ransomware attacks and succeed in 76% of those attempts, according to Veeam's Ransomware Trends Report.
- Deleting a backup doesn't erase the underlying data right away. On most storage arrays, the blocks stay put until something writes over them.
- Speed matters more than almost anything else. Stopping write activity to the affected storage is the single best thing you can do before a recovery specialist gets involved.
- Paying the ransom doesn't guarantee your backups come back intact. Only a small share of organizations that pay recover everything.
Why do attackers go after the backups first?
Because a company with working backups doesn't need to pay. Attackers now spend an average of over 70 days inside a victim's environment before they trigger encryption, and a lot of that time goes toward finding and disabling recovery options first. Backup platforms like Veeam are an attractive target because they sit on credentials for the rest of the environment and hold an unencrypted, time-ordered copy of everything the company runs.
I've seen this play out as credential harvesting from the backup console, followed by deletion of snapshots and shadow copies, and only then the encryption payload drops. By the time the IT team notices anything, the backups are already gone. Some groups, like Akira and Fog, have reportedly reorganized their whole approach around this. Instead of hitting production servers first, they go straight for the backup infrastructure, since that's where the leverage really is. This is part of why we wrote about dealing with a ransomware attack as a sequence of decisions, not a single moment. What you do in the first hour after discovery still matters, even if the backups didn't survive.
What can still be recovered after backups are deleted?
More than people expect, honestly. Deletion is usually a pointer operation. The file system marks the space as available, but the actual data blocks stick around until something new gets written there. That's the window a recovery engineer works in.
The techniques vary by what's left:
- File carving, which reconstructs files from raw data patterns without relying on the (deleted) file system metadata
- Recovery from residual snapshots or shadow copies that the attacker didn't find or fully wipe
- Deduplication store analysis, since dedup backups often keep unique data blocks that are referenced by more than one backup job
- Physical-level recovery when the storage hardware itself is damaged or partially wiped
I'll be honest, there's one exception that matters. On SSDs, the TRIM command tends to erase deleted blocks quickly, so the recovery window is narrower than it is on spinning disk or most SAN and NAS arrays. That's another reason the first move after discovering an attack is to stop writing to the affected storage, not to start troubleshooting on it. We go deeper into the actual mechanics in recovering data from ransomware attacks, including what a recovery engagement typically looks like.
Should you pay the ransom to get your backups back?
I'd say think hard before you do, and don't assume it solves the backup problem even if you pay. Recent industry data shows 97% of organizations recover at least some encrypted data after an incident, but among those who pay the ransom, only about 4% get everything back. Decryption tools from attackers are often unreliable, and they do nothing for backup repositories the attacker already deleted rather than encrypted.
This is a decision insurers and legal counsel need to be involved in early, not after the fact. We wrote a longer piece on whether to pay the ransom that walks through the tradeoffs in more detail. My own view, for what it's worth: payment is sometimes the right call for business continuity reasons, but it shouldn't be the plan for getting your backups back.
How do you build a backup strategy that survives the next attempt?
Add immutability and testing to whatever you're already doing. The old 3-2-1 rule (three copies, two media types, one offsite) was built for hardware failure and natural disasters. It wasn't built for an attacker who's inside your network for two months studying your backup schedule.
The updated version, sometimes called 3-2-1-1-0, adds one immutable or air-gapped copy that can't be altered or deleted even with admin credentials, plus zero recovery errors, meaning you've actually tested a restore and confirmed it works. I think that last part gets skipped more than people admit.
I'd also push back a little on treating immutability as a single setting you flip once. Object lock policies, retention periods, and admin permissions all need to line up, and I've seen "immutable" repositories that turned out to have an exception baked in for a service account nobody remembered existed. Worth checking that specifically, not just trusting the label on the storage tier.
What to do right now
If you're mid-incident: stop write activity to affected storage before you do anything else, including before you start troubleshooting the backup console. Bring in a data recovery specialist alongside your DFIR team, not after them, since the recovery window on deleted data narrows fast, especially on flash storage.
If you're not mid-incident: go find out whether your "immutable" backup copy is actually immutable, or just marked as important in a policy setting an admin credential can override. Then schedule a real restore test this quarter. Not a checksum verification. An actual restore.
Frequently asked questions
Can data still be recovered if ransomware deletes the backups?
Deletion usually removes the file system pointer to the data, not the data itself, so the underlying blocks can sometimes be recovered depending on the storage type and how much has been written since.
How long does recovery take when backups are gone?
It varies a lot, from days to a few weeks, depending on data volume, storage type, and how much overwrite has already happened. SSD-based environments tend to move faster because of TRIM, which shrinks the recovery window.
Does paying the ransom bring back deleted backups?
A decryption key addresses encrypted production data, not backup repositories the attacker deleted outright. Only about 4% of organizations that pay recover all their data, so payment isn't a reliable backup recovery strategy on its own.
What's the real difference between a backup restore and a data recovery engagement?
A restore pulls from a backup copy that still exists and works. A recovery engagement reconstructs data from what's physically left on storage after the backup itself is gone, using forensic techniques instead of a restore button.
Current situation and impact
Backup destruction is becoming standard practice and I don't think that trend reverses anytime soon. The organizations that come through it best are the ones who treat backup immutability and recovery testing as ongoing work, not a checkbox from a compliance audit two years ago. Ontrack works alongside insurers and DFIR teams on exactly this kind of recovery, and I'd rather talk to you about it before an incident than during one.
United States | English
Locations
Search
Back to listing
