The morning after a database crash, two executives ask the IT director two different questions. The chief operating officer wants to know how long until the company can take orders again. The chief financial officer wants to know how many of yesterday's orders are gone for good. Both are fair questions, and they have different answers, measured by different metrics.
On the CompTIA Security+ SY0-801 exam, recovery metrics sit under objective 3.4, which expects you to explain why resilience and recovery matter in security architecture. This lesson covers the two business targets, RTO and RPO, and the two operational measurements, MTTR and MTBF, then shows how MTBF and MTTR combine into availability. RTO and RPO are the pair most often confused, so telling them apart gets a section of its own.
Two recovery metrics are targets and two are measurements
Recovery time objective (RTO) and recovery point objective (RPO) are objectives. The business sets them in advance, system by system, and IT designs the recovery to meet them. They come from the business impact analysis, which is covered in the risk management section, and every RTO has to fit inside the maximum tolerable downtime, the longest outage the business could survive.
Mean time to repair (MTTR) and mean time between failures (MTBF) are measurements. They come from operating history or manufacturer data and describe how often things break and how quickly they're fixed. They tell you whether the targets are realistic.
The two objectives sit on either side of the moment of failure:
last good copy of data failure service restored
|<-------- RPO -------->|<--------- RTO --------->|
data written in this window users can't work in
is lost this window
Everything to the left of the failure is about data. Everything to the right is about time.
RTO is the deadline for having a system working again after a disruption
RTO is the maximum time allowed from a disruption to the point where the service is working again. The clock includes everything: noticing the problem, deciding to invoke the plan, restoring systems and checking that they work. A restore job that takes two hours doesn't meet a two-hour RTO if it takes another hour to detect the failure and decide to act.
RTO drives the recovery design. The shorter the target, the more has to be built and paid for in advance:
| RTO | Typical approach |
|---|---|
| Seconds to minutes | Clustering, active/active sites, automatic failover |
| A few hours | Hot site or warm standby with current replicas |
| A day or two | Warm site, restore from recent backups |
| A week or more | Cold site, rebuild from backups |
Different systems get different RTOs. An online store's checkout might have a 15-minute RTO, while the internal training portal can wait five days. Setting every system to the shortest target is the most expensive possible plan and is almost never justified.