How to determine your disaster recovery objectives (original) (raw)

Article 1 of 3

Part of: Determine recovery objectives for DR teams

Ideal recovery objectives are different for every business. Luckily, there are four basic steps you can follow to ensure you set the right RTO and RPO.

Determining how often to back up critical data, applications and systems depends on how you want recovery to run. Generally speaking, there are two guiding disaster recovery objectives to consider when creating a DR strategy: Recovery time objective, or RTO, and recovery point objective, or RPO.

RTO specifies the amount of time it should take to have the system back up and running. So, if your RTO is 45 minutes, your intent is to have the recovery completed within that time frame.

RPO specifies how far back the recovery goes. In other words, how much data are you willing to lose? For example, if a server were to go down right now and your RPO is 30 minutes, you're planning on recovering from a backup made 30 minutes ago.

There can be some confusion around setting these two disaster recovery objectives. Should they match? Can one be higher than the other? In what circumstances would they differ? The confusion with RTO and RPO often comes from not properly defining them, as their relative value to one another is completely unimportant.

How to determine RTO and RPO

You can define your disaster recovery objectives in four basic steps.

Start with the business. From an operations perspective, the business has certain expectations about the availability of specific data, applications and systems. Start discussions with the executive team, line of business owners, application owners, etc., about what their availability needs are.
Define downtime per data set. For each application, set of files, system or combination thereof, have the executive team share how the business will be impacted if each is unavailable. Let them decide what kind of downtime and data loss the business can accept. When you're done, you should have a comprehensive list of the entire environment's recovery needs.

RPO and RTO

RPO vs. RTO

Translate this to disaster recovery objectives. In essence, these discussions should provide the context needed to establish RTOs and RPOs for every part of the business. For example, if the executive team says it can't be without on-premises email for more than an hour and can't lose more than 30 minutes of data, you know you have an RTO of 1 hour and an RPO of 30 minutes.
Consider what's actually possible. Despite the fact that the executive team may have certain objectives, those may not be compatible with your current backup and recovery infrastructure. Take your objective requirements, compare them with what's possible and establish attainable objectives. You should also go back to the executive team to show them this gap and ask for a higher budget, citing the business needs not being met with the current infrastructure.

By following these four steps, you'll know exactly what the business requires, what your recovery goals look like and whether you'll be able to achieve them.

Next Steps

Develop a backup KPI to improve performance

Dig Deeper on Disaster recovery planning and management

Part of: Determine recovery objectives for DR teams

Article 1 of 3