When was the last time anyone at your company restored a full server, not a single file, from backup and timed how long it took? Most owners we ask know which backup product they pay for. Very few can tell us how many hours it would take to get the accounting system, the file shares, and user logins working again from those copies. That gap is where ransomware recoveries turn from days into weeks.
Backup restore testing is the only way to know whether your backups are a recovery plan or just a storage bill. A green checkmark in the backup console proves that data was copied somewhere. It does not prove that the copy is complete, uncorrupted, reachable after an attack, or restorable to working hardware within a time the business can survive.
No. Having backups means copies of your data exist; being able to recover means you can turn those copies back into running systems, in the right order, within a known time, using credentials and infrastructure that survived the incident. The only way to prove the second is to restore from backup on a schedule and measure the result against the recovery time the business actually needs.
Backup reporting is built around the backup job, so it measures the part of the process that rarely fails. The parts that do fail sit outside the job: the hypervisor you planned to restore onto was encrypted too, the backup console used the same domain credentials the attacker stole, the application needs a license server that nobody backed up, or the restore of a large file server takes three days over the available bandwidth. None of those problems show up until someone tries a real restore.
Our explainer on how backup differs from business continuity and disaster recovery covers the vocabulary. This article asks a narrower question: would the copies you already have work on the worst day?
Here is the belief we push back on most: that the main risk to recovery is losing the data. In most incidents we review, the data survives. What does not survive is the environment needed to use it. A backup is only as useful as the network, identity, hypervisor, licensing, and sequencing knowledge required to bring it back, and those dependencies are almost never documented next to the backup schedule.
This is also why recovery depends so heavily on preparation that happened months earlier. In the Sophos State of Ransomware 2026 report, organizations used backups to recover in 66% of attacks where data was encrypted, up from 54% a year earlier, while 48% paid a ransom to get data back (respondents could choose more than one method). Read the other way, a large share of victims either could not rely on backups alone or decided that restoring would take too long. Our analysis of the real dollar cost of downtime and ransomware for SMBs shows why: every extra day of restoration is payroll, missed billing, and customer trust lost.
The clearest public example of this problem is the British Library's 2023 ransomware attack, claimed by the Rhysida group. In its own published cyber incident review, the Library said it believed secure copies of its digital collections and metadata existed, yet it was "hampered temporarily by the lack of viable infrastructure on which to restore it." It named its reliance on legacy infrastructure as the primary contributor to the length of its recovery, because some older systems were unsupported and could not be repurchased or restored, or would not run on modern servers.
The lesson for a 50-person firm is that "we have the data" and "we can operate again" are separated by infrastructure. The Library's own lessons include practicing continuity plans for a total outage of all systems. A restore test is the cheapest way to find that gap while it is still a project instead of a crisis.
At minimum, test a meaningful restore every quarter and a full recovery of your most critical system at least once a year, plus after any major change such as a server migration, a new line-of-business application, or a change of backup vendor. Quarterly is not an arbitrary number: it is the cadence some insurers already ask about.
Federal guidance points in the same direction. CISA's #StopRansomware Guide tells organizations to maintain offline, encrypted backups of critical data and to "regularly test the availability and integrity of backups in a disaster recovery scenario," and to keep golden images of critical systems so they can be rebuilt quickly. For healthcare organizations and their business associates, the HIPAA Security Rule contingency plan standard requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan, and lists periodic testing and revision of those plans as an implementation specification.
Cyber insurers have turned the same expectation into application questions. AIG's ransomware supplemental questionnaire asks applicants to state a recovery time objective for vital assets and whether, at least quarterly, they test their ability to restore those assets in line with it. QBE's ransomware supplemental application asks how often the recovery time objective is tested and whether the applicant hit its target in the most recent test. If you answer those questions without test results to back them, you are making an attestation you cannot prove, which is exactly the risk we unpack in the attestation trap behind denied cyber insurance claims.
The easiest way to explain the difference to a leadership team is to put the two side by side. The left column is what most businesses have today. The right column is what the business actually needs to know before an incident.
| Question | Backup job report | Restore test |
|---|---|---|
| Was data copied? | Yes | Yes |
| Is the copy complete and uncorrupted? | Sometimes, via checksum | Yes, the application opens and the data is current |
| Can we reach it if the domain is compromised? | No | Yes, if the test uses isolated credentials |
| Where would we restore it? | No | Yes, the target hardware or cloud host is proven |
| How long until people can work? | No | Yes, measured in hours against the RTO |
| What order do systems come back in? | No | Yes, dependencies are documented |
Only one row is answered by the tool most companies rely on. The rest require people doing the work, which is why restore testing needs a schedule and an owner.
A restore test does not have to mean taking the business offline. It means proving recovery at increasing levels of realism and writing down what you learn. We build a program around four levels, each catching a different failure:
The output of each test is a short record: what was restored, from which date, how long it took, what broke, and what was fixed. That record is what turns "we have backups" into evidence you can hand to an insurer, an auditor, or your own board. It also feeds directly into the more detailed disaster recovery testing strategies larger organizations use.
The failures we find are rarely exotic. Backups that were configured years ago still exclude a folder that became critical later. The backup server is joined to the same domain it protects, so a compromised admin account can delete the restore points. Offsite copies exist, but downloading them would take longer than the business can wait. The only person who knows the restore order for the ERP has left the company. Each is fixable once visible, and catastrophic if first discovered during an attack.
Copy count matters too. If every copy lives in one place or under one set of credentials, a single compromise can reach all of them, which is why a 3-2-1 backup strategy with at least one offline or immutable copy is the foundation that restore testing sits on. And if your email, Teams, and SharePoint data is part of what you need back, confirm it is actually covered; our guide on why Microsoft 365 is not a complete backup strategy explains the gap.
An untested backup creates three exposures at once. Operationally, you do not know your real recovery time, so you cannot tell clients, lenders, or staff how long an outage will last. Financially, every unknown in the restore process adds days of downtime and increases the pressure to consider a ransom payment you never planned to make. From a risk and compliance standpoint, you may be attesting to insurers or auditors that recovery is tested when it is not.
The fix is not more backup software. It is a recovery time objective leadership has agreed to for each critical system, a test schedule that proves you can meet it, and documented results reviewed whenever something changes.
When we take on backup and recovery for a client, the first engagement is not a product swap. We inventory what is protected, map each critical system to a recovery time the owner signs off on, and then perform the first restore tests ourselves so the baseline is measured rather than assumed. Backup infrastructure is separated from the production domain, at least one copy is offline or immutable, and break-glass access is stored where an attacker inside your network cannot reach it.
From there, restore tests run on a calendar, results are logged with timings and fixes, and the evidence is packaged in a form you can hand directly to an underwriter or auditor. When a test misses its target, we treat it as a finding to close, not a footnote.
If you cannot say how long it would take to restore your most important system, that number is the first thing to find out. A single scheduled restore test will tell you more about your real resilience than any backup report.
To see how we design, test, and document recovery for businesses like yours, review Securafy's business continuity and disaster recovery services.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk through your current backups, your recovery targets, and the fastest way to prove you can meet them.