Recovery Time Objective and Recovery Point Objective

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. The clock starts at detection, so a failure noticed only at 06:50 would allow until 07:35. 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: a failure at 06:30 restored from a copy taken at 02:00 loses four and a half hours of changes and fails the objective, while a failure that happens minutes after the copy completed could pass it. 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.

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. 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. 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.