Understanding RPO and RTO

RTO and RPO considerations when selecting a backup solution


RTO and RPO: Understanding the definition and difference


RTO and RPO – I am sure you’ve had those acronyms thrown at you before. If you’re wondering what they mean, or how they impact your choice of backup solution, read on.

Both RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are related to situations where a business needs to recover from a (typically) unplanned disruption.

For businesses or applications which have zero tolerance for downtime, solutions like real-time replication or a high availability cluster may be a necessity – which is outside the scope of discussion for this blog post. But if there is some tolerance for downtime, then a backup solution can be a much more affordable and practical option. We will discuss RTO and RPO here from the standpoint of a backup solution.

If there is some tolerance for downtime, then a backup solution

can be a much more affordable and practical option.

What is RPO – Recovery Point Objective?

RPO meaning

A Recovery Point Objective (RPO) is the maximum acceptable amount of data loss after an unplanned disruption, expressed as an interval of time. This is generally thought of as the point in time before the event at which data can be successfully recovered until – that is, the time elapsed since the most recent reliable backup.

For certain businesses or in the case of certain types of data, an RPO of 24 hours may be adequate. For certain mission critical functions, the RPO may need to be much smaller. Naturally, this has a direct impact on the frequency of backups you run.

For the smallest RPO, backups which are continuous in nature – i.e. replicating and making a copy of data in real time are necessary. But as a matter of practicality, continuous backups come with the downside of requiring higher network bandwidth and in the case of most applications (like file services) it may not be necessary to transmit every change in real time.

Continuous backups come with the downside of requiring

higher network bandwidth and in the case of most applications

(like file services).

Scheduled backups with the flexibility of running schedules multiple times a day is more than sufficient in a majority of cases. An RPO of a few hours is acceptable in many businesses and for most applications.


What is RTO – Recovery Time Objective?

RTO meaning

Usually discussed in conjunction with RPO, a Recovery Time Objective (RTO) is the maximum tolerable length of time that an application can be down after a disruption. This can also be considered the maximum amount of time that can be taken to perform data recovery – i.e. this is how fast your data restoration needs to be.

The biggest factor impacting recovery time objective is, unsurprisingly, how far away your backups are. Backups that are on-premise obviously can offer lower RTOs. Backups that are offsite (like tapes, or cloud copies) have longer RTOs.


How do you reconcile the need to have an offsite copy with a lower RTO?

But backups are kept offsite to defend against natural disasters (like a fire, flood or earthquake). So, how do you reconcile the need to have an offsite copy with a lower RTO?

There are several approaches to this.

One is to simply also have a local copy of the backup, in addition to the offsite copy. Commonly called a Dual Copy strategy, this is a simple but effective way to get the best of both worlds.

Another is to be able to restore the cloud backup copy to a cloud destination so that users get access to their data faster. Cloud based restores are slow mainly due to network bandwidth limitations connecting the business to the internet. But if the data restoration happens from a cloud source to a cloud destination (say from your backups directly to a location like OneDrive or Google Drive) where users expect to be able to access the data – that speed can be considerably faster.

A third approach is to allow more critical data to be recovered first – so essential services can get up and running faster. Other data can be restored in the background – but at least users get the data they immediately need first – in order to be able to do their jobs.

One may of course use a combination of the above methods for best results.


Quick summary

Disaster Recovery and Business Continuity are complex subjects and impossible to do justice to in a short blog post. But, both RTO and RPO are important considerations from a DR and BC standpoint. It is important to consider both closely when choosing and configuring your backup solution.

To summarize:

1. Consider high availability clusters and real-time replication only if your applications are mission critical and have zero tolerance for downtime. Such solutions are expensive and not always practical.

2. Continuous backups offer low RTO but may be overkill for most cases. Their high network bandwidth usage might make them unsuitable in most cases where a few hours of RPO is considered acceptable.

3. Choose backup solutions that allow scheduling and offer the flexibility of allowing multiple schedules a day.

4. Choose a backup solution that offers a Dual Copy option to reduce RTO.

5. Pick a backup solution that allows a cloud-cloud recovery option and also allows you to prioritize which data to be restored first.

How Parablu can help

At Parablu we build solutions focused on protecting enterprise data. Parablu’s BluVault is designed to enable robust data backup from user endpoints, SaaS workloads (Microsoft 365) and edge servers. Our patented integration with Microsoft 365 and OneDrive for Business also means that you can deploy BluVault without spending a penny for backup storage.

Sound interesting? Reach out to us and learn more.

Do you have specific requirements or enterprise needs?

Share the Post:
Scroll to Top