Service planning and recovery exercises. Numerical scenarios below are illustrative, not test results or service guarantees.
Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.Ask two different questions
Use RPO to choose how much history the design must preserve and RTO to decide how much of the recovery path must be ready in advance. More frequent backups can improve the recovery-point gap without making a slow rebuild any faster. Conversely, a warm standby can reduce recovery time while still exposing recent changes to loss if the last usable data copy is old. Improving one target is not evidence that the other improved.
For RPO, ask how much work the business can reconstruct if recent data disappears. For RTO, ask how long the process can remain unavailable before the impact becomes unacceptable. A payroll system and an internal reference wiki may need very different targets.
Record the business event from which the recovery clock starts and what counts as restored. If RTO is measured only from when an engineer clicks Restore, hours of detection and decision-making can disappear from the report. Agree the convention with the service owner.
Work through a concrete scenario
Suppose an incident occurs at 14:00 and the newest usable recovery point is 12:30. The recovery-point gap is 90 minutes. A 60-minute RPO has not been met, even if the job schedule says hourly: failed jobs, replication lag or an unusable latest copy can widen the actual gap.
If the agreed RTO is four hours, reserve time for access, dependency recovery, data restoration, checks and business acceptance. A two-hour data transfer does not prove a two-hour service recovery. The critical path may include identity, DNS, keys or a supplier response.
One incident, two different clocks
- 12:30
Newest usable recovery point.
- 14:00
Hypothetical incident. The recovery-point gap is 90 minutes.
- 18:00
Recovery deadline if a four-hour RTO starts at 14:00.
The RTO includes the agreed service recovery and acceptance work. 18:00 is a target deadline, not an observed completion time.
Translate objectives into a design
Estimate change rate and recovery data volume. Ask the backup supplier which workloads support the required consistency and frequency. Measure available restore throughput over the path you would actually use during an outage. Include cloud retrieval and egress constraints where applicable.
If the budget or platform cannot meet the target, present the gap explicitly. Options include changing architecture, reducing the recovery scope, improving dependency readiness or negotiating a different business target. Do not silently redefine success after a failed exercise.
Report targets separately from observed results
Keep three fields: approved target, design estimate and measured exercise outcome. Record the recovery point used, exercise start and accepted completion. Repeat under materially different data volumes or infrastructure changes.
An exercise on a warm spare may be faster than rebuilding after a site loss. State those assumptions beside the result. Recovery objectives are planning commitments; they do not remove the need to test failure modes or to preserve several recoverable points.
Calculate the critical path, not just transfer time
In a worked planning example, 20 minutes for incident decisions, 40 for prerequisites, 120 for restoring data and 30 for acceptance total 210 minutes, or 3 hours 30 minutes, when the steps run sequentially. Against a four-hour RTO, the plan has only 30 minutes of margin. These are stated scenario inputs, not an observed recovery.
If independent steps can run in parallel, use their longest dependency path rather than summing every task. An untested parallel plan is still an estimate. Report the 90-minute recovery-point gap in the earlier example separately: it misses the one-hour RPO by 30 minutes even if the service returns within its RTO.