Three controls that solve different problems
Backup, high availability and disaster recovery are often discussed as if they were interchangeable. They are not. A backup is a recoverable copy of data or system state. High availability is an architecture intended to keep a service running through selected component failures. Disaster recovery is the coordinated process for restoring an acceptable business service after a serious disruption. A resilient design may use all three, but each addresses a different failure pattern.
A replicated database can improve availability, yet corruption or malicious encryption may be replicated too. A clean backup can restore the data, but a large restore may take longer than the business can tolerate. A second site can host recovery systems, but it will not help if identity, DNS, network routes, certificates, application configuration and trained people are absent. The design has to connect copies, infrastructure, dependencies and operating decisions.
- Backup answers: can we recover an earlier, usable copy?
- High availability answers: can the service continue through a defined local failure?
- Disaster recovery answers: how will we restore the complete service after a major event?
Set recovery objectives from business impact
Recovery time objective (RTO) is the target time to restore a service after disruption. Recovery point objective (RPO) is the maximum targeted data-loss interval, expressed as a point in time. Neither is a promise by itself. Both should come from a business-impact discussion that considers financial operations, customer commitments, safety, legal duties, manual workarounds and dependencies.
Apply objectives to business services, then map the systems underneath. The order matters. Restoring an application before identity, network connectivity or its database may achieve nothing. Services with similar names can require different objectives: a public website, order-processing system and archive might all store files, yet have very different urgency and acceptable data loss.
- What happens after one hour, one business day and several days without the service?
- How much recent data could be reconstructed, and by whom?
- Which upstream and downstream systems must recover first?
- Who is authorised to declare a disaster and prioritise restoration?
Design backups for recoverability
Define backup scope at the level needed to rebuild the service: databases, files, virtual machines, cloud configurations, software settings and relevant software-as-a-service data. Select retention from operational and legal needs. Keep copies sufficiently separated from the production failure domain, and consider immutable or offline options where the threat model includes ransomware or privileged-account compromise.
The familiar idea of multiple copies on different media with one copy off-site can be a useful starting heuristic, but it is not an acceptance test. Cloud-region design, encryption keys, identity separation, bandwidth, retention locks and deletion authority all influence whether a copy survives the incident. Monitor job completion and capacity, investigate failures, and protect the backup administration plane with strong identity controls.
A successful job only shows that data was written. Recovery testing shows whether the data is readable, sufficiently current and usable by the application. Test representative file, database, virtual-machine and complete-service restores. Record duration, prerequisites, errors and the evidence needed to accept the result.
Build disaster recovery around dependencies
A recovery strategy might restore from backup, replicate systems to another site or cloud, maintain a warm environment, or run an active service across locations. Faster objectives usually require more pre-provisioned capacity, automation and operational discipline. Choose the pattern per service instead of assigning the most expensive pattern to everything.
Map identity, DNS, network, certificates, keys, licences, external integrations, support contacts and minimum staffing. Decide how users will connect when the primary office or identity path is unavailable. Confirm whether suppliers support operation in the recovery location and whether data transfer, replication and standby systems have separate commercial requirements.
Write a runbook that names triggers, authority, communications, technical sequence, validation and return-to-normal steps. A document stored only on the affected system is not useful. Keep an accessible controlled copy, but protect sensitive credentials and network information through an appropriate secure process.
Test decisions, not only technology
Use several test depths. A tabletop exercise can expose unclear authority and missing contacts. A component restore can validate backup media and permissions. An isolated service recovery can test dependencies without affecting production. A planned failover can validate routing, user access and operating procedures. Select a safe method and define success criteria, risk controls and rollback before each exercise.
Exercises should answer practical questions: Can the team obtain emergency access? Are recovery credentials independent of the failed identity path? Can someone reach the relevant supplier? Does the application owner recognise a correct result? Can the business reconcile transactions after the recovered point? Capture lessons as assigned actions and test the revised step, rather than filing the report and assuming readiness.
A concise planning sequence
Begin with a service catalogue and business-impact workshop. Assign service-level RTO and RPO targets, then map technical dependencies and current controls. Compare the existing backup and recovery capability with those targets. Prioritise gaps where business impact is high or recovery evidence is weak. Create a staged roadmap that includes technology, runbooks, ownership and exercises.
Ask providers to state assumptions and boundaries clearly. A backup project should specify protected sources, frequency, retention, copy location, immutability, encryption, monitoring and restore tests. A disaster-recovery project should additionally specify recovery architecture, sequence, capacity, invocation authority, communications and test method. The goal is not a claim that failure is impossible; it is an evidenced ability to make controlled recovery decisions.