Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

Well-managed organizations use data protection best practices to assess data loss risks and develop effective business continuity policies. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are two critical metrics used in disaster recovery and data protection strategies.

Both these parameters, RTO and RPO, are closely related and sound similar but differ in many ways and serve different purposes.

Here, we try to understand the difference between these two terms, some examples of their application, and how they help build solid disaster recovery strategies for an organization.

What is Recovery Time Objective (RTO)?

Recovery Time Objective (RTO) measures how quickly a business process must get back to normal after a disaster to avoid any unacceptable consequences for the business continuity. In other words, RTO answers the question, ‘How long did it take to restore the infrastructure after being notified of the disruption?’

RTO is often used to define the highest acceptable downtime an organization can manage. It is the desired time set for the restoration of services after a disruption.

For example, an RTO of 2 hours means everything within the company should be back and running in two hours after receiving a disruption notification.

Different organizations have varying resilience to outages, and the desirable RTO may not always be achievable. A natural calamity may, for instance, impact a business for weeks.

Organizations can either have internal or outsourced RTO. Businesses with in-house IT departments should include technical problem-solving as a goal.

The severity of the disruption determines the ability to meet the RTO. For example, an RTO of 1 hour is realistic for a server crash. However, the same RTO may not be attainable for a natural disaster.

When IT services are outsourced, the RTO is defined as a part of the Service Level Agreement (SLA). The service provider generally includes terms like:

• Availability: the hours they are available for support
• Response time: how fast they respond once you ask for support
• Resolution time: the time they take to restore the processes

The RTO and support vary depending on your business needs. By defining the RTO for a particular system or application, a business can identify the best disaster recovery techniques for the situation.

See also: Mastering Service Level Agreements: Best Practices for SLAs

What is Recovery Point Objective (RPO)?

Recovery Point Objective, or RPO, is a measure of the acceptable data loss, in terms of amount or time, a business can afford during a disruption.

Consider the example of a bank transactions database where transfers, payments, and other information are recorded. The recovered database, in this case, should be the same as the database at the time of the disaster.

This is because many transactions can occur in few minutes, and the information is difficult to recover in other ways. So, the RPO is equal or close to zero, meaning the backup should be done in real-time.

Now, consider a source code repository where developers store their work. Software developers may find it easy to rewrite the code lost for one day but may not be able to recreate multiple days of code.

So, the RPO, in this case, should be 24 hours, which means a backup should be done at least once a day. The implication is that the RPO is shorter for data that is harder to recover or recreate.

Backups and data copies are an integral part of RPO strategies. However, it is vital to know the threshold of data loss acceptable by a business. Some businesses calculate the frequency of backups by comparing storage costs with recovery costs. Others prefer creating a real-time copy of all the business data using cloud storage.

Just like RTO, some organizations have better data loss tolerance than others. For example, a small service business may be able to retrieve 18 hours of data loss without impacting its operations severely. On the other hand, an internet-based store can start experiencing troubles within minutes of disruption.

What is the difference between RTO and RPO?

The primary difference between Recovery Time Objective and Recovery Point Objective is the purposes they serve.

RTO focuses on the downtime of processes, applications, and services, thereby guiding the allocation of resources for business continuity.

On the other hand, RPO focuses on the amount of data and serves the sole purpose of defining backup frequency.

Another critical difference between the two is their behavior concerning the disruption. RTO looks forward in time by measuring the time taken to resume operations, while RPO looks backwards by estimating the amount of data or time you are losing in the disaster. 

Difference between RTO and RPO in risk calculation

Both Recovery Time Objective and Recovery Point Objective are calculations of risk. RTO calculates how long a business can withstand an interruption, while RPO estimates how fresh the data will be upon recovery. Both the measures involve periods, but RPO focuses on data loss while RTO emphasis restoring the systems.

Calculating RTO

When calculating RTO, it should first be aligned with the possibilities in the organization. An understanding of various restore speeds helps determine realistic RTO. For example, if the minimum time a system needs to restore is two hours, an RTO of one hour is impossible.

The calculation should start with an inventory of business-critical applications, systems, data, and virtual environments. The next step is to evaluate the importance of each application and service.  This step needs to be done with consideration of its contribution to business operations.

Here are some essential factors that help calculate RTO:

• Cost of outage per hour
• Importance and priority of systems
• Cost/benefit ratio for recovery solutions
• Measures required for disaster recovery

By understanding the value of each running application and system, it becomes easy to calculate RTO. However, RTO requirements can vary depending on the priorities and values of the applications.

Calculating RPO

RPO calculation is directly associated with risk assessment. During a disruption, RPO works as a factor in balancing the impact of loss and recovery costs. An acceptable loss is a few dissatisfied customers from lost transaction data but losing hundreds of transactions is unacceptable.

Here are some factors that help determine RPO:

• The maximum amount of data loss the business can tolerate
• Cost of data loss
• The expense of implementing data recovery solutions

RPO is a measure of the maximum time between any two backups the business can afford. If a business performs backups every six hours and a disaster occurs one hour after a backup, you lose only one hour’s worth of data and are five hours under the projected RPO.

RTO and RPO in Disaster Recovery

Both RTO and RPO are essential aspects of a disaster recovery plan, helping organizations choose the best data protection and business continuity solutions. Apart from business impact analysis, these objectives lay the foundation for identifying the strategies to be included in a disaster recovery plan. The strategy options include those that would allow a process to resume in accordance with the RTO and RPO.

In the case of a disaster, RTO is used to determine the steps taken for mitigation in terms of facilities, applications, money, staff, etc. A shorter RTO requires more resources. On the other hand, RPO determines the frequency of data backup for the recovery of data that may be lost during a disaster. For example, an RPO of 4 hours means you should back up data every four hours at the minimum. Twenty-four hours can be dangerous while doing it every hour would cost too much without adding much value.

A good ratio of RTO/RPO depends on the type of disruption and the maximum period of tolerance. Some of the most common types of disruptions that may require data backup and recovery include:

• Loss of data: It can be a simple file deletion or as complicated as an infected database
• Application: These are the changes or updates affecting the services negatively
• System: A failure of hardware or operating system crash
• Operations: A complete stoppage of business operations
• Infrastructure: The disaster may include fire, flood, chemical accidents, electrical outage, etc

It is vital to consider data, systems, processes, applications, and infrastructure in a disaster recovery plan. Such factors influence the values of RTO and RPO to a great extent. Once you have identified the disaster possibilities, you can prioritize the ones you think are the most important and then implement measures for recovery.

Relation between RTO and RPO

Though both RTO and RPO are critical aspects of business impact analysis and continuity management, they are not related to each other directly. However, as they don’t conflict, no rule tells whether RTO should be less than RPO or vice-versa. One could have an RTO of 20 hours and RPO of 2 hours or RTO of 1 hour and RPO of 10 hours.

For example, the RTO for an eCommerce site is 5 hours because it should be up in this time duration after a disaster. But the store has two databases – the product catalog is updated every week, and the sales database is updated thousand times a day. So, the RPO for the first database is six days, and for the second, it has to be close to zero.

RTO and RPO work together to help you estimate the downtime related to a disaster in the organization and better define your business continuity strategies. The right balance of processes and resources to meet your RTO and RPO is essential for protecting your business against the impact of disruptions.