Backup Jobs Finish. Few MSPs Prove They Actually Restore

Most BCDR line items fail for a reason that has nothing to do with backup software. The backup job completes, the dashboard shows green, and nobody actually tries to restore from it until the day a client needs it. That gap between a completed backup and a proven restore is where BCDR operations are quietly failing right now, and insurers are starting to underwrite around it.

Is Having a Backup the Same Thing as Being Able to Restore One?

No, and the gap between the two is wider than most BCDR sales conversations admit. Among businesses with backup solutions in place, less than two-thirds, 63 percent, successfully restored their data after a ransomware attack, while 31 percent saw their backups fail, according to At-Bay's Backup Breakdown report.

The consequence of that failure compounds immediately. At-Bay's report also found that companies that failed to restore their data were three times more likely to pay a ransom than companies that restored successfully. The same report found that effective backups reduced the severity of a ransomware claim by 41 percent. A backup job that completes successfully every night but has never been proven to restore is not actually the risk reduction your contract implies it is, it is an unverified assumption with a one-in-three chance of failing at the worst possible moment.

"Proven to restore" has a specific operational meaning that a green status light does not capture. It means someone on your team has actually pulled files, or ideally a full system image, out of a backup set and confirmed they open and run correctly, recently enough that nothing about the source environment has drifted out from under the backup since the last test. A backup job can report success every single night while silently failing to capture an application's database consistently, and the only way to catch that failure mode before a client needs the restore is to actually attempt one.

Why Do So Few MSPs Actually Test Their Own Backups?

Mostly because testing competes directly with billable work for the same technician hours, and nobody notices the gap until a restore fails. Over half of businesses test their disaster recovery plan once a year or less, and 33 percent test infrequently or never at all, according to Kaseya's reporting on backup testing habits.

That testing gap is not a client-facing problem until the exact moment it becomes the only problem that matters. A backup contract sold on recovery time promises, without a tested restore behind those promises, is a liability dressed up as a service line. The fix is not more frequent full-scale disaster simulations for every client, which most MSPs genuinely cannot staff, it is a tiered testing cadence, frequent file-level restore checks for critical systems and periodic full restores for everything else, that at least closes the gap between what the contract promises and what has actually been proven to work.

Building that cadence into a recurring operational task, tied to a calendar rather than to whenever a technician has spare time, is the difference between a testing program and a testing intention. An intention that lives in a runbook nobody revisits is functionally the same as not testing at all, and it shows up as the same 33 percent statistic the next time someone surveys the industry.

The staffing math behind this is not complicated, it is just rarely written down. A technician who spends a small, predictable block of time running file-level restore checks across a client's critical systems, with a fuller system restore on a longer cycle, is trading a scheduled, bounded task for the alternative, an unplanned multi-day outage during the one incident where the restore actually has to work. Framing testing hours as billable risk-reduction work, rather than overhead that gets deprioritized the moment a client calls with an urgent ticket, is the operational change that actually closes this gap.

Are Cyber Insurers Now Requiring Proof That Backups Actually Work?

Increasingly, yes, and attestation alone is no longer enough. Insurers now expect immutable, write-once backup storage that an attacker cannot modify even after compromising production credentials, along with regular restoration testing that produces evidence the backups actually restore, not just that the backup job completed, according to TechTarget's reporting on how cyber insurance requirements are reshaping backup architecture.

That shift changes what a BCDR line item actually has to deliver. A client's ability to renew or qualify for cyber coverage now depends in part on documentation your team produces, not just infrastructure your team maintains. An MSP that cannot hand a client auditable proof of a recent, successful restore test is putting that client's insurability at risk alongside their data, which raises the operational stakes of testing well past what a missed SLA used to cost.

That documentation requirement also changes what counts as finishing the job. A restore test that a technician ran and verbally reported as successful is not the same deliverable as a dated record showing what was restored, when, and by whom, with enough detail that an underwriter reviewing the client's application would accept it as evidence rather than an attestation. Building that paper trail as a standard output of every test, rather than reconstructing it after a client's broker asks for proof, is a small process change that turns a thing you were already doing into something you can actually show.

Is Backup Recovery Enough on Its Own Anymore?

Not against the way ransomware attacks are actually structured today. Dual extortion attacks, where attackers both encrypt data and steal a copy of it before encrypting, accounted for 70 percent of ransomware claims tracked by Coalition in its most recent claims data, reported by Help Net Security. The same data shows 86 percent of ransomware victims refused to pay a ransom demand, with ransomware claim severity falling 19 percent as backup-based recovery improved.

That combination is good news and a new operational complication at the same time. Backup-based recovery is working well enough that fewer victims feel pressured to pay, which is the entire point of running BCDR operations well. But a successful restore does nothing to undo a data theft that already happened before encryption started, which means a technically successful recovery can still leave a client facing breach notification obligations and reputational exposure that backup alone was never built to solve.

That gap matters for how you scope a BCDR engagement going forward. A recovery runbook that stops at "systems are back online" is answering only half the question a client actually has after an attack, because the other half, what data left the network and who needs to be notified, lives in your detection and logging posture rather than in your backup platform. Operationally, that argues for tying BCDR testing to a broader incident-response review rather than treating backup verification as a self-contained checklist item disconnected from the rest of the security stack protecting the same client.

What Should This Change About How You Run BCDR Operations?

Treat backup testing as a scheduled operational task with the same priority as the backup job itself, not as something that happens when a technician has a free afternoon. A restore that has never been tested is not a verified recovery capability, it is an assumption riding on the hope that the day it matters is not the day it fails, and the data above says that hope is wrong often enough to matter.

Documentation matters as much as the test itself now that insurers are asking for it directly. A technician who can produce a dated restore-test record for a client's critical systems is protecting that client's insurability in addition to their data, and that is a different value proposition than simply running the backup job every night. Building that habit, and the broader discipline of verified, documented BCDR operations, into how your technicians actually work is a training problem as much as a tooling one, and Forge University's AI-mentored IT and security certification training is built to close exactly that kind of operational skills gap.

Standardizing that testing and reporting discipline across every client, instead of leaving it to whichever technician happens to own a given account, is also where a broader white-labeled operations catalog pays off, by layering consistent monitoring and verification on top of whatever backup infrastructure you already run. If you are not sure how much of your current BCDR line item is tested versus assumed, running it through the stack builder is a fast way to see where the gap sits before a client's next renewal, or next insurance application, tests it for you. See the full stack to see how a white-labeled platform can turn backup verification into a documented, repeatable process instead of a once-a-year guess.