Q&A: Why successful backups don't guarantee recovery

There is no shortage of products and features in the data backup market, but many organizations have difficulty recovering systems when hit with a disruption. Vendors promote immutable backups, speedy RPOs and easy-to-use dashboards, but many organizations find those capabilities alone do not ensure a successful recovery in a high-pressure situation.

Thanks to AI-powered ransomware and phishing campaigns, attackers can act more swiftly, customizing their impersonation attempts on a large scale and easily bypassing legacy controls. This has put more pressure on organizations to achieve clean and prompt recovery. Moreover, the use of multiple cloud platforms, together with the widespread SaaS adoption, can hide key dependencies and mask responsibility. These challenges raise the risk of restoring to a compromised environment and make it harder to prove end-to-end recoverability.

The real test for recoverability is not the size of the backup volume but the organization's ability to restore business services in the correct sequence as quickly as possible.

Obuks Akpede, a data governance consultant at Adastra Corporation, helps organizations improve their resilience capability by moving from traditional backup methods. In this Q&A, he discusses common recovery shortcomings, the metrics that matter most and the operational practices that can increase resilience against evolving threats.

Editor's note: This Q&A has been edited for length and clarity.

Leaders often see a "green" backup dashboard and feel confident. Where does that go wrong and what mindset closes the gap?

Obuks Akpede: It's common to see immutable copies, established RPOs and clean audit reports and think that means you have recoverability. But none of that demonstrates how your team performs under real conditions. Backups show you can make copies, but they don't show you have true recovery capability. The trap is treating recovery as a feature checkbox on a backup product. Resilience isn't something you toggle on -- it's something you design into your operating model.

Obuks Akpede

What works is a shift from "we have copies" to "we can restore services under pressure." That means integrated processes, tested failure scenarios and cross-functional coordination so teams know what comes first and how to move in the right order.

Top Tip: Stop looking at backup success rates. Ask for evidence of the last full end-to-end recovery of your top business services.

Even when backups appear healthy, recovery efforts can still fail. What are some of the common causes?

Obuks Akpede: Teams often know their own stack but miss what sits underneath it: DNS, identity, messaging, middleware, monitoring and shared storage. In a real outage, they bring back the application tier only to discover a hidden dependency blocks the comeback.

[Recovery data] can also become the attack path back into production if you restore malware persistence, corrupted datasets or compromised credentials without clean rooms, [validation procedures] or credential hygiene.

And leadership frequently gets slides full of green backup jobs without any proof that services have been restored end-to-end under realistic conditions, creating a false sense of confidence.

Top Tip: Keep dependency maps up to date and make them part of the workflow. Report on real-world service recovery tests and highlight unresolved issues.

Can you share real-world cases that show why backups aren't enough? What you would engineer differently for identity and landing zones?

Obuks Akpede: When NotPetya hit Maersk, domain controllers were wiped almost simultaneously. Active Directory came back only because one DC survived due to a separate power outage. Recovery hinged on luck -- not design. At the British Library, clean backups existed, but legacy systems and a lack of viable infrastructure meant there was nowhere trustworthy to restore to. Recovery dragged on because the landing zone hadn't been engineered.

If you were designing differently, you would treat identity and landing zones as tier‑zero assets. For identity, engineer diversity and isolation -- offline or out‑of‑band copies, segmented controllers and rehearsed restoration procedures. For landing zones, provision pre‑approved clean environments with capacity, controls and validation tooling ready to receive restores.

Top Tip: Sources of trust (identity systems and clean backup copies) and recovery environments (landing zones) should be day-one priorities.

What does a well-defined recovery process look like in practice?

Obuks Akpede: The engineered recovery model turns recovery from ad‑hoc restores into a structured operating capability. It starts with prioritize: identify critical services, define restore tiers and make decision rights explicit so teams know what comes first when everything is down.

Next is sequence: map dependencies and define restore order across identity, network, storage, platforms and applications. Services return along chains. Isolate then prepares clean restore zones, protects credentials and keys and establishes [validation procedures] for malware and data integrity.

Rehearse is where assumptions are tested, running drills at increasing realism, validating workflows and surfacing failure modes. Finally, report translates operational outcomes into assurance metrics that boards and executives can understand and act on.

Top Tip: Write your recovery plan around these five steps and assign clear ownership so it becomes a working process -- not just a diagram.

During recovery, why does the restoration sequence matter, and what breaks when foundations are unstable?

Obuks Akpede: Restores should follow a layered cadence. Bring back foundational layers first -- data centers, power, storage and backup services and security controls. Then move to controllers and monitoring, compute and virtualization and finally applications in business-critical order.

When foundations are shaky, everything above becomes brittle. A fragile network perimeter makes identity and app traffic unreliable. Poorly segmented or under-resourced storage and backup platforms slow or contaminate restores. Missing monitoring leaves the team flying blind. The only way to know is to test layer by layer: stress the foundations and measure time to application readiness, then focus investment where a failure would collapse the stack.

Top Tip: Stress test and confirm that infrastructure and foundational layers are working as expected before moving onto business applications.

What drills actually build confidence, and what kinds of weaknesses should they reveal?

Obuks Akpede: First, tabletop exercises: stakeholders in a room, walking through scenarios and decisions. These expose missing roles, weak escalation paths, unclear ownership and unrealistic assumptions about dependencies.

 Second, technical recovery drills: targeted restores of infrastructure, key applications and identity. These uncover missing dependency maps, unavailable credentials or encryption keys, weak data quality readiness and validation bottlenecks, where nobody is clearly responsible for proving data is good.

 Third, production‑scale simulations: end‑to‑end drills at realistic volume and pressure. These reveal resource contention, outdated runbooks that no longer match reality, metric‑driven false confidence and broken communications when collaboration tools themselves are degraded.

Top Tip: If a drill feels too neat and frictionless, it probably isn't realistic enough.

Which metrics best demonstrate end-to-end recoverability, and how should they be presented to leadership?

Obuks Akpede: The most useful metrics don't come from backup tools; they come from rehearsed recoveries. Start with last validated end‑to‑end recovery date for each critical service, including conditions and scope. Add percentage of critical dependencies tested together rather than in isolation. Track time to prepare a clean restore environment, and number and severity of open recovery blockers with named owners and target dates.

 For leadership, present these in a simple service‑level view: a small portfolio of top business services, each with its last tested recovery, dependency test coverage and current risk status. Pair that with a brief about recent drills and what they revealed.

Top Tip: Leaders need decision-ready facts. Provide them with recovery test dates, dependency coverage, recovery preparation time and a list of blockers with owners and due dates.

For an organization that wants to improve its recovery capabilities, what should they prioritize during the first 90 days?

Obuks Akpede: Days 0–30 are about baseline reality. Identify your top‑tier services, map their critical dependencies, confirm recovery owners and document clean restore prerequisites. The checkpoint is simple: can you describe, on one page per service, what it takes to bring it back?

Days 31–60 focus on evidence. Run targeted rehearsals for those services, document the failure modes you discover and fix the highest‑value blockers that are typically around identity, storage, networks and validation. The checkpoint here is: do you have at least one credible drill outcome per top service?

Days 61–90 are about assurance. Translate drill outcomes into executive metrics, establish a recurring recovery readiness review and embed recovery into governance. The checkpoint: leadership receives a concise resilience report with tested recoveries, open risks and planned improvements.

Top Tip: Assign a clear owner to each phase and make progress visible. Accountability and transparency accelerate results.

How does a small or mid-sized company without a big program office adopt this pragmatically? Where should they start?

Obuks Akpede: Smaller organizations often assume sophisticated recovery frameworks are only for large enterprises, but the principles scale down well. The key is to start narrow and focus on the services that would genuinely hurt you if they were offline for days.

First, identify three to five top‑tier services and sketch their dependency chains. Second, define basic clean restore prerequisites: where you would restore, how you'd keep it isolated and who would validate data. Third, run one or two targeted drills per year on those services, even if they're partial. Finally, report simple evidence to leadership: what you tested, what broke and what you fixed.

You don't need a full program office to do this; you need clear ownership and a short list of services that matter.

Top Tip: Even small organizations can move from "we think we're fine" to "we have proof we can come back" without boiling the ocean.

Ana Salom-Boira is an editorial manager within TechTarget's Editorial Summits team. She also produces and hosts the podcast series Tech Beyond the Hype, which explores how emerging technologies and the latest business trends are shaping the future of work.