Only if you have tested it. Having backups is not the same as being able to restore from them during a ransomware attack, and the gap between the two is where organizations lose their data.
Ransomware encrypts your files and demands payment for the key; your recovery plan is only as good as your last successful restore test. The evidence is blunt: attackers now hunt your backups first, and many teams discover their restore process is broken at the worst possible moment. This article explains what the data shows, why untested backups fail, and how to test recovery before an attacker forces the issue.
Table of Contents
- Attackers target your backups first
- Having backups is not the same as restoring from them
- Paying the ransom is not a substitute for a working restore
- How to actually test a restore
- Set a recovery time you can defend
- Frequently Asked Questions
Attackers target your backups first
backups are no longer a quiet safety net. According to Sophos's State of Ransomware 2024 analysis, criminals attempted to compromise backups in 94% of ransomware attacks, and 57% of those attempts succeeded. Veeam's 2025 Ransomware Trends report found 89% of organizations had their backup repositories targeted.
This is a deliberate strategy. If attackers destroy or encrypt your backups, they remove your only alternative to paying. The same Sophos data shows the financial consequence: when backups were compromised, the average ransom demand rose to $2.3 million versus $1 million when backups stayed intact, victims were roughly twice as likely to pay, and overall recovery costs ran about eight times higher. The lesson is not "have backups." It is "protect and verify backups as an attack surface of their own," because that is exactly how attackers treat them.
Having backups is not the same as restoring from them
This is the gap the title asks about, and the numbers are stark. Veeam reported that despite widespread backup targeting, only about 10% of organizations recovered more than 90% of their data. A backup that exists but cannot deliver a clean, complete restore is a false sense of security. Restoring is also becoming less common as a recovery route.
Sophos's State of Ransomware 2025 report found use of backups to restore encrypted data fell to a six-year low of 54% of incidents, while 49% of affected organizations paid the ransom instead. Some of that is coercion, but some is simply teams not trusting or not being able to use what they have. Backup failure is a leading cause of data loss in its own right. Zerto and IDC found in their 2024 research that backup-related issues were the single largest cause of data loss, responsible for 32% of incidents — even though backup and recovery was named the top IT software investment priority.
Paying the ransom is not a substitute for a working restore
Some teams quietly assume that if backups fail, paying will fix it. The data says otherwise. Zerto and IDC's September 2024 research found only 20% of organizations that paid a ransom fully recovered their data. Payment also does not mean the victim lacked options.
In the same study, 48% of those who paid did so despite holding valid backups — a strong signal that they could not restore quickly or confidently enough to avoid paying. That points back to untested recovery, not missing backups. Treat payment as a failure state, not a plan. A decryption key from an attacker is slow, partial, and legally fraught, and the evidence shows it usually does not return all your data.
How to actually test a restore
Testing means proving you can rebuild real systems from backups, not just confirming a backup job reported success. A green checkmark in a backup console says data was copied; it says nothing about whether that data restores into a working system.
CISA's #StopRansomware Guide directs organizations to keep offline, encrypted, immutable backups and to regularly test the availability and integrity of backups in a disaster recovery scenario. Work through a realistic drill rather than a file-level spot check: Follow the 3-2-1 rule that CISA endorses as a baseline: three copies of data, on two different media, with one kept offline or off-site. An immutable copy that attackers cannot alter is what makes the "restore from a clean source" step possible.
- Restore to isolated hardware or a clean network segment, not over production, so a test never overwrites live data.
- Rebuild a full system or application — database, dependencies, and configuration — not a single file, and confirm it runs.
- Assume your primary backup is encrypted by the attacker, and restore from your offline or immutable copy instead.
- Measure how long the restore takes and how much data you recover, then compare both against your targets.
- Verify the restored data is uninfected and that the restore did not carry the attacker's foothold back in.
Set a recovery time you can defend
Speed matters because ransomware downtime compounds. Sophos's 2025 report found recovery is slow even when it works: 53% of victims fully recovered within one week, up from 35% a year earlier, and 97% within three months. A three-month tail is a survival threat for most organizations.
Testing is what turns a hoped-for recovery time into a measured one. Time your drills, and if a full restore takes three days when the business can tolerate one, you have found a problem on your schedule instead of the attacker's. Re-test after any major change to systems, backup software, or infrastructure, because an untested change is an untested restore.
Frequently Asked Questions
How often should we test ransomware restores?
Test after every major infrastructure or backup-software change, and on a regular recurring schedule. CISA advises regularly testing backup availability and integrity in a disaster recovery scenario, not just checking that backup jobs completed.
Isn't a successful backup job enough proof?
No. A completed backup job confirms data was copied, not that it will restore into a working system. Zerto and IDC found backup-related issues caused 32% of data loss incidents, so a green checkmark is not evidence of recoverability.
Why keep an offline or immutable backup if we already have cloud backups?
Because attackers target backups directly — Sophos found compromise attempts in 94% of attacks. An offline or immutable copy is the one an attacker cannot encrypt, which is why CISA makes it part of the 3-2-1 baseline.
You Might Also Like
- My Backup Drive Was Connected During a Ransomware Attack: Can I Trust It?
- What Is New With Ransomware Attacks in August 2026? Latest breach notices and security advisories and Key Takeaways
- Ransomware Update 2026: Disclosure, Response, and Open Questions