RTO and RPO: What’s the Difference?

What Is RTO?

A recovery time objective (RTO) is the maximum acceptable time between disaster and recovery after which a business suffers critical damage.

Defining RTO boils down to this question: How long can we comfortably stay down after a disruption without a considerable impact on our business?

What Is RPO?

A recovery point objective (RPO) is the maximum acceptable time between the last backup copy and now. In this context, “now” refers to all the data currently stored in production.

Defining RPO begs the question: How much data can we comfortably lose in a security incident before it starts to impinge on our business?

Note: Although RPO describes data quantity, it is expressed in units of time, not units of storage. This is because data accrues at a variable rate, so we cannot predict the exact amount that will be generated. For this reason, time is the most reliable way to measure RPO.

RTO vs. RPO

The main difference between RPO and RTO lies in their purpose. RTO supports business continuity, while RPO focuses on data. In other words, RTO protects the future. RPO protects the past.

Recovery Time Objective (RTO)

RTO protects the freshest data, allowing you to recover the most recent changes, which is important to keep businesses operational.

Improving RTO requires investing in high-performing hardware optimized for the recovery use case, including support for load balancing and Instant Recovery, which can run failed workloads directly from backups.

RTO is called a recovery time objective because it’s about minimizing the time of recovery.

Recovery Point Objective (RPO)

RPO protects all the data your business has collected until now. RPO relies on backups, and the relationship is straightforward: the more frequent the backups, the better the RPO, and the less data is at risk of being lost.

We call RPO a recovery point objective because it defines the latest point of data backup. For example, an RPO of 0 would require that every change in data be duplicated in real-time, eliminating discrepancies between backup and production. This approach is called continuous data protection (CDP).

In its strict form, continuous data protection can drive RPO down to zero, but it’s so resource-intensive that few companies implement it to the letter.

The Importance of RTO and RPO

The truth is that businesses don’t want to suffer any downtime or data loss. Framing these as “acceptable” or “comfortable” may make you feel… well, uncomfortable.

However, devoting time to calculating RTO and RPO will, paradoxically, give you the comfort of knowing that your organization can withstand a disaster.

Other benefits of RTO and RPO for your business include:

Better Disaster Preparedness. RTO and RPO will inform your entire recovery strategy and make it more realistic. They will point you to the right resources, steps, and protocols for mitigating data loss and business disruption.

Realistic and reliable SLAs. Once you know the feasible RTO and RPO for your business, you can include them in your Service-Level Agreement and confidently deliver them.

Optimized Division of Labor. RTO and RPO will also help design and streamline employee workflows for an incident. Again - when you have a clear goal grounded in reality, you can easily plan and delegate tasks around it.

How to Calculate RTO and RPO?

Follow the steps below to gather the correct information and use it to calculate RTO and RPO in your organization.

Step 1: Interview

Ask your leadership and management to rank the organization’s systems and applications from the most to least critical for business continuity and revenue.

Step 2: Categorize

Armed with this information, sort the systems into tiers. For example, assign the most critical apps to Tier 1, the less critical ones to Tier 2, and the least to Tier 3.

Step 3: Examine

Now, imagine there’s a service interruption due to a security incident. Go through each system one by one, assuming it’s been breached, and determine the following:

RTO	RPO
The frequency of the disruption.	Estimated data loss based on existing backup schedules.
Its average duration.	The cost of the projected data loss.
The cost of downtime per minute.	The cost of reproducing the lost data–in terms of human labor, for example.
The service-level agreement (SLA) if applicable.
The potential for customer churn or dissatisfaction.
Potential impact on other systems.

Table 1. Pre-evaluation checklist for RTO and RPO.

Step 4: Calculate

With the data from Step 3, use the questions below to determine the right metrics for your business.

Determining RTO	Determining RPO
What’s the maximum acceptable downtime?	What’s the backup frequency across the different departments within your organization?
What are the resources needed to stay within that limit?	What does your business continuity plan say about RPO and backup schedules?
How long will it take to deploy the necessary procedures?	What are the industry standards for backup frequency depending on system criticality (tiers)?
Your RTO is the maximum acceptable downtime plus the time to muster the resources.	Your organization’s RPO should align with the most frequently backed-up system, your business continuity plan, and industry standards.

Table 2. Checklist for calculating RTO and RPO

RTO and RPO Best Practices

In a perfect world, RTO and RPO should always amount to zero. But life being what it is, the metrics won’t likely live up to that ideal. Nevertheless, here are some best practices you can foster within your organization to reduce RTO and RPO:

Schedule backups frequently. The rule is simple–the more frequent your backups, the better your RPO. Also, make sure you keep the most sensitive data on immutable backups for extra security.

Leverage redundancy. Follow a data replication scheme. Replication isn’t a substitute for backups, but it adds an extra layer of security for your business.

Testing and validation. Even the best RTO and RPO are just a figment of your imagination until you test them and validate them in real-life circumstances.

Priority-based recovery. Make your disaster recovery resource-efficient–prioritize your systems and restore the critical ones first.

Automation. Take advantage of automation to manage your backup schedules, but don't forget to check if it continues to align with your business strategy.

Offsite storage. Follow the 3-2-1 backup rule to make your backups even more secure–with three identical backup copies on two different media, and one of them offsite, so it’s not affected by local disasters such as floods.

How Can Ootbi Help in Disaster Recovery?

Ultimately, RTO and RPO depend on how secure, simple, and powerful your backup and recovery system is.

Ootbi (Out-of-the-Box Immutability) by Object First is a purpose-built backup appliance for Veeam customers that delivers on all those fronts.

Ootbi is secure. Ransomware-proof and immutable out-of-the-box, Ootbi is designed around the latest Zero Trust Data Resilience principles, with zero access to root, built-in segmentation, and multiple resilience zones.

Ootbi is simple. Racked, stacked, and powered in under 15 minutes with no technical expertise required, Ootbi is maintained and optimized automatically by the vendor.

Ootbi is powerful. Designed with performance in mind, Ootbi scales linearly within minutes and supports backup speeds of up to 4GB/s and Instant Recovery tested at scale with up to 80 VMs running on a four-node cluster.

Others have improved their metrics with Ootbi. For example, Centerbase, a legal practice management solution, reduced its RPO by 50%. Here’s what they said:

Use Ootbi to improve your metrics, too. Book a free demo today, and let our engineers show you the magic behind the box. Book demo

FAQ

What Are Examples of RTO and RPO?

In the case of RTO, suppose a ransomware attack disables your web server, making your website inaccessible to customers. Based on prior calculations, the maximum acceptable downtime for this system is 1 hour. After that, you’ll start losing traffic, clients, and reputation. Therefore, the web server must be restored to full capacity within that time window.

In the case of RPO, say your analysis shows that the most recent backup copy of the web server data must not be older than 1 hour. You don’t want to lose customer records and transactions from beyond that point in time. Consequently, as long as the last backup of the web server was performed within 60 minutes of the incident, your RPO requirements will be met.

What Is Disaster Recovery?

Disaster recovery is a detailed plan of action that aims to prevent security incidents from happening and mitigate their fallout if they do occur. RTO and RPO are vital, but not the only elements of a disaster recovery strategy.

Product news