Everything MSPs need to know about RTO vs. RPO

RTO and RPO are both critical elements of disaster recovery. In order to mitigate against irreversible data loss and consequent damage to business and revenue due to a potential natural disaster, it is fundamental to prepare for the worst-case scenario.

 

Calculating a business’ RTO and RPO is the first step to designing the optimum backup and disaster recovery plan to maximize business continuity and minimize risk and disruption.

 

In this article, we outline the fundamental role of both RPO and RTO, what the differences between them are, and will look at why all MSPs should not underestimate their value.

 

What is RPO?

 

RPO stands for ‘Recovery Point Objective’. RPO tells you the maximum tolerable amount of time that can pass between the time of the latest backup and a disaster.

 

By calculating an accurate RPO, you can determine:

 

  • How frequently backups should and need to be scheduled
  • The maximum amount of data that an organization can afford to lose in the event of a disaster

 

RPO looks retrospectively to indicate at which point in time the data was last in a usable and acceptable state, thus designating the moment to which an application or system will be restored. This also tells you how up-to-date your recovered data will be in the event of an outage.

 

RPO is also an indication of how much recent data will be lost, and therefore will need to be re-entered in the case of a disaster.

 

For example, if an organization backs up every 12 hours, the maximum amount of data lost would be 12 hours’ worth.

 

That being said, the optimum RPO is not a blanket metric across a whole organization. Instead, the maximum data loss will vary depending upon the value and priority of the application affected (but more on this later).

 

RPO is linked to an organization’s maximum allowable threshold or ‘tolerance’, which is a measurement of how much data can be lost before you see irrecoverable and detrimental damage to the organization, its operations, and its business continuity.

 

Although RPO is an IT metric, it is actually defined during BCDR planning and is as much a business decision as it is an IT one.

 

What is RTO?

 

RTO stands for Recovery Time Objective. RTO is related to how much time is needed to bring a disaster-affected system or application back online.

 

Whilst RPO looks back retrospectively, RTO looks forward to the future. It is a measure of recovery time and how much time a specific application can tolerably be down for.

 

Essentially, it references the maximum threshold of downtime that a business can endure before detrimental damage is caused.

 

RTO will indicate:

 

The time it will take to run full restoration processes from the time of disaster
What MSPs need to prepare ahead of a disaster to facilitate effective implementation of BCDR plan
The maximum acceptable risk of data loss

 

The maximum RTO will fluctuate between businesses. While some organizations can invariably tolerate hours of downtime, for others, even an outage lasting seconds could cause lasting damage.

 

RTO vs. RPO

 

RTO and RPO sound very similar and both relate to disaster recovery, so what is the relationship between them?

 

There is a balancing act between RTO and RPO. By looking at both metrics, MSPs can calculate how far back they should restore to without delaying data loss against anticipated RTO.

 

Similarities between RTO and RPO

 

RTO and RPO are both measured in units of time. They are both crucial metrics that inform data recovery strategies and processes. In an ideal world, an organization’s RTO and RPO should be near-zero. Unfortunately, in reality, this is near impossible. This is because near-zero RTO and RPOs are expensive, resource-intensive, and most probably not necessary for all applications used by an organization.

 

For this reason, the most effective DR planning is based on prioritization. This prioritization is informed by both revenue and risk, and will help an organization to rank applications and systems in order of importance.

 

Ultimately, resources will be concentrated on the most critical applications that hold valuable data.

 

Differences between RTO and RPO

 

RTO relates to applications, systems, and data recovery processes. It is explicitly linked to the maximum downtime acceptable to an organization.

 

By contrast, RPO concentrates on the amount of data that could be lost in case of a disaster.

 

How do you calculate RPO and RTO?

 

Unfortunately, there is no single one-size-fits-all BCDR. This also means that every organization and business’s RPO and RTO will differ slightly.

 

That being said, RTO and RPO will actively influence an organization’s computer system and infrastructure design, so it’s critical to calculate them accurately. Both parameters call for a balance between the cost and benefit of mitigation and recovery.

 

Specifically, RPO is a balance between the impact of data loss and the cost of mitigation. These are some of the factors that should be taken into consideration when calculating RPO:

 

  • The anticipated amount of data loss and its cost
  • Data type and how it is stored
  • How often is this data changed
  • Maximum tolerable data loss threshold
  • Regulatory and compliance concerns
  • Cost of lost data and its reentry
  • Cost of mitigation and recovery protocol

 

RTO calculation is based on application priority and risk to business, which helps to allocate available resources and budget appropriately. To determine maximum RTO, MSPs should look at:

 

  • The cost per hour of the outage and the projected loss of revenue as a result
  • How it affects customers or clients
  • Wider infrastructural impact of an outage – does this application or system have dependencies?
  • Importance and priority of system or applications in question
  • Cost of recovery protocol implementation
  • Budget and available resources

 

Why RPO and RTO are important

 

RPO and RTO are absolutely fundamental parameters for any business. As with any risk mitigation, thorough preparation ahead of time is crucial to damage limitation and a speedy recovery.

 

RPO and RTO directly inform BCDR plan

 

By taking the time to calculate RPO and RTO, an organization will better understand their particular position, the risks they can afford to take, and the measures that need to be put into place to protect their business. This will directly influence their BCDR plan and help ensure it’s as robust as possible.

 

RPO and RTO help MSPs prepare and prioritize

 

When you’ve determined your client’s RPO and RTO, you will be able to better prepare your disaster recovery objectives and business continuity plans in advance.

 

Because a critical part of the RPO and RTO calculation process is prioritization, you will be able to ascertain which applications you should be prioritizing in your disaster recovery plan, and prepare your system infrastructure to accommodate this.