RTO vs RPO: Two Metrics You Need in Your Disaster Recovery Plan

Some disasters, such as those wrought by Mother Nature, can be physically destructive; others, such as those brought on by cyberattackers, can be virtually destructive. However, no matter which type of disaster strikes, there’s always one thing in common: downtime.

According to Gartner, the world’s leading research company, downtime can cost companies $5,600 per minute, or nearly $340,000 an hour! In today’s highly competitive market, that’s just not acceptable.

To mitigate downtime and the loss of productivity and revenue that comes with it, organizations need to practice preparedness; being prepared is the best defense against downtime. This means having a strong business continuity and disaster recovery (BCDR) plan. To build a strong BCDR plan, of course, you’re going to need metrics.

Why You Need to Set and Track Metrics for Your Disaster Recovery Plan

Metrics offer business leaders important and accurate information about their organization and its processes, from marketing to IT. Applying metrics to your business continuity and disaster recovery plan objectives is just as important – if not more so – as this data offers disaster preparedness. Metrics, as part of a BCDR plan, help organizations to:

• Monitor the current state of IT
• Identify potential issues
• Prescribe corrective action
• Measure the results

Through BCDR metrics, organizations can create pre-defined IT processes, requirements for them, and identify objective variances from their goals. This makes BCDR metrics the basis for improvement, helping to estimate and eliminate operational vulnerabilities and downtime impacts. In addition, metrics offer insight into IT efficiencies and compliance with regulations and conformance to standards.

Two important disaster recovery plan metrics that comprise any solid BCDR plan are RTO and RPO.

What is RTO?

RTO is the Recovery Time Objective. It requires calculating how quickly you need to recover operations so you can determine what preparations will be necessary.

What is RPO?

RPO is the Recovery Point Objective. It requires determining how much data you can afford to lose to determine the frequency of data backup.

What is the Difference Between RTO and RPO?

Since RTO is the timeframe in which applications and systems must be restored following a disaster, IT leaders should be measuring RTO from the very moment an incident occurs, not from the moment that their team begins correcting the issue. This approach provides them with knowledge of the exact point at which users start to be impacted.

On the other hand, RPO looks at how much data an organization can lose before it begins to impact business operations. For example, consider an online retailer. Now, not all are created equally. For a small mom-and-pop operation with only a handful of orders coming in per day, a few hours of lost data may not cost them any business at all. So, conducting data backups a couple of times a day may be fine; however, for a behemoth like Amazon, two hours of downtime could be devastating for their eCommerce and to their reputation, so backups may be needed on the minute.

So what do RTO and RPO have in common? Ideally, the numbers should be as close to zero as possible. Of course, the closer they are to zero, the greater the investment in IT experts, software, or other equipment will be.

Defining RTO vs RPO Values

As our earlier example illustrated, recovery time and point objectives (RTPO) are not one-size-fits-all. Organizations are different in size and industry; for example, while that small retailer may be able to play loosely with its metrics, a hospital – where lives are at stake – likely cannot afford any downtime.

That said, one common disaster recovery strategy is to divide applications and services into various tiers and set RTPO values according to the service-level agreements (SLAs) that they have committed to.

By classifying the protection of data, organizations can identify the best method of storing, accessing, protecting, recovering, and updating data based on specific criteria to mitigate damages. For example, an organization may opt for a three-tier BCDR model:

• Tier-1: Mission-critical applications requiring an RTPO of less than 20 minutes
• Tier-2: Business-critical applications requiring RTO of 1 hour and RPO of 4 hours
• Tier-3: Non-critical applications requiring RTO of 8 hours and RPO of 24 hours

To create these tiers, an organization would need to closely examine their applications and services to identify which drive the business, generate revenue, and are essential to operations. This is called business impact analysis (BIA), and it all comes back to – you guessed it – metrics.

Lower Your Downtime with Thrive

Once you’ve ranked your applications and services to determine the impact they will have on your business, you may be looking for a way to protect them. Look no further than Thrive. We offer a safe and secure path to the cloud, with bundled or customized options, and are hyper-aware of the devastating effects of disasters and downtime. That’s why we:

• Are located away from coastlines, outside flood zone/wind-blown debris zone in CAT 3–CAT 5 Hurricane-rated structures with fire protection
• Use redundant N+1 generators, Uninterrupted Power Sources (UPS) and Computer Room Air Conditioning (CRAC) Units
• Use dual authentication security (HID, PIN, and/or biometric), motion security cameras, and have alarmed man-traps

Contact the experts at Thrive to discuss your disaster recovery plan options.