Backup is not disaster recovery: what a green dashboard does not prove

Three plans, and backup is not one of them

NIST Special Publication 800-34 Revision 1 separates three plan types that most estates treat as one thing.

NIST SP 800-34 Rev. 1, sections 2.2 and 3.4.2. The last row is the story: the standards treat backup as a component of a plan, not as a capability.

Section 3.2.1 defines the numbers: RTO is “the maximum amount of time that a system resource can remain unavailable” before the impact is unacceptable, RPO the point “to which mission/business process data can be recovered”. Our guide on choosing RPO and RTO covers how to set them. NIST also places backup on the cost curve: “The shorter the RTO, the more expensive the recovery solutions… whereas a low-impact system with a longer RTO would be able to implement a less costly simple tape backup.”

AWS divides the same ground into four strategies of increasing capability: backup and restore, pilot light, warm standby, multi-site active/active. Backup and restore is the first, scoped as “mitigating against data loss or corruption”. Not site loss. And one sentence on that page settles the question: “How often you run your backup will determine your achievable recovery point.” Backup frequency sets RPO and says nothing about RTO. ISO 22301:2019 covers the same ground, but its clause text is paywalled, so the definitions here are NIST ones.

What a backup does not restore

A backup job captures data. An estate is data plus the machinery that makes data usable: identity, keys, secrets, the management plane, and the order things may start in. Each item below comes from the vendor’s own documentation.

Identity. The Active Directory forest recovery guide is a five-step procedure and a backup gives you part of step three. You restore “one writeable DC from backup” per domain, with “the network cable…not attached”, running two restores at once on it: “a nonauthoritative restore of AD DS and an authoritative restore of SYSVOL”. The rest is manual. Seize the domain-wide and forest-wide operations master roles, clean up the metadata of every controller you are not restoring, raise the available RID pool by 100,000, and reset the krbtgt password twice, because “the krbtgt password history is two passwords” and one reset leaves a forged ticket valid.

The cleanup step lists what the backup never held. Outbound trusts: “these external trust relationships aren’t restored automatically from backups”. DNS and WINS records, reconfigured by hand. Everything after the restore point, since objects added and “updates (such as password changes)…are lost”. And two details contradict most retention policies: the guide recommends restoring from “backups that were taken a few days before…the failure”, and the backup itself expires, its lifetime being “the deletedObjectLifetime value or the tombstoneLifetime value, whichever is less”.

Keys and secrets. The same vendor’s PKI team documented in April 2010 that on Windows Server 2008 and 2008 R2 a system state backup did not capture the certification authority’s private key at all. Take the principle rather than the release: the key needs a deliberate, separately verified backup, and an authority restored without it is a new authority. Azure Key Vault has its own version of this. It “doesn’t currently provide a way to back up an entire key vault in a single operation”, and the blob must be restored into “the same Azure subscription and Azure geography”, so a plan whose purpose is to leave that geography cannot use those backups.

The management plane. A vCenter Server file-based backup holds the appliance’s configuration, inventory and historical data, but the restore is not a restore. Broadcom describes “deploying a new vCenter Server appliance and copying the data from the file-based backup” to it, which needs a working ESXi host to deploy onto first, and where vCenter High Availability was in use the restore comes back without it: “You must reconstruct the cluster.” The management plane has to be partly alive to restore the management plane. Broadcom publishes no procedure for losing vCenter and all its ESXi hosts together, and we will not invent one.

The order. NIST SP 800-34 section 3.2.3 notes that “priority levels can be established for sequencing recovery activities”; Implementing Regulation (EU) 2024/2690 makes it mandatory, item (e) of the required plan contents being literally “order of recovery for operations”. The order decides whether anything can start: identity and name resolution precede the databases that authenticate against them, and the management plane precedes the machines it schedules. Network configuration and licence servers belong on the same list, though no vendor document states it crisply, so the honest hook is item (g), “required resources, including backups and redundancies”.

The arithmetic of restore time

Recovery time is set by three multipliers no dashboard shows: bytes divided by throughput, the number of systems, and dependency depth. AWS has done the first sum in public for an 82 TB transfer.

AWS Snow Family documentation; the full table also lists 450, 300, 277 and 30 MB/s. It is a transfer table for Snow devices, not a restore benchmark for any backup product: the right arithmetic, not a performance claim.

Read the 100 MB/s row twice: a respectable sustained rate over a 1 GbE-class path turns 82 TB into 9.49 days before a single machine boots. Scaling that ratio ourselves, 500 TB at a sustained 400 MB/s is about 14.5 days of pure data movement; that is our arithmetic, not an AWS figure. Put an estate against it: three hundred virtual machines whose disks average 273 GB come to about 82 TB, so 2.37 days at 400 MB/s and 9.49 at 100, before anyone logs in. And the rate is set by the slowest element in the path: GitLab’s 2017 post-mortem records a database copy that “took around 18 hours” because the source was throttled at around 60 Mbps, about 7.5 MB/s, slower than the bottom row above.

The second multiplier is the count, which Atlassian measured live in April 2022: approximately 48 hours to restore a batch of sites, and approximately 12 hours for one site after it built new tooling mid-incident, across 775 sites. Archive tiers then add a floor before the first byte moves. Amazon S3 Glacier Flexible Retrieval finishes standard retrievals typically within 3 to 5 hours and bulk within 5 to 12; Deep Archive standard retrievals typically finish within 12 hours and bulk within 48, and expedited retrieval is not offered for Deep Archive at all. If the only clean copy is in Deep Archive, no RTO below 12 hours is achievable.

Restored is also not the same as working properly. AWS documents that a volume created from a snapshot “might experience increased I/O latency and decreased performance” while it initialises, reaching full performance “only once all storage blocks have been downloaded and written”. Every major backup product concedes the point with instant recovery, which runs a workload from the deduplicated backup file, at reduced performance, until it is migrated onto production storage.

Ransomware makes the backup a target

Everything above assumes the backup is a bystander. The strongest evidence that it is not is casework, not a survey. M-Trends 2026, published by Mandiant and Google Cloud in March 2026 from over 500,000 hours of investigations in 2025: “Ransomware groups are no longer just encrypting data; they are actively destroying the ability to recover.” It observed operators, including the crews behind Akira and Qilin, targeting “backup infrastructure, identity services, and virtualization management planes” and deleting backup objects from cloud storage: the three things a green dashboard does not cover. Median dwell time was 14 days, up from 11.

Survey rows are what respondents said about their own experience, not measurements.

The Sophos and Veeam rows look contradictory and are not: Sophos asks whether any data came back, Veeam how much. Almost everyone recovers something; almost nobody recovers everything. In that Sophos 2024 dataset the organisations whose backups were compromised were twice as likely to pay, 67 per cent against 36, and their median recovery cost was eight times higher.

Which is what the extended rule is for. Veeam states 3-2-1 as three copies, two types of media and at least one off-site, attributing it only to “the early 2000s” without naming an author, and extends it to 3-2-1-1-0: one copy “stored in an immutable or air-gapped location” and “zero backup errors through automated integrity checks and regular restore testing”. The last digit is a testing requirement, not a storage one, so 3-2-1-1-0 without restore testing is 3-2-1-1. The UK National Cyber Security Centre gave the off-site reason in 2019: ransomware has encrypted “the connected USB and network storage drives holding data backups”, hence “never having all backups connected” at once.

Immutability covers part of the rest, with documented limits. In Amazon S3 Object Lock, governance mode is bypassable by any identity holding the bypass permission, so it fails in the scenario it was bought for; compliance mode is absolute except that “The only way to delete an object…before its retention date expires is to delete the associated AWS account.” The rest is reasoning, not vendor text: immutability preserves whatever was written, including data already encrypted during a 14-day dwell, it expires, and it says nothing about restore throughput or whether there is anywhere to restore into. The mechanics are in our article on what immutable backup protects against. It is one digit of five, and the other four are not storage settings.

Proven recovery: what the texts actually require

The binding EU text is the implementing regulation, not the directive. Commission Implementing Regulation (EU) 2024/2690 states at point 4.1.1 that it applies “For the purpose of Article 21(2), point (c) of Directive (EU) 2022/2555”. Point 4.2.6 is the proven-recovery clause: entities “shall carry out regular testing of the recovery of backup copies and redundancies to ensure that, in recovery conditions, they can be relied upon and cover the copies, processes and knowledge to perform an effective recovery”. Three nouns, and only the first is on a dashboard. Processes mean a runbook someone other than its author can execute; knowledge means people, whom point 4.2.1 names alongside “facilities, network and information systems”.

The backup requirements at 4.2.2 read like a checklist written after an incident: recovery times; copies complete and accurate “including configuration data”; storage “not in the same network as the system” and “at sufficient distance to escape any damage from a disaster at the main site”; access controls; restoring data; retention periods. Item (b) names configuration data outright, and item (c) is the off-site half of 3-2-1 written into EU law. Point 4.2.3 adds regular integrity checks.

On frequency the texts disagree, and we will not pick one. Point 4.1.4 says plans “shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes”. The word annually appears elsewhere in that annex, at points 1.1.2, 2.1.4 and 10.1.3, but not in the business continuity section. ENISA’s Technical Implementation Guidance version 1.0 of June 2025 reads “at planned intervals and at least annually” in the corresponding passage. We could not reconcile the two. The regulation binds and the guidance advises, so quote 4.1.4 in the policy and expect an assessor holding the ENISA document to look for a yearly cadence. Anyone who says flatly that NIS2 requires annual disaster recovery testing is quoting neither.

NIST SP 800-84 is strict about the vocabulary: a tabletop exercise is discussion-based, a functional exercise has personnel “performing their duties in a simulated operational environment”, and “the term ‘test’ is reserved for testing systems or system components”, not for exercising plans. AWS puts it operationally in requirement REL13: “Exercise the recovery path to verify that you can accomplish the recovery in the specified time to the specified state”, because “the only error recovery that works is the path you test frequently”. AWS Backup sells the evidence as a feature, monitoring restore job duration, which is RTO evidence where backup success is not. After an intrusion NIST SP 800-61 Revision 3 adds two checks: restoration assets “for indicators of compromise, file corruption, and other integrity issues before use”, and restored assets, remediating “root causes before production use”. Neither appears on a backup report, which is the difference between a backup estate and a cyber resilience design.

Where the backups existed and the recovery still failed

Every case below comes from the organisation’s own published account or its chief executive’s sworn testimony. No press coverage is used.

The British Library’s own review of March 2024 confirms that “viable sources of backups had been identified that were unaffected”, then states this article’s thesis from the victim’s side: “we are hampered temporarily by the lack of viable infrastructure on which to restore it”. The attacker had gone for the substrate deliberately, with a methodology including “destruction of servers to inhibit system recovery”, and a few key systems “cannot be brought back in the form that they existed in before the attack”. What set the clock was not the data: “reliance on legacy infrastructure is the primary contributor to the length of time” the recovery would take.

GitLab is the case to read if your dashboard is green. Its post-mortem of the 31 January 2017 outage lists five backup and replication mechanisms, none of which produced a usable recent backup: “The S3 bucket was empty, and there was no recent backup to be found anywhere.” The cause was a version mismatch, “pg_dump 9.2, while our database is running PostgreSQL 9.6”, and nobody knew because the cron failure notifications were emailed and “DMARC was not enabled” for them, so they were rejected. Roughly 5,000 projects, 5,000 comments and 700 user accounts were lost for good.

Atlassian is the case to read if your backups are genuinely excellent. Its review states the databases allowed recovery to “any particular ‘Point in Time’…within the backup retention period (30 days)”. The data was there; the orchestration was not: “we did not have the ability to select a large set of customer sites and restore all of their inter-connected products”. 775 customers were affected over as much as 14 days, and the review says it outright: “During this incident, we missed our RTO but met our RPO.”

Change Healthcare answers “why not just restore?”. In testimony to the US Senate Committee on Finance on 1 May 2024, the chief executive of UnitedHealth Group stated that the compromised portal “did not have multi-factor authentication” and that “Ransomware was deployed nine days later”. The recovery was not a restore: the team began “rebuilding Change Healthcare’s technology infrastructure from the ground up”, because after a domain-wide compromise the restore target is itself untrusted. The testimony gives no downtime figure and does not discuss backups.

Norsk Hydro and Maersk show that recovered is not a date. Hydro’s own first-quarter 2019 report puts the impact of the March attack at NOK 300-350 million in that quarter and estimates “around NOK 200-250 million” for the second. Maersk’s own disclosures put the effect of NotPetya at USD 250-300 million, covering “loss of revenue, IT restoration costs and extraordinary costs”. The widely quoted operational figures for that rebuild come from remarks by its chairman at a panel in January 2018, appear in no Maersk publication we could find, and are not printed here.

What a recovery plan contains that a backup policy does not

The regulator has already written the outline. Implementing Regulation (EU) 2024/2690 point 4.1.2 lists what the plan shall include:

1. purpose, scope and audience
2. roles and responsibilities
3. key contacts and internal and external communication channels
4. conditions for plan activation and deactivation
5. order of recovery for operations
6. recovery plans for specific operations, including recovery objectives
7. required resources, including backups and redundancies
8. restoring and resuming activities from temporary measures

Check your own documents against that, and against six things the list assumes. A dated, measured time to service for your top business processes, produced by an exercise rather than a backup success rate. The place you restore into, named: which hosts, on which network, and who confirms it is clean before anything starts. An identity runbook with the forest recovery steps written out and the people allowed to execute them. Custody of the certification authority private key and of the secrets the backup does not hold. A redeployment plan for the hypervisor management plane, because the vendor documents a redeployment rather than a restore. And the dependency order, with what waits for what.

If your plan holds all of that and has been exercised end to end, the green dashboard is a useful signal about one of your two numbers. If it does not, it is telling you that your data exists, which was never the question. Eurokommerz designs and runs backup and recovery estates across the EU with our engineering partner Vixen.UNO, and the deliverable of our disaster recovery work is a measured restore time per business process with the order written down, not a report that every job succeeded.

FAQ