Recovery Time and Recovery Point Objectives

The recovery time objective, or RTO, is how long a system’s components may remain in recovery before the organization’s mission or business processes are harmed. The recovery point objective, or RPO, is the point in time to which data must be recovered after an outage, which fixes how much recent work may be lost. Both definitions come from NIST’s contingency planning guide, and they are separate conditions: meeting one says nothing about the other.

Two questions about the same outage

A fictional morning report has a 45-minute recovery time target: if the job fails at 06:30 and the failure is detected immediately, the clock starts at 06:30 and a usable report must exist by 07:15. This example defines its clock from detection, so a failure noticed only at 06:50 would allow until 07:35 under that target. If the failure began at 06:30, the total interruption would be 65 minutes. Record detection delay separately and compare the full interruption with the business tolerance; meeting a detection-based target does not by itself establish acceptable continuity. The report’s 06:00 comparison point is the data scope the report needs, since clerks accept that receipts booked after 06:00 appear tomorrow; it is not a loss tolerance. A replaced order-entry system needs a recovery point objective stated as an allowed loss, for example no more than five minutes of accepted orders before the failure, because an order accepted and then lost is a business failure. The last completed synchronization is the recovery position actually achieved, not the objective: it meets the objective only if that position lies within the allowed loss, and a synchronization that stopped an hour before the failure fails it.

A nightly backup that brings a usable service back within 30 minutes of detection meets the 45-minute time target. Whether it meets a five-minute point objective depends on how old the recovered data actually is: if recovery after a 06:30 failure reaches only the consistent data position at 02:00, four and a half hours of changes are missing and the objective fails. A recovered position at 06:28 would meet the five-minute objective if there are no earlier gaps. The backup’s completion time alone does not establish either position. Judge the recovered position, not the backup schedule. A continuous copy that takes three hours to bring back fails the time target, and it meets the point objective only if the verified recovered position, after checking for replication lag, gaps, and corruption, lies within five minutes of the failure; the copying method alone proves nothing. The time target is measured to a usable service, not to files restored. The two objectives pull on different mechanisms: recovery speed depends on procedures, people, and access; recovery point depends on how often and how completely data is captured — which is why a replica kept current for reads and a backup kept for restores answer different halves of the question.

Recoverability is not availability

Availability and recoverability answer different questions, and one number can hide the other. Two systems can report the same availability for a year and be nothing alike: one had ninety short interruptions of six minutes, the other had a single outage of nine hours. The first may never have come close to its recovery objectives, because no interruption lasted long enough to test them; the second blew through an RTO of an hour, and the people affected remember it. Whether it also missed its RPO is a separate question with a separate answer: if every acknowledged write was still there when the service came back, the recovery point was the moment of failure and an RPO of zero was met. A long outage is an RTO result. Lost work is an RPO result. A single event can fail one and satisfy the other. Availability describes the aggregate share of eligible time or requests for which the service met its defined success condition. This example counts time; a request-based measure would also give busy periods more weight, so the same outages can produce a different percentage. The recovery objectives describe the worst single event you are prepared to survive — how long it may last, and how much recent work may be gone when it ends.

The practical consequence is that an availability percentage cannot be used to infer either objective, and a long tail of short blips can keep an availability figure respectable while leaving the restore procedure entirely unexercised. State all three, and measure them separately.

Objectives are met by rehearsed restores

Google’s reliability engineering guidance puts it plainly: what people actually want are restores, and you only know that you can recover if you actually do so. A backup that exists is not evidence for either objective — and a restore that runs without a reconciliation against the source shows the service is up, not that the data is right. Rehearse the restore with the people expected to perform it, time it, check the currency of the restored data, and confirm that the restored service can be reached with valid credentials and access.

Set the objectives from the business tolerance, not from what the current tooling happens to provide, and record the owner who accepted them. Both are quality requirements, and they need the same four elements as any other: population, boundary, window, and pass rule. If the tooling cannot meet them, that gap is a requirement for the modernization, not a footnote.

References

• NIST glossary: recovery time objective
• NIST glossary: recovery point objective
• Google SRE: Data integrity

Figures here are illustrative.