Key takeaway
A restored server and a recent backup label do not settle both objectives. Record when the required workflow worked and how current its recovered state was.
Define the service the business needs back
A recovery report says the archive server was restored in sixty-five minutes. The business could not open its required inspection workflow for another fifteen minutes. Its latest backup completed shortly before the failure, but the recovered records represented an older consistent point. One green status cannot describe all of those events.
AWS’s recovery guidance distinguishes the Recovery Time Objective, the maximum acceptable delay to restoration of service, from the Recovery Point Objective concerning acceptable time after the last recovery point. It also stresses business impact and dependencies. Define the service and acceptance boundary before measuring a drill; an infrastructure milestone may be only one step toward that boundary.
A completed drill can pass one objective and fail the other
Hypothetical example: a company sets a ninety-minute RTO and fifteen-minute RPO for an authorized archive-retrieval workflow. A synthetic disruption begins at 14:00. The recovered consistent state represents 13:42. A backup job completed at 13:55, but its recorded recovery point is still 13:42. Infrastructure returns at 15:05 and the required authorized workflow passes its agreed validation at 15:20.
All times refer to one stated clock and timezone in this invented exercise. The business defined restoration as successful completion of that workflow, not merely a running server. The example demonstrates a test record; it does not claim a real VOID recovery test or authorize disruption of a production system.
| Scoped measurement | Observed illustrative result | Objective decision |
|---|---|---|
| Usable service restoration | 14:00 to 15:20 = 80 minutes | Passes the stated 90-minute RTO for this drill |
| Recovered-state age at disruption | 13:42 to 14:00 = 18 minutes | Fails the stated 15-minute RPO |
| Backup completion timestamp | 13:55 | Does not replace the recorded 13:42 recovery point |
| Infrastructure available | 15:05 | Intermediate milestone; workflow validation follows |
Explain the eighteen-minute window accurately
The RPO comparison concerns the recovered point, not the time somebody copied the last backup file. In the fictional drill, the eighteen-minute gap exceeds the target by three minutes. It does not establish that every event in that window is permanently lost, or even how many business records fall within it.
If replay logs or another approved source can advance the recovered state, verify the replay and resulting consistency before updating the recovered-point claim. The existence of a log is not the same as a successful restoration. Preserve the initial result and the later repair as distinct observations.
Map dependencies such as keys, identity services, schema dictionaries and linked objects. AWS’s guidance asks how recovery objectives relate to dependent workloads. A database can be present while an unavailable key or missing attachment prevents the required business workflow from functioning.
Exercise the path that the runbook actually requires
AWS recommends regular recovery testing to validate implementation and objectives, noting that assumptions about a secondary system’s capabilities and capacity can become stale. The useful test therefore checks the actual permitted recovery route, relevant configuration and required workload, rather than an easier administrator-only substitute.
For this example, the drill owner records the input backup/version, represented recovery point, disruption start, infrastructure milestone, validation cases and completion time. The technical owner assigns the RPO failure for correction and a bounded retest. The passed RTO result remains scoped to the tested workflow and conditions.
Plan real exercises through the organization’s approved change and incident procedures. This article proposes evidence to retain; it does not instruct an operator to create an outage or restore restricted data into an unapproved environment. Synthetic workflow records can support preparation without exposing a company archive.
Report the two decisions without averaging them
The completed fictional result is RTO passed, RPO failed, with an explicit recovered-state gap to investigate. Reporting a combined recovery pass would hide the failed objective. A later test should name the repaired configuration and show the new observations rather than overwrite the earlier failure.
Use readiness to retain the unresolved recovery work before promising a continuing delivery service. A one-time licensing discussion does not require the owner to offer an uptime guarantee. VOID’s initial referral does not host or back up the company’s records; any continuing service commitment belongs in a separate technical and commercial decision.