Measure recovery from a declared incident boundary
What This Concept Is
Recovery time measures elapsed time to a specified usable outcome. Recovery point measures the data boundary restored. Both require explicit clocks, scope and validation rather than a backup-job success badge.
Why It Matters Here
The original timed restore lab must establish whether the capstone can serve correct data after loss.
Concrete Example
Teaching case: failure begins 12:00; isolated service passes functional/data checks at 12:18. Measured recovery time is 18 minutes under that start boundary. Last recoverable committed record is 11:55, so the time gap to failure is five minutes. Also count missing committed records; time alone can hide a burst of writes. These are fictional calibration numbers, not measurements.
Common Confusion / Misconception
Download time is not full recovery time. A restored process that starts but cannot authorize users or read records is not recovered. A successful backup is not proof of a usable restore.
How To Use It
Declare target RTO/RPO, incident start, backup selection, key/config dependencies and verification checks. Restore into an isolated environment, retain valid records and checksums/counts, then test the user workflow.
Check Yourself
When does the timer stop? Which committed writes are missing? Can the keys needed for restore be recovered?
Mini Drill or Application
Run the original restore with a known synthetic write sequence before/after the backup. Report time and record loss, including unmet targets.
Read This Only If Stuck
Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.