Chapter 5 — RTO and RPO

5.1 RTO/RPO Are "Objectives"

In Chapter 4, we saw that looking at business functions and the impact of disruption through BIA (Business Impact Analysis) provides the basis for thinking about the need for Recovery and its priority.

This chapter looks at one way of expressing that need for recovery as a more concrete objective: RTO (Recovery Time Objective) and RPO (Recovery Point Objective).

There is an important premise here.

RTO/RPO are not words that describe "how many hours it actually took" or "how often Backups are taken." They are words that describe how far, in business terms, you are aiming to reach.

In other words, RTO/RPO are first and foremost "objectives," and need to be thought of as separate from the technical design used to achieve them and from the results actually achieved. We revisit this distinction in 5.7.

5.2 What Is RTO?

RTO (Recovery Time Objective) is an objective for thinking about how much time, after a failure or disruption occurs, business operations or a system need to be recovered within.

In the technical guidance on contingency planning for information systems published by NIST (the National Institute of Standards and Technology), RTO is also treated as a recovery-time objective tied to unacceptable downtime and business impact.

What to be careful of here is that RTO is something considered from the business side, as "the maximum amount of time allowed before recovery." It is considered separately, for the moment, from how the recovery work is technically carried out or how much time it actually takes.

This chapter does not go as far as the exact point at which RTO is considered to start and end. For now, it is enough to hold onto the idea of "a target for the downtime acceptable from a business standpoint."

5.3 What Is RPO?

RPO (Recovery Point Objective) is an objective for thinking about, when a failure occurs, how far back in time data needs to be able to be restored to — that is, how much data loss can be tolerated.

This, too, is treated in NIST's technical documentation as an objective for the point in time to be recovered, tied to acceptable data loss.

RPO is not "the Backup interval itself." It is an objective for "how much data loss can be tolerated from a business standpoint."

For example, an objective of "an RPO of one hour" means "tolerating, at most, one hour's worth of data loss counting back from the point of failure" — it is not the implementation-level fact of "taking Backups every hour."

5.4 RTO and Restore Duration Are Not the Same

Let's clarify a common misunderstanding here.

RTO is an objective; it is not the actual time (duration) that a Restore or Recovery takes.

As in the opening scenario, it is common to treat "the time recovery actually took" as if it were the RTO. But this gets the order backward. RTO is an objective the business side sets in advance — "we want to recover within about this much time" — and the actual Restore duration is result-side information used to judge whether that objective was achieved.

That said, one thing needs attention here. This does not mean "RTO and the actual Restore duration are unrelated." The time an actual Restore or Recovery takes is important information for judging whether the RTO objective can be achieved. The objective and the measured result are distinct concepts, while being related to each other.

5.5 RPO and Backup Interval Are Not the Same

The same kind of clarification is needed for RPO.

RPO is an objective; it is not the interval at which Backups are taken (the Backup interval) itself.

"The fact of taking Backups every day, by itself, does not fix the RPO at 24 hours."

This is also what the person in charge in the opening scenario initially assumed. The Backup interval is one design element for achieving the RPO objective. It is not the RPO objective itself.

Here too, note that this does not mean "the Backup interval and RPO are completely unrelated." How often Backups are taken is one design input that affects whether the RPO objective can actually be met. The objective and the implementation-level setting are distinct concepts, while being related to each other.

Things Easily Confused with RTO / RPO

Let's organize what we've covered so far into a simple table.

This table, too, is only a guide for organizing ideas; it does not present concrete time values or industry standard values.

5.6 Connecting RTO/RPO to Design

As we have seen, RTO and RPO are, first and foremost, business-side objectives to consider.

That flow can be summarized simply as follows.

Business Impact / Need for Recovery (Chapter 4)
          ↓
The objectives RTO / RPO
          ↓
Input to Backup / Recovery design

Once the RTO/RPO objectives are set, they become one of the inputs for thinking about Backup or Recovery design.

For example, design decisions such as how often to take Backups are also related to the RPO objective.

Multiple other elements are also involved in concrete technical design.

That said, this does not mean "once you decide on the RTO/RPO objectives, the design content is automatically and uniquely determined." Objectives are material and a foundation for thinking about design; they do not mechanically derive the concrete design decisions themselves.

Note also that, to actually get back to the point in time RPO calls for, a Restore to that point in time needs to actually succeed. This is a matter of technical dependency, and the details are beyond the scope of this chapter.

5.7 Separating the Objective from the Result Actually Achieved

Let's organize the content of this chapter one more level.

When thinking about RTO/RPO, it helps to separate the following three layers.

Teaching Diagram (a simplified conceptual diagram; it does not show the strict
timeline definition of any particular standard or product)

Recovery Objective (the objectives RTO / RPO)
          ↓
Technical Design / Operation (Backup frequency, Restore method, and other technical design/operation)
          ↓
Actual Measured Result (the recovery time actually achieved, the data point in time actually recovered to)

Simply setting an RTO or RPO objective does not mean it has been achieved. Carrying out technical design and operation based on the objective, and then confirming whether that objective can actually be achieved when a failure occurs, requires a separate confirmation.

When thinking about RTO, the criteria for what counts as Recovery being complete also matter. We cover this point in a later chapter on Recovery plans.

Also, whether a set objective can actually be achieved needs to be confirmed through Recovery Test / Exercise. The concrete method of confirmation is covered again in a later chapter.

5.8 Summary

This chapter organized RTO and RPO, centered on the idea that each is an "objective."

The important points are these:

• RTO is a business-side objective for how much time, after a failure occurs, recovery needs to happen within.
• RPO is a business-side objective for how far back in time data needs to be restored to.
• RTO is not the actual Restore duration itself, but the two are not unrelated — the duration matters for judging whether the objective was achieved.
• RPO is not the Backup interval itself, but the two are not unrelated — the interval is one design element related to achieving the objective.
• The RTO/RPO objectives are material and a foundation for thinking about Backup/Recovery design, but they do not automatically and uniquely determine the design content.
• Setting an objective does not mean it has been achieved; whether it can actually be achieved needs to be confirmed through Test/Exercise and the like.

In the next chapter, we look at how Business Criticality, Recovery Priority, and Technical Recovery Order are each distinct ways of thinking.

Questions to Consider After Reading Chapter 5

Thinking about the systems you are responsible for, can you answer the following questions?

• Can you explain RTO in your own words?
• Can you explain RPO in your own words?
• Can you explain why RTO is not the same as the actual Restore duration?
• Can you explain why RPO is not the same as the Backup interval?
• Can you explain why setting an RTO/RPO does not mean it has been achieved?

You do not need to be able to answer all of them.

Rather, if there is a point where you get stuck, that is exactly the point this chapter is meant to help you check.