Dependency map and recovery order
A service does not come up without the identity, network, database and integration layers it depends on. The map makes that chain visible and the recovery order is derived from it. An order is not considered valid until a rehearsal confirms it.
- Identity and network layers gate most chains from the start
- External service dependencies belong on the map too
- Order changes are updated after each rehearsal
- The map is kept live through change management
Choosing the replication technique
Synchronous replication minimizes data loss but imposes distance and latency limits; asynchronous replication gives flexibility but leaves a loss window. The choice follows the system's recovery objective and the real measured latency between the two locations.
- Latency is taken from the field, not from a datasheet
- The loss window is expressed to the business as a number
- Database and file layers are assessed separately
- The failback path is designed from the outset
Failover and failback
Declaring failover is a business decision, not a technical one; who declares it and at what threshold is written in advance. Failback is where most plans stop short: how and when the data produced at the secondary site returns to the primary.
- Decision threshold and decision owner are written down
- The communication chain is defined before failover
- The failback window is planned separately
- Data created at the secondary site is not lost
Rehearsal and evidence
Until it is rehearsed, a plan is an assumption. Rehearsals are staged from tabletop scenarios through to real failover; each round compares measured duration against the objective and updates the plan.
- Staged rehearsal: from tabletop to real failover
- Measured duration is recorded every round
- Findings become remediation items
- Evidence is retained in an audit-ready form