How to Calculate RPO and RTO for Disaster Recovery Planning
When disaster strikes, your firm must find a way to ensure business continuity. That means getting your networks and systems up and running as quickly as possible. However, that raises questions. Do all applications need to be restored as soon as possible? How much information do you need to restore?
That’s where RTO and RPO come into the picture. In this article, we’ll explore what these concepts mean, how to calculate them, and examples of how to apply these concepts.
|RTOs measure how quickly you need to restore an application.||RPOs measure back in time to when your data was saved in a usable format (usually the most recent backup).|
|RTOs can be used to determine how long you can tolerate an application outage.|
If you’re creating a disaster recovery plan, one of the first things you need to do is determine what you need to protect. All data is not created equal and there’s likely no reason to replicate and store every bit and byte on your servers.
The two primary methods of measuring the criticality of IT systems are how much data and time you can afford to lose, commonly referred to as RPO and RTO.
RPO: Recovery Point Objective
The first, the Recovery Point Objective is the threshold of how much data you can afford to lose since the last backup.
Defining your company’s RPO typically begins with examining how frequently backup takes place. Since backup can be intrusive to systems it is not typically performed more frequently than every several hours. This means that your backup RPO is probably measured in hours of data loss.
We’ll illustrate with an example of how to use RPO. Let’s say that you have a system outage at 1 PM. You know that the system performs a backup automatically at 12 PM. As the last time your information was saved in a usable format, the RPO should be 12 PM.
Read our white paper
Review every high availability and disaster recovery solution available today for your environment, from single-system to multi-system replication, from logical replication to disk-level replication and all points in between.
RTO: Recovery Time Objective
The second, the Recovery Time Objective is the threshold for how quickly you need to have an application’s information restored.
Here’s an example of how you use RTO. You have an application that collects sensor data from mission-critical hardware. If you don’t have visibility into how that hardware is performing, your company could suffer huge losses. The RTO for bringing that system back online is very short. However, if you have a less mission-critical application (let’s say an app that you don’t use very frequently that doesn’t have a huge bearing on the business), the RTO could be considerably longer.
Using these two primary measures will help you estimate your cost of downtime to better define your budget for an IT system continuity plan. Reviewing your RPO and RTO can also help you determine which technology will best meet your needs.
Finding the right balance of features and price to meet your RPO and RTO is one of the most critical things you can do to protect your business. For IT system continuity, there are three solution categories: backup, high availability and disaster recovery.
- Backup means keeping your data safe; in this situation, RPO is more critical than RTO.
- High availability means avoiding downtime and keeping your critical applications and data online – a high availability solution is required for high RPO and RTO
- Disaster recovery is the ability to recover data in case the production system is damaged, destroyed or becomes unavailable for an undeterminable period of time. A comprehensive disaster recovery solution that can restore data quickly and completely is required to meet low RPO and RTO thresholds.
Precisely offers high availability and disaster recovery solutions (Assure MIMIX, Assure iTERA and Assure QuickEDD) to ensure you can keep critical apps online and restore any lost data in the event of a disaster.
Read The Ultimate Buyer’s Guide to HA/DR Solutions for a detailed look at every option available today for your environment, from single-system to multi-system replication, from logical replication to disk-level replication and all points in between.