Every managed service provider says the same thing when a client’s server is encrypted: “We have backups. We can restore.” The gap between having a backup and being able to restore is where most disaster recovery plans quietly fail. IBM’s Cost of a Data Breach report puts the average breach at $4.88 million in 2024, and the organizations that cut that cost most were the ones that had actually tested restoration, not just assumed it worked. The restore you never tested is a hope, not a control.
The gap between backup and restore is where most disaster recovery plans quietly die. Buying the backup product is a purchase. Confirming the restore actually works is a discipline. Very few businesses do the second thing, and almost none do it on the schedule the risk demands.
The 2024 data on this is stark. Veeam’s Data Protection Trends Report surveyed 1,200 IT leaders globally and found that cyber-attacks are now the number one cause of business outages, with fewer than a third of companies confident they could recover quickly from even a small incident.1 Sophos reports in its 2025 State of Ransomware research that ransomware operators now target backup repositories in 96 percent of attacks, and 76 percent of those attempts succeed at compromising the backup. Organizations whose backups get compromised recover within a week only 26 percent of the time. Those with intact, tested backups do it 46 percent of the time. Recovery costs run roughly eight times higher when the backups are gone.2
Backup restore testing is not a checkbox. It is a documented, recurring practice, or it is a promise that fails at exactly the moment it needs to work.
What “Backup” Actually Means Now
The word backup still means what it used to. What the word requires to actually protect a business has changed.
Backup restore testing is not a service line item. It is the only thing that catches the failure modes below. Ransomware crews now spend the reconnaissance phase inside a network specifically looking for backup infrastructure. They have learned that a client with functioning backups is a client that will not pay the ransom. So the backup targets get hit first, the appliance, the credentials that reach it, the retention policy, the cloud replication path. By the time production data gets encrypted, the recovery option is already gone.
The controls that stop this pattern are not exotic. Immutable storage, Veeam Hardened Repository, Wasabi Object Lock, AWS S3 Object Lock, Datto immutable snapshots, prevents an attacker with valid admin credentials from deleting or modifying the backup. Air-gapped or logically isolated backup networks prevent the attacker from reaching backup infrastructure with production credentials. Multi-factor authentication on the backup management console prevents credential theft alone from opening the door. Backup admin identities kept separate from production admin accounts prevent a single credential compromise from ending the recovery option.
Every one of these has to be configured. All of them together are the baseline in 2026. None of them alone are enough.
The Restore Test Nobody Ran
The failure mode nobody talks about is not the backup that stopped running. It is the backup that appeared to run every night for two years and produced files nobody could actually restore.
Three specific things break backups without anyone noticing:
- Corruption at the block or file level. The backup job completes. The status is green. The backing storage has silently corrupted the file due to a disk fault, a controller bug, or an incomplete write. Nobody sees it until the restore fails.
- Retention drift. The policy says 30 days. The actual retention is 7 days because of a storage quota, a misconfigured job, or a change nobody documented. The moment you need to recover to a point older than what the appliance actually kept, you find out.
- Snapshots that turn out to be crash-consistent, not application-consistent. Your database was mid-write when the snapshot fired. The snapshot is technically valid. The database restored from it will not start.
Every one of these is invisible until someone tries to restore. That someone should be your MSP on a scheduled cadence, not you at 3 a.m. after an incident.
What Real Backup Restore Testing Looks Like
Real backup restore testing is not opening the backup product and looking at the green checkmark. It is provisioning a target environment, a segregated VM, a spare fileserver, a sandboxed cloud account, and restoring the data there. Reading the files. Booting the workload. Running the application against the restored dataset. Documenting the time it took. Documenting who watched it happen.
The recovery time objective on your business continuity plan is a number your MSP promised. The tested recovery time is a number your MSP proved. Those two numbers are almost never the same, and the gap between them is what your business will actually experience during a real incident.
Once a year is not enough. Once a quarter is the floor for business-critical workloads. Monthly is common for high-value data and any workload subject to a compliance framework that treats recovery as an auditable control.
What Your MSP Should Be Handing You
If backup restore testing is part of your service, you should be able to walk into any conversation about disaster recovery with a specific set of documents in hand.
A restore test report from the last 90 days that names the workload, the target environment, the restore duration, and the result. Not a job log. A report someone had to write.
Documented recovery time and recovery point objectives, with the tested numbers next to the promised numbers. When those two do not match, that is the conversation to have before the incident, not during it.
Immutable backup configuration attestation. Which storage tier is immutable. What the retention lock period is. How the credentials that reach it are separated from production credentials.
A ransomware-specific tabletop exercise on file. Not the generic disaster recovery drill. The specific scenario where the production systems are encrypted, the primary backup appliance is unreachable, and the recovery has to run from the secondary or offsite copy.
Where This Leaves You
Backups are not what you paid for. Recoverability is what you paid for. The subscription line item on your MSP invoice for backup is buying you the first thing. Only backup restore testing gives you the second.
If your MSP cannot show you a dated, scoped, documented restore test from the last 90 days, they have sold you the appearance of recovery without the confirmation of it. That is not their failure alone. It is a gap nobody knew to ask about until the day the phone rang at 2 a.m. Now you know to ask. Ask this week.
Sources
1 Veeam, “Data Protection Trends Report 2024 Finds Cyber-Attacks the #1 Cause of Business Outages,” veeam.com, January 17, 2024.
2 Sophos, “The State of Ransomware 2025,” sophos.com.
About Brent Lacy: Brent Lacy has been in the IT industry since 1997. He moved into the managed services world around 2015 and was doing vCIO work before the title even existed. He writes about the operational discipline, trust-based relationships, and strategic thinking that separate MSPs built to last from those built to bill. He is the author of Rewired MSP: Mastery, Scalability and Performance, vCIO Rewired: Virtually Conquering IT Obstacles, and Near Miss: Preventable IT Failures Threatening Your Business Security.
