RTO and RPO: What’s the Difference? - Zerto

RPO and RTO: Differences and Considerations

A-to-Zerto Glossary of Terms

BACK TO THE GLOSSARY

Overview

Recovery point objectives (RPOs) and recovery time objectives (RTOs) are two of the most important metrics of any disaster recovery plan and are measured in units of time. They deal with data loss and recovery time for data and applications in the event of a disaster. Low RTOs and RPOs are key to achieving IT resilience.  

What Is the Difference between RTO and RPO?

RTOs and RPOs are service level agreement (SLA) metrics that measure the effectiveness of disaster recovery (DR). They are expressed in units of time (days, hours, minutes). Lower values—shorter periods of time—are more desirable.

Timeline showing RPO and RTO as the result of a disruption

Figure 1

  • RTO represents the amount of downtime that can be expected before operations, including data and application services, are back online following a disruption. RTO may be influenced by many factors, including the level of manual vs. automated recovery processes such as boot ordering of VMs, redirecting network traffic, recovering application stacks consistently, etc.
  • RPO measures data loss in a disaster recovery scenario. It refers to most recent point in time in which a known, good copy of data is available to recover a system. The further back in time a recovery point exists, the more data is lost. RPO is often determined by what data protection solution is used such as: backups, storage replication, or continuous data replication.

In figure 1, the RTO is 4 hours (from 1:05 to 5:05 p.m.). Since the disruption occurred at 1:05 p.m., and the last data copy was taken at 10:00 a.m., the RPO is three hours and five minutes. However, in the worst case scenario, the RPO would be four hours, which is the interval between each backup time. This example is simplified—it assumes that the recovery phase starts almost exactly when the disruption occurs. This isn’t usually the case, as described in the next section.

DR 101: Recovery Point Objective (RPO)

DR 101: Recovery Time Objective (RTO)

What is the Relationship between RPO, RTO, MTD and MTDL?

RTOs and RPOs are usually set to meet specific business continuity SLA metrics: maximum tolerable time (MTD) and maximum tolerable data loss (MTDL), metrics that may be driven by internal or external regulatory requirements for operation and data recovery.

what business continuity metrics (MTD and MTDL) and disaster recovery metrics (RTO and RPO) represent over a business disruption

Figure 2

RTO is one of several components that make up MTD. As shown in figure 2, MTD includes incident response time (IRT)—the time from the disruption point to when the disaster is declared and the recovery plan activated—RTO, and the operational resumption time (ORT) needed to restart and run business function at an acceptable level.

Optimizing any of these three components (or all of them) increases the likelihood of meeting, and even exceeding, the MTD requirement.

If IRT and ORT are inefficient, they will force an RTO target lower than what may be necessary, which potentially adds cost toward a DR solution that can deliver a lower RTO.

RPO directly correlates to MTDL and must be less than or, at most, equal to it.

Risk Assessment, BIA, SLA, RTO and RPO: What's the Link? MTD and MTDL

MTD and MTDL: Differences and Considerations

RTO and RPO: Business Process vs. Application and Data Level

Business impact analytics usually determine MTD and MTDL, two key business continuity metrics, at a business process level.

However, there are almost always several IT applications and systems involved in each business process. The RTOs and RPOs of each individual application will have to be evaluated. All dependencies—such as any order over app, VM, or database recovery sequence—must be considered to ensure that the resulting RTO and RPO of the overall business process is compliant.

How Disaster Recovery (DR) metrics (RTO and RPO) meet Business Continuity (BC) SLA metrics (MTD and MTDL)

Figure 3

This sets RTO and RPO requirements, which need to be less than or equal to the MTD and MTDL set in the SLA, as shown in figure 3.

The DR team is responsible for evaluating and selecting compliant solutions as part of the DR planning process.

Financial Implications of RPO and RTO

Downtime, measured by RTO, is time spent waiting for applications and data to be recovered. It significantly decreases revenue, productivity, brand reputation, and customer loyalty. For most businesses, the cost of data loss easily reaches six figures.

Figure 4 illustrates the financial impact downtime that varying RPOs and RTOs would have on a company with a revenue of $100M, based on three different solutions.

Table showing financial impact of data loss and downtime in relation to RTO and RPO

Figure 4

Together, low RTO and low RPO are the foundation of any disaster recovery plan. Both help businesses understand the actual costs of data disruption to help businesses plan and prepare for a disaster, whether it’s an unplanned outage, an act of nature, or a ransomware attack.

While achieving low RTOs and RPOs does incur cost, it’s a small fraction of the costs that downtime and data loss inflict on an organization. When considering its critical business processes, an organization will often decide the investment is well worth it.

RPOs & RTOs: Lowering the Cost of Recovery

Optimizing RTO and RPO

A successful disaster recovery solution should include certain features to help you optimize your RTO and RPO.

  • Continuous data protection (CDP). CDP is always on and replicating the most recently changed data, offering much lower RPOs than snapshot-based backups—with significantly less data loss.
  • Journal-based recovery. Granular journal technology allows you to rewind specific components and recover to the precise moment (down to the second) immediately before a disruption, giving you the lowest RPOs possible.
  • Orchestration and automation. These elements are essential for a disaster recovery strategy, as they allow you to test your disaster recovery plan and minimize downtime before a disruption occurs, helping you to get your RTOs as low as possible.
  • Scalable architecture. A flexible, scalable architecture simplifies and reduces recovery time from a disaster of any size, from one VM, application to an entire datacenter.

Optimizing Recovery Point Objective (RPO)

Optimizing Recovery Time Objective (RTO)

Achieve the Lowest RTO and RPO in the Industry with Zerto

In today’s digital business world, it is more important than ever to keep these objective times as low as possible. Luckily, lowering RPO and RTO to within a few seconds is not only possible but simple with Zerto, a Hewlett Packard Enterprise company. 

Zerto consistently achieves the lowest RTOs and RPOs in the industry —with its continuous data protection technology— to help organizations achieve business continuity and ransomware resilience. Zerto adapts DR strategies to keep recovery objectives as low as possible, preventing data loss almost entirely. 

Zerto Solution Overview

Other Resources

LATEST FROM ZERTO SEE ALL

Resource Center

Discover and access content from Zerto and 3rd parties (IDC, Gartner, ESG, etc.) related to RPO and RTO.

Disaster Recovery Essentials

Learn about the essential elements part of disaster recovery.

DR Testing Essentials

Testing is essential to ensure you can achieve your target RTOs and RPOs. Make sure you are safe and can deliver on your SLAs.

What is Zerto?

Learn about Zerto and how it can help you solve your data protection and recovery challenges.