Disaster recovery (DR) is a plan for continuing operations when a disruptive event takes the primary environment out of service. The alternate environment is usually in a different geographic location, protecting against fire, flood, or theft. Power, network, and hardware failures are more likely reasons to use the plan. If an outage would significantly harm clients, plan for when one happens—not just whether it might happen. section 8.4
Start with the downtime clients can tolerate: minutes, hours, or days. A near-immediate switch can be costly and difficult, particularly for older systems or databases not designed to run across two locations. Data must travel between sites, and users must be directed to the active one. Present the cost and consequences of each realistic option so technology and business leadership can agree on an acceptable target. section 8.4.1
Decide what must work during recovery, not just where it will run:
- Identify services that can remain available in a reduced or read-only mode; consider whether logging, reporting, or scheduled administration can pause. section 8.4.2
- For services that must continue in full, determine how the alternate environment will handle work interrupted during the switch, including possible duplicate or lost actions. section 8.4.2
- Choose whether the alternate environment should be ready to take over or started when needed, accounting for the resulting cost and recovery work. section 8.4.1 section 8.4.4
A useful partial-service choice
A social service might let people read existing posts while temporarily disabling publication. An ecommerce site might keep browsing and carts available while checkout is unavailable. Either choice needs an explicit decision about what clients can tolerate; a partial service is not automatically an acceptable one. section 8.4.2
Write down when to switch. A destroyed site may make the decision obvious; intermittent power or a provider promising that a network outage will end “very soon” does not. Set triggers based on affected services and outage duration. Keep contacts, network details, and passwords securely accessible; document startup and data-refresh tasks, address and DNS changes, responsible people, and validation tests. Include a reverse plan if operations will move back. DNS propagation time belongs in the timeline. section 8.4.4
Cloud infrastructure can serve as an on-demand alternate environment for a non-cloud-native application and make small-scale configuration tests more affordable. Running in the cloud alone does not establish readiness. A strategy needs a documented way to fail forward or back—and a recovery plan practiced within the last 12 months. Ask: could the team execute the switch, verify service, and return operations using the plan it has today? section 8.4.5 section 8.4 section 8.10
