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

Three plan types in NIST SP 800-34, and where backup fits

Backup keeps copies of data; disaster recovery brings working systems back, usually at an alternate site, within a recovery time the business has set. NIST Special Publication 800-34 Revision 1 separates three plan types that most organisations treat as one.

NIST SP 800-34 Rev. 1, sections 2.2 and 3.4.2 and the glossary. In NIST’s structure, backup is a component of a plan.

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 cost to implement”, while 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 and multi-site active/active. Backup and restore is the first: AWS calls it “a suitable approach for mitigating against data loss or corruption” and adds that it can also mitigate a regional disaster when the data is replicated to other AWS Regions. Copies elsewhere keep the data; the recovery time still depends on rebuilding the environment and restoring into it. The same page states: “How often you run your backup will determine your achievable recovery point.” Backup frequency sets the RPO and says nothing about the 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. A working IT environment also needs what makes the data usable: identity, keys, secrets, the management plane and the order in which systems may start. Each item below comes from the vendor’s own documentation.

Identity. The vendor’s 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 of a physical DC left unplugged, running two restores at once on it: a nonauthoritative restore of the directory database and an authoritative restore of SYSVOL. The remaining steps are 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”. The DNS configuration is reverted by hand, and the name records of every controller that was not recovered are deleted. 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: with the Recycle Bin enabled, its lifetime is “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 its 2008 and 2008 R2 server releases 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. Cloud key services have their own version of this: check whether yours can back up a whole vault in one operation, and whether a backup can be restored outside the subscription and region it came from, because a plan whose purpose is to leave that region cannot use backups that are tied to it.

The management plane. A vCenter Server file-based backup holds the appliance’s configuration, inventory and historical data, but restoring it means redeploying. 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.” Part of the management plane therefore has to be running before the management plane can be restored. We found no Broadcom procedure for losing vCenter and all its ESXi hosts together.

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 for the entities it covers, 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 we found no vendor document that states it clearly, so the closest reference is item (g), “required resources, including backups and redundancies”.

How long a full restore takes: the arithmetic

Recovery time is set by three multipliers no dashboard shows: bytes divided by throughput, the number of systems, and dependency depth. AWS publishes the same sum for an 82 TB transfer; the table below is our own division.

Our arithmetic: 82,000,000 MB divided by the sustained rate, in decimal units. AWS’s Snowball Edge documentation prints the same division for an 82 TB device; its 400, 200 and 100 MB/s rows match ours, its 800, 60, 30 and 10 MB/s rows do not. A transfer calculation, not a restore benchmark for any backup product.

At 100 MB/s, a respectable sustained rate over a 1 GbE-class path, 82 TB takes 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. As an example, 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. 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 883 sites of 775 customers. Archive tiers then add a wait 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, plan on the retrieval alone taking up to 12 hours for standard and up to 48 hours for bulk before the restore can start.

A restored system does not necessarily run at full performance straight away. 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”. Instant recovery, offered by Veeam and other backup products, runs a workload directly from the backup file at reduced performance until it is migrated onto production storage.

With our disaster recovery service, your systems come up from replicas at a recovery site in Tier III EU data centres. Tell us which systems must run first and how long each can be down; we reply within one business day.

Ransomware makes the backup a target

Everything above assumes that the backup itself is left untouched. Incident casework shows most clearly that attackers go after the backup. M-Trends 2026, published by Mandiant and Google Cloud in March 2026 from over 500,000 hours of investigations in 2025, says of ransomware operators that “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 but measure different things: Sophos asks whether any data came back, Veeam how much. Read together, almost every respondent recovered some data, and fewer than one in three recovered all of it. In that Sophos 2024 dataset the organisations whose backups were compromised were almost twice as likely to pay, 67 per cent against 36, and their median recovery cost was eight times higher.

The extended 3-2-1-1-0 rule addresses this. 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 asks for restore testing, so a backup set that has never been restored does not meet the rule. 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 remaining risk, with documented limits. In Amazon S3 Object Lock, governance mode can be bypassed by any identity holding the bypass permission, so it does not hold against a compromised account that has that permission; 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.” Three further limits are our reasoning rather than vendor text: immutability preserves whatever was written, including systems already backdoored during a 14-day dwell and any data encrypted before the job ran; the lock 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. Immutability accounts for one of the five digits of 3-2-1-1-0.

Recovery testing in NIS2 and Implementing Regulation (EU) 2024/2690

The most detailed EU text is the implementing regulation, not the directive. Commission Implementing Regulation (EU) 2024/2690 applies only to the entities listed in its Article 1 (DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers); every other organisation in scope of NIS2 is bound by the national law that transposes Article 21 of Directive (EU) 2022/2555, and which text applies to you is for your legal department to confirm. The directive reaches companies through national law, and national transposition may differ in detail: in Austria the NISG 2026 (BGBl. I Nr. 94/2025) has applied since 1 October 2026, in Germany the NIS-2 Implementation and Cybersecurity Strengthening Act (BGBl. 2025 I Nr. 301) since 6 December 2025. As a technical checklist the regulation is still the clearest text we found; its point 4.1.1 ties the plan to “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”. Of these three, only the copies appear on a backup 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 work as a checklist: 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 differ. Point 4.1.4 says plans “shall be tested, reviewed and, where appropriate, updated at planned intervals and following significant incidents or significant changes”. How often to test under NIS2, and what ENISA’s guidance adds, is covered in our guide to NIS2 backup and business continuity requirements.

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 offers restore job duration monitoring as a feature, and restore duration is evidence about RTO, which 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 check appears on a backup report; both belong to a cyber resilience design.

Our disaster recovery service runs scheduled test restores in an isolated environment, with a report on what came up, how fast and what to fix. Write to us with the restore times you have measured so far; the first call is free of charge.

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 testimony to the US Senate. 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”. The infrastructure, not the data, set the duration: “reliance on legacy infrastructure is the primary contributor to the length of time” the recovery would take.

GitLab’s backups failed without anyone noticing. 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 new user accounts were lost for good.

Atlassian had excellent backups and a slow recovery. Its review states the databases allowed recovery to “any particular ‘Point in Time’…within the backup retention period (30 days)”. The data was available, but the orchestration to restore it 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 is a case in which restoring was not the way back. In testimony to the US Senate Committee on Finance on 1 May 2024, the chief executive of UnitedHealth stated that the compromised portal “did not have multi-factor authentication” and that “Ransomware was deployed nine days later”. According to the testimony, the team began “rebuilding Change Healthcare’s technology infrastructure from the ground up”. In our reading, after a compromise of that depth the restore target is itself untrusted. The testimony gives no downtime figure and does not discuss backups.

For Norsk Hydro and Maersk, recovery had no single end date. Hydro’s own first-quarter 2019 report puts the impact of the March attack at NOK 300 to 350 million in that quarter and estimates “around NOK 200 to 250 million” for the second. Maersk’s own disclosures put the effect of NotPetya at USD 250 to 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

For the entities the regulation covers, the regulator has already written the outline, and it works as a checklist for anyone. 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 recovery documents against that list and against six things it 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.

What we do

Under our disaster recovery service, our engineering partner Vixen.UNO works with you to define the critical systems, the target RPO and RTO for each tier and the disaster scenarios, and the output is a continuity plan rather than just copies. Replication runs on Veeam to a recovery site in Baltneta’s Tier III data centres in Lithuania, with scheduled test restores. Eurokommerz holds the contract and supplies the hardware.

FAQ