Most organizations have a disaster recovery plan. The question is, “can you actually count on it?”
Backups get scheduled, replicated, and monitored every day. Recovery, on the other hand, only gets tested when someone finds the time, the budget, and a spare environment to test it in. For many organizations, that can be a rare occasion given the costs of creating a separate infrastructure environment, escalating responsibilities for IT teams, and tightening resources. The result is a gap between “we have backups” and “we can recover” that doesn’t show up until the day it matters most.
Recent research from HyperFRAME Research puts a number on that gap: 91% of organizations say cyber resilience is a priority, but only 30% are very confident in their recovery speed and capabilities following a cyberattack or cloud-based data loss event. That’s not a small discrepancy. It means most organizations that believe they’re prepared haven’t actually proven it. If you manage backup, disaster recovery, or compliance for an IBM Power or IBM i environment, here are five questions worth asking before you assume your recovery plan will hold up.
- When was the last time you actually recovered from your backups, not just restored a file?
There’s a real difference between confirming a backup job completed successfully and confirming that a full system, application, or environment can be brought back online and made usable again. Restoring a single file or verifying a checksum tells you the data exists. It doesn’t tell you whether an LPAR will boot cleanly, whether dependencies will resolve, or how long the process will actually take under pressure. If your most recent “test” was really just a backup verification, you don’t yet know whether your recovery plan works. You know your backup job works.
- Could you test recovery today without disrupting production or spinning up new infrastructure?
This is where most recovery testing programs quietly stall. Building a dedicated clean room environment, one that’s isolated, current, and safe to test in, takes planning, budget, and usually months of setup. Many teams reasonably decide that recovery testing is something they’ll get to next quarter, and next quarter becomes next year.
The organizations with real confidence in their recovery speed are the ones that removed the friction. They can spin up an isolated test environment on demand, run the exercise, and tear it down again without touching production or maintaining a complete and separate costly infrastructure.
- Does every recovery test start from a truly clean, known state?
A test environment that’s been reused, patched inconsistently, or left running since the last exercise isn’t really testing recovery. It’s testing whatever configuration drift has accumulated since then. If malware, misconfigurations, or stale settings can carry forward from one test to the next, a “successful” test may not reflect what would actually happen during a real incident.
Validated recovery means each test starts from a known clean baseline, every time. No leftover state. No assumptions carried over from the last exercise.
- If an auditor asked for proof of tested recovery tomorrow, could you produce it?
For organizations subject to regulatory frameworks like DORA, “we have a DR plan” isn’t sufficient. Auditors increasingly want documented evidence that recovery has been tested and works. Scrambling to assemble that proof after the fact, or worse, treating it as a standalone compliance project, is a sign that recovery testing isn’t built into the operational rhythm. Audit-ready recovery documentation should be a byproduct of routine testing, not a fire drill of its own.
- Is recovery testing something your team does, or something your team dreads?
This one is less technical, but it matters. If recovery testing requires specialized cloud expertise, weeks of coordination, or pulling infrastructure out of storage, it’s going to keep getting deprioritized. Not because it isn’t important, but because it’s genuinely hard to do. A recovery plan that’s too costly or complex to test regularly is, functionally, an untested plan.
The goal should be a process simple enough that testing happens routinely, not just when a compliance deadline forces the issue.
The Takeaway
A recovery plan that hasn’t been tested isn’t really a recovery plan. It’s a hypothesis. The gap HyperFRAME Research identified isn’t about whether organizations are capturing their data; it’s about whether they’ve proven they can get it back.
If you answered “no” or “not sure” to more than one of these questions, it’s worth a closer look at how and how often recovery gets validated in your environment. That’s exactly the conversation we’re having in “Is Your IBM i Data Truly Recoverable?” Join us to see these five questions apply to your real IBM i and IBM Power scenarios, and how organizations are closing the gap between “backed up” and “recoverable.” Register here.
