IT Tips & Tricks
Your Backup Worked. Why Can’t You Recover?
Why Successful Data Backup Doesn’t Guarantee Disaster Recovery
Published 3 November 2026
The backup console is reassuring. Last night’s job is marked Success, Completed or Succeeded. The logs show no errors. Somewhere in the building, an IT manager is enjoying a rare moment of calm.
That calm lasts until a ransomware attack, system failure or spectacularly ill-timed human mistake forces the organization to put those backups to the test. The question isn’t whether the data was copied. It’s whether the business can be rebuilt from it.
Suddenly, those reassuring status messages look less like proof and more like an overly optimistic suggestion.
Among IT respondents who had experienced ransomware during the previous 12 months, only 28% said they were able to recover all affected data. Another 44% recovered less than 75% of the data.
The gap between a successful backup and a successful recovery is wider than many organizations realize. For its 2026 Data Trust and Resilience Report, Veeam surveyed more than 900 security leaders spanning C-suite and frontline security roles. Ninety percent said they were confident their organizations could recover from a cyber incident within their recovery time objectives. Yet among respondents who had experienced ransomware during the previous 12 months, only 28% said they had fully recovered all affected data. Another 44% recovered less than 75%.
Pre-disaster confidence in their recovery capabilities was nearly universal. Complete recovery among ransomware-affected organizations wasn’t.
The lesson is simple, although not especially comforting: A successful backup job isn’t proof of a successful recovery.
Backup Is an IT Task, but Recovery Is a Business Outcome
Backup and recovery are two quite different things, a distinction that may not become fully apparent until a real outage puts both to the test.
A data backup system has a relatively narrow job. It copies selected data according to a schedule and policy. If the expected bytes arrive, the job may be recorded as successful.
Recovery asks a much larger question: Can the organization restore trustworthy data, applications, identities, permissions and connections quickly enough for people to get back to work?
Backup and recovery are two quite different things, a distinction that may not become fully apparent until a real outage puts both to the test.
A company can restore database files yet still be unable to run the application if the backup or recovery process didn’t include the required configuration, encryption keys, service accounts or other dependencies. Files may be restored successfully, but users still may not be able to open them if access permissions weren’t restored correctly or the relevant user accounts and groups are missing. If files are restored to a new location, the links pointing to them (from other files) will continue looking for them in their old locations.
These types of failures don’t necessarily mean the backup was corrupt. They usually mean the recovery process didn’t reconstruct everything the data depended on.
The data may be back, but the organization could still be on its knees.
Your Backup Can Be Complete and Still Be Wrong
Corruption isn’t always dramatic. A backup can contain damaged files, incomplete application data or malware that entered the environment before the copy was made.
If corruption goes unnoticed for weeks, recent recovery points may faithfully preserve the problem. That’s a rather grim example of automation doing exactly what it was told.
Ransomware adds another complication. Attackers may try to find and damage accessible backups before encrypting production systems. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends maintaining offline, encrypted backups and regularly testing their availability and integrity.
Recovery can stall over the smallest unseen dependency.
Isolation is important because a backup that uses the same credentials, network pathways or administrative environment as production may share the same fate.
The organization must also identify a clean recovery point.
The Missing Pieces May Not Look Like Data
Many recovery plans concentrate on the large, obvious systems: file servers, databases, virtual machines and major applications. Real operations also depend on less conspicuous pieces.
Just one missing dependency can turn restored data into an impressive but unusable collection.
Think about DNS, certificates, service accounts, encryption keys, license servers, configuration files, APIs and scheduled jobs. Add identity systems, multifactor authentication, privileged accounts and the devices administrators need to reach the recovery environment.
One missing dependency can turn restored data into an impressive but unusable collection.
Microsoft’s current training for advanced Active Directory recovery, for example, covers far more than restoring a domain controller. It includes recovery sequencing for domains and forests, plus validation of replication, DNS, SYSVOL, time, authentication, trusts and applications before reconnection. That list reveals why “restore the server” is rarely a complete recovery plan.
Organizations need dependency maps showing what each critical service requires and what must come online first. During an outage, “Someone in infrastructure probably knows” isn’t documentation.
SaaS Data Has a Habit of Slipping Through the Cracks
The modern organization’s data estate no longer fits inside the data center. Important information may live in Microsoft 365, Salesforce, Box, project-management platforms and specialist cloud applications.
It’s easy to assume that because a provider keeps the service running, everything stored inside it is covered by the organization’s recovery plan. Availability, retention and backup are related, but they aren’t interchangeable.
A forgotten application often becomes important at precisely the moment nobody can log into it.
Coverage also varies by workload. Microsoft 365 Backup, for example, protects selected SharePoint sites, OneDrive accounts and Exchange mailboxes, with different restore options for each. Microsoft explicitly notes that what matters isn’t simply the backup, but whether data can be restored to a healthy state quickly.
That overlooked SaaS application may be the one holding data that the business suddenly needs.
Every organization should know which SaaS applications hold critical data, what recovery features each provides, how long material remains recoverable and whether a separate backup is required. It should also know who can initiate recovery.
A forgotten application often becomes important at precisely the moment nobody can log into it.
Recovery Order Can Decide Whether Recovery Works
When many systems are down, restoring the most visible one first may feel sensible. It may also be the wrong move.
Applications depend on databases. Users depend on identity services. Identity services may depend on DNS and time synchronization. Automated processes rely on service accounts, certificates and network routes. Files may rely on links to other files, applications or cloud locations.
Starting these components in the wrong sequence can produce errors that look like failed restores even when the data itself is sound. Teams may waste hours troubleshooting applications that are simply waiting for an unseen dependency.
A useful disaster recovery plan describes sequence, not merely inventory. It identifies the minimum systems needed to resume critical work, which components come first and how each will be validated.
That plan should also account for the possibility that the usual documentation, ticketing system and password vault are unavailable. A recovery guide trapped inside the system being recovered has a certain dark, comedic elegance, but not much practical value.
Authentication Can Lock Out the Rescuers
During an ordinary workday, centralized identity is wonderfully convenient. During a major outage, it can become a single locked door.
What happens if administrators can’t reach the identity provider? Can they access backup consoles without production authentication? Are emergency accounts protected and tested? Does multifactor authentication rely on an unavailable service? Can the team retrieve encryption keys?
Answer these questions before anyone is reading the recovery plan by flashlight.
Emergency access must be tightly controlled, monitored and used only for its intended purpose. It also has to work. An untouched break-glass account with an expired credential is less a safeguard than a historical artifact.
A Restore Test Is Only Useful If It Resembles Trouble
Many organizations test recovery by restoring a few files to a convenient location. That confirms something, but not enough.
NIST’s Guide for Cybersecurity Event Recovery recommends identifying and prioritizing organizational resources, developing recovery playbooks and using realistic test scenarios. Realistic is the key word.
A meaningful test removes shortcuts that won’t exist during an incident. It assumes production systems may be unavailable or untrusted. It checks whether recovery staff can obtain instructions, credentials, clean devices and usable data. It measures whether restored applications support business work.
The test should answer questions such as:
- Can we restore at the required scale, not just one file?
- Can users open the restored data and do their jobs?
- Are permissions, metadata, links and application relationships intact?
- Can we prove the recovered environment is clean?
Only a well-tested recovery can tell you whether the organization can begin again.
- Do our actual recovery times match our stated objectives?
- Which decisions require executives, legal counsel, insurers or outside specialists?
Afterward, the organization should update its documentation. A recovery exercise that uncovers twelve problems and changes nothing has merely scheduled the same nasty surprises for later.
Measure What the Business Gets Back
Backup success rates are still useful. They just shouldn’t be mistaken for recovery readiness. Better measures include the percentage of critical services restored, recoverable data, time required to resume priority business functions and unresolved dependencies. Recovery point objectives should reflect how much recent data the organization can afford to lose. Recovery time objectives should reflect how long the business can operate without each service.
Both should be agreed with business leaders, not simply chosen because they make a dashboard look good.
Veeam’s findings also suggest that alignment remains a problem. Although 90% of respondents expressed confidence in meeting recovery time objectives after a cyber incident, only 69% said those objectives were fully aligned with business continuity goals.
That discrepancy tells its own story. Restoring a system within its technical target is of limited comfort if the business process it supports remains unavailable.
Make Recovery Something You Can Prove
Recovery confidence is built during realistic rehearsals, not abstract discussions about what could or should work.
Organizations don’t need less confidence in their backups. They need confidence supported by evidence.
That means knowing what is protected, preserving clean and isolated copies, mapping dependencies, documenting the correct recovery order and preparing for identity failures. It means including SaaS data and the relationships that make restored files useful. Most of all, it means testing the whole process under conditions that feel inconvenient, pressured and real.
The best recovery exercise may be the one that fails in a dozen irritating ways. Every failure discovered during a test is one less nasty surprise waiting to introduce itself during a ransomware attack, cloud outage or other very bad Tuesday.
A green backup report can tell you that last night’s job finished. Only a well-tested recovery can tell you whether the organization can begin again.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment