Disaster Recovery vs High Availability: Staying Up vs Coming Back After Loss

High availability keeps a service running through component failure, but it faithfully copies every deletion, corruption and encrypted block to the standby, so it cannot bring you back from a loss it helped spread. Disaster recovery is the separate capability to restore a service to a known good state, at a known point in time, after the primary and its replicas are gone or untrustworthy. Many organisations fund one and assume they have the other. This guide gives the short answer, a side-by-side comparison, the threat model and failure modes of each, how RTO and RPO differ between them, the identity and secrets dependencies that decide whether either works, and a worked scenario. It is for infrastructure architects, resilience and continuity leads, and security teams who own recovery of identity platforms, vaults and data stores.

Key takeaways

• They answer different questions. High availability (HA) asks "will the service survive a failed node, zone or link?"; disaster recovery (DR) asks "can we rebuild the service and its data from a clean point after we have lost it?".
• Replication is not a backup. Synchronous and asynchronous replication copy bad writes as fast as good ones; AWS guidance states replication may not protect against corruption or destruction unless the strategy also includes versioning or point-in-time recovery.
• HA usually has an RPO near zero only for hardware failure. For logical corruption, ransomware or an admin mistake, the real recovery point is the last clean backup, which can be days old.
• Identity and secrets decide recovery. A DR site that needs the primary directory, identity provider (IdP), key management service or vault to start is not a DR site.
• Only tests prove either. Failover drills prove HA; timed restores from isolated copies into a clean environment prove DR. Use measured drill times, not design targets, when you report RTO.

The short answer

Buy and build HA when the business cannot tolerate minutes of outage from routine failures: a host crash, a disk, a zone, a network path. Build DR for every service whose loss would be material, including services that already have HA, because HA does not cover deletion, corruption, malicious encryption, a compromised administrator, a bad configuration push or loss of a whole region or provider. If you can only afford one for a given system, DR comes first: an outage of hours is survivable, permanent loss of the data or the identity plane often is not.

The broader planning context (business impact analysis, plan family, crisis management) is in the Business Continuity and Disaster Recovery Guide, and the design choice inside an HA cluster is in Active-Active vs Active-Passive. This page concentrates on the boundary between the two capabilities.

Side-by-side comparison

High availability: threat model, architecture and failure modes

Threat model: HA is designed for random, independent failures. It assumes the data is correct and the control plane is honest, and that the main risk is a part breaking. It does not model an adversary or an operator who issues valid but destructive commands.

Architecture in words: two or more instances sit behind a health-checked load balancer or a cluster manager. State lives in a replicated database or storage layer that acknowledges writes once a quorum or a peer has them. Instances are spread across fault domains, typically multiple availability zones in one region. AWS notes that a multi-AZ design in one region may already meet much of an organisation's risk mitigation needs because zones are separated by meaningful distance. The same administrators, automation accounts, keys and configuration management serve every node.

Failure modes HA does not cover:

• Logical corruption: an application bug, a bad migration script or a mistaken bulk delete is committed to the quorum and replicated in milliseconds.
• Destructive attack: ransomware or a wiper running with valid credentials encrypts or deletes data on every replica. MITRE ATT&CK tracks this as Data Encrypted for Impact (T1486) and Data Destruction (T1485); attackers also delete snapshots and shadow copies under Inhibit System Recovery (T1490).
• Control plane compromise: an attacker with cloud or hypervisor admin rights can disable or delete the HA pair as easily as one node.
• Correlated failure: a bad configuration push, an expired certificate or an identity provider outage takes every node down at once because they share the dependency.
• Split brain: both sides believe they are primary after a network partition and accept conflicting writes; reconciliation can require a restore anyway.

Controls that make HA safer: quorum or witness placement in a third fault domain, change control that stages configuration to one node first, separate credentials for the replication channel, and alerting on replication lag and failover events. None of these turn HA into recovery.

Disaster recovery: threat model, architecture and failure modes

Threat model: DR assumes the primary environment is unavailable or cannot be trusted, including the case where an adversary held administrator rights for some time before discovery. The goal is a known good state, not the most recent state.

Architecture in words: AWS describes four strategies in increasing cost and decreasing recovery time. Backup and restore keeps only backups and redeploys infrastructure from code at failover. Pilot light keeps core infrastructure and data replication running but application servers off. Warm standby runs a scaled-down, fully working copy. Multi-site active/active serves traffic from several regions. The same guidance is explicit that even active/active needs point-in-time backups, because recovery from corruption always involves some downtime and data loss. Beneath any of these sits a copy that the production administrators cannot alter: offline media, object lock, or a vault in a separate account with its own identities. See the Backup Security and Immutable Backup Guide and the Cloud Disaster Recovery Strategies guide for those patterns in depth.

Failure modes of DR:

• Backups reachable from production: CISA's ransomware guide warns that many ransomware variants try to find and delete or encrypt accessible backups, and tells organisations to keep offline, encrypted backups and test them.
• Infected restore point: restoring the most recent backup reinstates the attacker's persistence. Microsoft's Active Directory forest recovery guidance recommends a backup from a few days before the failure as a trade-off between lost changes and dangerous data.
• Missing rebuild assets: templates, images, runbooks and pipelines that only existed in the lost environment. CISA advises keeping golden images and offline copies of infrastructure-as-code templates.
• Untested sequencing: applications restored before the directory, database or key service they depend on, so nothing starts.
• Stale capacity assumptions: the DR region or provider cannot supply the compute, quota or licences needed at full scale.

Controls that make DR work: isolated copies with separate credentials, documented restore order, integrity checks before restore (NIST CSF 2.0 RC.RP-03), and drills that measure real time to recover.

RTO and RPO: where the two diverge

AWS defines recovery time objective (RTO) as the maximum acceptable delay between interruption and restoration of service, and recovery point objective (RPO) as the maximum acceptable time since the last data recovery point. Both should come from a business impact analysis and be weighed against cost. The mistake is to state one RTO and one RPO per system. A system has a different achievable pair for each failure class, and HA only improves some of them.

Report the worst realistic row to executives, not the best. Microsoft's Azure Well-Architected guidance says to use metrics from testing as the minimum time needed for recovery steps, and that production drills are the only way to verify RTO and RPO in real conditions.

Identity and secrets dependencies

Both HA and DR fail most often on dependencies that nobody listed. For identity, three questions matter.

• Can the recovery site authenticate without the primary? Azure guidance tells teams to duplicate account setups, role assignments and policies in the secondary region with the same security baseline. If the DR site federates to an IdP hosted only in the failed region, or to on-premises Active Directory that is also encrypted, nobody can sign in to run the recovery. See the IdP configuration backup and restore for Entra ID and Okta guide.
• Are the recovery credentials separate from production? NCSC advises protecting backup account credentials with multi-factor authentication, removing backup clients' credentials when storage is not in use and limiting which clients can modify backups. A backup console that trusts the production domain falls with it. See the Backup Identity Isolation Guide.
• Are keys and secrets recoverable independently? Encrypted backups are useless without the keys, and restored applications cannot start without database passwords, API keys and certificates. Azure guidance says to protect and replicate DR assets, including credentials, certificates and scripts, and to keep offline or printed copies for the worst case. Vault and key service resilience is covered in the Secrets Manager Resilience Guide; secrets inside the backups themselves are covered in the secrets in backups and snapshots guide.

After a compromise, restored non-human identities also carry the attacker's knowledge: a service account password or token captured before the incident still works on the restored copy. Plan to rotate machine credentials as part of DR, not as a later clean-up.

Decision guidance

Trade-offs to state openly: HA increases blast radius because every node trusts the same accounts. DR adds data loss equal to the recovery point and needs people to declare and run it. Active/active spending often buys HA across regions but still needs a separate backup tier, which AWS states explicitly. Cost should be weighed against the loss avoided: AWS guidance says a recovery strategy costing more than the loss it protects against generally should not be implemented unless a secondary driver such as regulation applies.

Worked scenario: an order platform with a regional cluster

A hypothetical retailer runs its order platform in one cloud region across three availability zones. The database is a managed cluster with synchronous replicas in each zone. Sign-in for staff and automation federates to the corporate IdP, which itself syncs from on-premises Active Directory. The team reports RTO under one minute and RPO of zero.

1. Zone failure: the cluster fails over in under a minute with no data loss. HA performs as designed.
2. Ransomware via a compromised automation account: the attacker deletes automated snapshots, then encrypts data through the application tier. Every replica holds encrypted rows within seconds. HA delivers an RPO of zero for the encrypted state.
3. Recovery attempt: backups were in the same account and are gone. Staff cannot sign in to the cloud console because on-premises Active Directory was also encrypted and the IdP depends on it. Break-glass accounts exist but were federated, so they fail too.
4. Redesign: the team adds a backup vault in a separate account with object lock and its own cloud-only administrators, daily cross-region copies, a pilot light environment built from offline infrastructure-as-code templates, two cloud-only emergency accounts, and a documented order: directory and IdP, key service and vault, database, application.
5. Proof: a quarterly exercise restores the database into the pilot light environment from the vault, rotates every service credential, and records real elapsed time. The first drill takes 31 hours; after automation the team reports 9 hours as the ransomware RTO, and keeps "under one minute" only for zone failure.

The extended outage at Jaguar Land Rover in 2025, where production stayed down for more than five weeks before a controlled, phased restart, shows why recovery planning must assume a multi-week rebuild is possible. See the Jaguar Land Rover Cyberattack 2025 page.

Implementation: a phased approach

1. Inventory and tier: list services with business owners and impact. Record for each the HA design, the DR strategy and its dependencies, including identity provider, directory, DNS, key service and secrets store.
2. Set objectives per failure class: agree RTO and RPO for hardware loss, region loss, deletion and destructive attack separately, using the table above.
3. Separate the recovery plane: move backups into a separate account, subscription or tenant with its own administrators and MFA, enable versioning and immutability, and remove production write access to the copies.
4. Close dependency gaps: create cloud-only emergency accounts, replicate role assignments to the DR site, escrow keys and recovery secrets offline, and keep templates and runbooks outside production. Use the Break-Glass Account Guide.
5. Test in rings: start with tabletop walkthroughs, then restores in non-production, then component restores in production, then a full exercise. Azure guidance warns that drills directly in production can cause severe failures, so prove procedures in non-production first. The Disaster Recovery Testing Guide covers test design.
6. Plan failback separately: Azure guidance treats failback as its own process; write it, including how data written in the DR site is reconciled.
7. Roll back safely: if a change to replication or backup policy causes errors, revert to the previous policy, but never delete existing immutable copies to free capacity during the rollback.

Detection and measurement

• Watch for attacks on recovery: alert on snapshot or backup deletion, retention or lock changes, backup job disablement, new administrators on the backup platform and replication being paused. These map to ATT&CK T1490.
• Watch for HA drift: replication lag, failover events, quorum loss and capacity headroom in the secondary.
• Measure:
  • Percentage of tier 1 services with an isolated, immutable copy.
  • Measured restore time versus stated RTO, per failure class, from the last drill.
  • Percentage of restores that passed integrity verification (RC.RP-03, RC.RP-05).
  • Age of the oldest untested DR runbook.
  • Number of DR dependencies on primary-site identity or key services (target zero).

Common failure patterns

• Reporting HA figures as recovery figures: "RPO zero" on a dashboard that only describes synchronous replication.
• Backups in the same blast radius: same account, same domain-joined backup server, same admin group.
• DR site that cannot authenticate: federation, MFA or Conditional Access depends on the failed site; emergency accounts are synchronised from on-premises.
• Restoring the attacker: picking the newest backup without checking for persistence, then restoring compromised service account credentials unchanged. The Cloudflare Thanksgiving Breach 2023 shows how credentials left unrotated after an earlier incident can be used weeks later.
• Keys lost with the site: encrypted backups whose key material only exists in the destroyed key service.
• Never failing back: a DR site that becomes permanent production without its own backups.

Framework mapping

Practitioner checklist

• State RTO and RPO per failure class, not one pair per system.
• Confirm every tier 1 service has a copy production administrators cannot alter or delete.
• Keep point-in-time backups even for active/active services.
• Make the DR site authenticate without the primary directory, IdP or key service.
• Hold two cloud-only emergency accounts and test them on a schedule.
• Store templates, images, runbooks and recovery keys outside production, with an offline copy.
• Verify integrity of backups before restore and of systems after restore.
• Rotate service account, API and certificate credentials as part of every compromise recovery.
• Run timed drills and report measured, not designed, recovery times.
• Alert on backup deletion, retention changes and replication pauses.

Standards and references

• NIST: SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CISA: #StopRansomware Guide
• NCSC: Offline backups in an online world
• AWS: Disaster recovery options in the cloud
• Microsoft: Azure Well-Architected, Develop a disaster recovery plan
• MITRE ATT&CK: Inhibit System Recovery

Related NHI Mgmt Group resources: Business Continuity and Disaster Recovery Guide, Active-Active vs Active-Passive, Cloud Region Outage Resilience, Identity Resilience vs ITDR and Ransomware Response and Recovery Guide.