Maersk rebuilt roughly 4,000 servers and 45,000 PCs in about ten days after NotPetya in 2017, and recovered its directory only because one data centre had been offline during the attack. What does this say about DR design?

The case, as publicly reported

In June 2017 the NotPetya malware — destructive rather than financially motivated — propagated through Maersk's network, encrypting endpoints and servers within minutes. Losses were reported at roughly $250–300 million.

The widely-reported recovery detail: Active Directory was destroyed across the estate, and without it the rest could not be rebuilt. A domain controller in Ghana survived because a power outage had taken it offline before the malware arrived, and it was physically transported to provide the only clean copy.

What it says about DR design

1. Most DR plans assume the wrong disaster. They are built for a site failure — one location gone, another intact. NotPetya was a correlated, simultaneous, estate-wide destruction event that propagated through the network faster than anyone could react. Warm standbys connected to the same network were encrypted too.

The design consequence: at least one recovery copy must be offline or immutable — air-gapped, or in a store with object-lock where the production identity cannot delete it. "Replicated to another region" is not a defence against something that replicates with you.

2. Identity is the recovery keystone. Almost nothing can be rebuilt without the directory: not authentication, not the backup system's own login, not the tooling. Yet AD is rarely treated as tier-zero infrastructure with its own isolated recovery path. The question worth asking of any estate is: if the directory were destroyed, what is the documented sequence to reconstitute it, and has that sequence ever been performed?

3. Recovery order is a design artefact. Rebuilding 45,000 endpoints is not a single task; it is a dependency graph — identity, then DNS and networking, then core platforms, then applications, then endpoints. Organisations that recover quickly have that sequence written and rehearsed.

4. RTO is fiction until measured at scale. A documented four-hour RTO for a single application says nothing about recovering an estate. The realistic number for a full rebuild is days, and it should be stated honestly so the business can plan around it rather than be surprised by it.

The uncomfortable lesson

The survival of one domain controller was luck, and the organisation was candid about that. A recovery plan that succeeds because of a coincidental power cut is not a plan.

What a strong answer adds

Distinguishing backup from recovery capability. Maersk had backups. What determined the ten days was tooling, sequencing, network rebuild and the human logistics of a global rebuild — none of which appear on a backup dashboard. The test is not "do we have backups", it is "have we restored the estate, timed it, and written down what went wrong".