Glossary
Disaster recovery orchestration
Disaster recovery orchestration is software that runs the technical steps of a recovery plan as one automated workflow. It starts systems in dependency order, checks each stage before moving on, redirects users to the recovered services and can run the same sequence as a non-disruptive test.
From runbook to workflow
Recovery runbooks are long and are often followed at night, under pressure, by people who did not write them. Steps get skipped or run out of order. Orchestration encodes the restore sequence of the disaster recovery plan so that it executes instead of being read. People keep the decisions: declaring the disaster, approving the switch and accepting the result.
What a workflow does, in order
- Selects the recovery point for each system.
- Brings up network and connectivity in the recovery environment.
- Starts identity, directory and DNS services.
- Starts databases and storage-dependent services, each waiting for a health check on the one before.
- Starts applications, running independent ones in parallel.
- Redirects users and external connections to the recovered endpoints.
- Records the duration of every step in a report.
Parallel steps account for most of the time saved. The timed report doubles as audit evidence and as a measured baseline for the recovery time target.
Choosing the recovery point is a step, not a default
Many tools default to the newest replica or backup. After a ransomware attack, the newest copy is usually the worst choice, because intruders are often inside for days before encryption begins and replication has copied the damage. A workflow that restores the latest copy restores the attack, quickly and in the right order. Its first step therefore has to pick a copy shown to be clean, such as an immutable backup taken before the intrusion, using results from scanning or restore testing. Recovering into an isolated network first, covered under clean room recovery, lets that copy be checked before users reach it.
Why workflows drift
A workflow is accurate on the day it is built. New application dependencies, changed addresses and expired credentials make it wrong without anyone noticing, and the error only shows when it runs. Scheduled test runs in isolated networks are the control, and they are where orchestration pays back most: a rehearsal that once took a weekend of staff time becomes a routine job, so disaster recovery testing can happen far more often. The orchestration tool, its credentials and its configuration also need to survive the event they recover from, so they cannot live only in the primary site.