Disaster Recovery Planning

A backup is not a plan. A plan names who decides, what returns first, where it runs, how people are told and how long each step takes, and it has been tested. The failures we see are ordinary: backups in the same building as the servers, restores nobody has timed, a single cloud region, no list of the accounts and licenses needed to rebuild, and a contact list that lives on the server that is down.

Ransomware changed the rules. Attackers look for the backups first, so a copy the attacker can reach is not a recovery option. Immutable and offline copies, and a clean room to restore into, are now part of the baseline. Our articles "Backups That Actually Restore" and "Ransomware Readiness and Incident Response" cover the principles in plain language.

We start with a business impact analysis. For every system and process we record who depends on it, what an hour of downtime costs, what a contract or regulation requires and what has to come back before anything else. The result is a ranked list that leadership signs off, not a technical inventory.

Next comes the recovery design. Each system gets a recovery time objective (RTO, how long it can be down) and a recovery point objective (RPO, how much data it can lose), and the systems are grouped into tiers. A tier-one system may need continuous replication to a second region or site. A tier-three system may need only a nightly immutable copy. Matching the design to the tier is how a plan stays affordable. The diagram on this page shows the relationship between RPO, RTO and the cost of each tier.

The architecture uses the copies and places that fit the tier. Backups follow the 3-2-1 rule with at least one immutable or offline copy that ransomware cannot alter. Critical systems run from an alternate site or a second cloud region, whether in a colocation cage, a private room or a cloud landing zone on AWS, Google Cloud, Microsoft Azure or Oracle Cloud. Our article "Hurricane-Proofing IT by Moving to the Cloud" is a worked example of moving out of a risk zone, and "Proving what you sent" shows how immutable email archives keep records unalterable.

The plan is only useful if people can follow it under stress. We write runbooks for each tier in the order of the recovery, with the commands, accounts and vendor contacts in them, and a communications plan that says who calls staff, clients, the insurer, counsel and regulators, and what each message says. A copy of both lives off the systems they describe, on paper where it makes sense.

Then we test. Tabletop exercises walk leadership through a scenario to test decisions and communication. Live failover tests move real systems to the alternate site or region and back, with the timings recorded and compared with the objectives. Every gap becomes a fix and a retest. The failover diagram on this page shows what a clean switchover looks like.

The Apocalypse IT Package is the offline layer of the plan. When an outage outlasts the cloud, whether from a regional disaster, a provider failure or an attack on a vendor, an on-premises kit with a local reference library, scanning, a private AI desk and local chat keeps core work running. Disaster recovery planning decides which of your processes need it and how it connects to your recovery tiers. See the Apocalypse IT Package for the details, and "Can the Internet Be Switched Off in the US?" for the reasoning.

The plan ends with a review cadence. It is reviewed after every significant change, such as a new system, a new site or a changed provider, and at least once a year, and the test schedule is part of it. The result is a plan that matches the environment you run today, with documentation current on the day we hand it over and every day after.

Directory, mail and databases need their own recovery designs. We write Active Directory forest recovery runbooks, build Exchange database copies in a second site and prove SQL Server point-in-time restores, as described on our Microsoft practice page.