Observable condition
The backup dashboard is green. Files are copied. Snapshots exist. Management therefore assumes the business can recover from a serious failure.
Then a real incident asks harder questions: which systems must return first, which application depends on which database, whether credentials and configuration are recoverable, how long restoration actually takes, and whether the restored environment is clean and usable.
Realisation
A backup is evidence that data or system state has been copied. Resilience is evidence that the business can restore the services it depends on within an acceptable period and with acceptable loss.
NIST's 2026 OT Backup Quick Start Guide explicitly includes regular backup creation, testing and review during recovery exercises. CISA likewise recommends offline or protected backups and regular testing of availability and integrity. The underlying principle is broader than any one technology: recovery must be exercised, not assumed.
Identification
This is a recovery-readiness and service-resilience problem. The visible condition is “we have backups.” The structural question is whether people, systems, dependencies and recovery procedures can reconstruct the service the business actually needs.
Diagnosis
Backup confidence can hide weak recovery design when:
- restores are rarely or never tested end to end;
- critical service dependencies are undocumented;
- recovery priorities are based on systems rather than business services;
- credentials, configurations, integrations or infrastructure definitions are excluded;
- recovery responsibilities are unclear during an incident;
- the organization has not defined tolerable downtime or data loss.
A technically successful restore can still fail commercially if the wrong service returns first or the business cannot reconnect the dependent workflow.
Commercial impact
The Commercial Value Wrapper is uptime, revenue protection, resilience and scalability. Recovery uncertainty lengthens outages, increases operational improvisation and can turn a contained technical failure into a larger business interruption.
As infrastructure becomes more interconnected, the commercial unit to protect is increasingly the service or process, not an isolated server or file set.
Common misidentification
The common mistake is to equate backup completion with recovery readiness. Another is to buy more backup capacity without defining recovery objectives or testing the restoration path.
More copies can improve protection, but they do not replace dependency mapping, prioritisation and exercises.
Possibility
A more resilient state starts with business-critical services and works backward to the systems, data, identities, integrations and configurations required to restore them. Recovery procedures are tested, ownership is explicit and results are used to improve the design.
Intervention
Identify the services whose interruption would materially affect customers, revenue, safety or operations. Map their dependencies, define recovery objectives, confirm what is actually backed up and run controlled restore exercises. Record how long recovery takes, what fails and what must change.
The intervention may include backup architecture, immutable or offline protection, infrastructure-as-code, disaster-recovery design, recovery runbooks, dependency mapping and regular exercises. The target is recoverable business capability.
Practical diagnostic questions
- When was the last successful end-to-end restore test?
- Which business service must recover first after a major failure?
- Are identities, configurations and integrations included in recovery planning?
- Can the organization state its acceptable downtime and data-loss tolerance?
- Who owns recovery decisions during an incident?
Bottom line
Backups are necessary, but they are not the same as resilience. The stronger test is whether the organization can restore the business service, in the right order, within a period the business can tolerate.
Sources and further reading
Related Mellorca reading
- The Financial Cost of Backups That Have Never Been Tested
- What Service Levels Make Sense for Business-Critical Automations?
- Why Business Systems Need Ongoing Stewardship