RTO vs. RPO
The abrupt pause in business activity that we’re all facing due to COVID-19 goes far beyond the typical summer slowdown that a lot of businesses experience annually. However, it doesn’t have to be all bad. Take advantage of this lull to work on your business, rather than in it.
At Alexant, we encourage our clients to add assessing disaster recovery protocols onto that list of things to do when business is slow—as it will save you money and reduce stress in the long-run. One of the first steps in this process is to consider two guiding disaster recovery objectives: recovery time objective (RTO) and recovery point objective (RPO).
Although there are several similarities between RTO and RPO, there is one big difference: their purpose. RTO deals with systems and their applications, and primarily describes time restraints on their downtime; while RPO has to do with the amount of data lost when a disaster occurs.
RTO is the amount of time it should take to get your system running again. For example, if your RTO is 1 hour, your goal is to make a complete recovery within that timeframe. On the other hand, RPO defines how far back a recovery goes. For example, if your server were to crash and your RPO is 1 hour, your plan is to recover a backup created 1 hour ago. So, in a sense, it’s the amount of data you are willing to lose in the event of a disaster.
Business owners are often confused when they encounter these data recovery objectives. They usually wonder if the numbers should match, if one should be higher than the other, or under which circumstances should they differ. However, RTO and RPO’s relative value to one another is, in fact, unimportant; and the “correct” number for these objectives depends on the unique needs and desires of your business.
What are the benefits of RTO?
Determining RTO is beneficial to your company because it forces you to develop a course of action in the event of a disaster. You see, RTO is not simply the amount of time that you expect between loss and recovery. It also encompasses the steps your IT team must take to restore systems, applications and data.
A few of your applications may be able to stay down for days without significant damage to your business. On the other hand, some high priority applications can only go down for mere seconds before causing employee irritation, angry customers and loss of business. Let’s look at a couple examples:
RTO in Action
Ecommerce Site. A retail business’ self-hosted e-commerce site relies on three databases: a relational database that stores the product catalog; a document database holding order data; and an API database that connects to the payment processor’s gateway. The document database is able to recreate data from other databases so its RTO and RPO are both under 24 hours. The retail store only adds products to their relational database once per week, so RPO is not critical. However, RTO is critical because if the database goes down, then customer transactions cannot be completed.
Granular Item Recovery. Imagine an employee accidentally deletes a time-sensitive email and then empties his trash folder. Because Outlook is a business-critical application for this company, IT is continuously backing up changes in the email app. Their backup application is capable of granular backup and recovery, allowing IT to retrieve and restore the individual email within an RTO of a few minutes instead of recouping an entire system in the effort to obtain a single message.
What are the benefits of RPO?
RPO refers to your loss tolerance: the amount of data that your business is able to lose before incurring any significant harm. Like RTO, this objective is presented as an amount of time, measured from the last completed back up to the loss of data.
The more data a business loses, the greater the disruption there is to that business. Therefore, RPOs that minimize data loss contribute to the seamlessness of business continuity and make businesses more resilient.
Determining Your Disaster Recovery Plan
Objectives for data loss protection and recovery are unique to each business. But once you understand disaster recovery protocols, your business can determine your unique disaster recovery plan in three easy steps:
1.Understand business goals.
Determine the expectations and needs your teams have for the availability of data, applications and systems.
2.Establish acceptable downtime for each data set.
Go through each system, application and file and determine how your business will be impacted if each is unavailable. Then, determine how much downtime and data loss the business can accept. This process will leave you with a list of your recovery needs.
Your team must then consider what is actually possible. Although you may have certain expectations of disaster recover, those expectations may not be compatible with your existing backup and recovery infrastructure. Compare your recovery needs to what is actually possible with your current system and establish realistic objectives.
3.Translate what you know to RTO and RPO.
Turn those realistic objectives into RTOs and RPOs for every part of your business. For example, if you cannot be without email for more than 2 hours and cannot afford to lose more than 10 minutes of data, then your RTO is 2 hours and your RPO is 10 minutes.
Once you have created a disaster recovery plan you will know what your recovery goals look like and how to achieve them. If your recovery needs are greater than the established objectives, you know that you need to look at investing more capital into your current infrastructure.
With extensive knowledge on data loss prevention, Alexant is the go-to expert consultant for helping your company translate disaster recovery objectives into a realistic and fool-proof plan.
Establish Your Company RTO/RPO Plan now.