Hindsight is 20/20, and it’s easy to see where the gaps in your disaster recovery plan are after one hits. However, hindsight can be too late to save crucial systems that are required for your business to operate at its highest level.

We asked Bluelock Solutions Architect Jake Robinson to list the things that would be most important to consider before a disaster hits. After listing off the obvious like saving the lives of those around you, knowing your fire escape plan and calling 9-1-1 for assistance, he honed in on seven things to think about today that will help you better protect your applications when disaster strikes tomorrow.

1. Do I need a DR plan?

This question may be asked before you embark on a journey to plan your perfect DR scenario. “The answer,” Robinson explains, “is always, yes.”

You always need a DR plan,” he continues. “That plan may involve not recovering all workloads if there are any expendable to you, but you always need to perform a risk assessment and a business impact analysis in order to have the most complete DR plan so you don’t forget any of your critical workloads.”

That doesn’t, however, mean each application’s recovery plan is the same level of complexity or importance.

“If you’re application is currently hosted as SaaS, a lot of times the DR plan and the BC plan is built into the service itself,” Robinson explains. “Focus most of your energy and time on a plan for applications you are hosting in-house and with PaaS and IaaS.”

2. Which applications should I recover?

“If you’re in an enterprise IT setting, figuring out which applications need to be recovered requires a lot of interviewing,” Robinson explains. “You may not know what apps are the most critical without interviewing each business unit.”

Each business unit can have it’s own DR plan, and each application within that business unit can have its own DR plan as well.

“Don’t be afraid to get too granular,” Robinson says. “In order to decide which application takes precedence in a recovery situation you need to perform a risk assessment and a business impact analysis for every single application in advance of a disaster.”

3. How much data can I afford to lose?

After you complete a risk assessment and business impact analysis for each application, you should be able to understand your RPO.

RPO refers to Recovery Point Objective, or, the point in time at which all your data is recovered up to that point.

“Every application is unique,” explains Robinson. “If you’re in the banking industry than you really can’t afford to lose database transactions. It will be important to have as little RPO as possible so you don’t lose those upon recover.”

“On the other side, however, your website has a low rate of change and may only be updated once a week or once a month,” Robinson continues. “You would be able to afford a much longer RPO, which will save you money with your recovery solution.”

4. How quickly do I need to recover?

Also determined in your risk assessment and business impact analysis is the answer to how quickly you need to recover. Referred to as your RTO, or Recovery Time Objective, this is the ideal time that your application will be back and running at 100%.

“RTOs pre-virtualization were dreadfully long,” Robinson shares. “If a piece of hardware failed and we didn’t have a spare piece of hardware in the back room, we’d have to call the supplier. If they didn’t have it, we’d have to order it. It wasn’t uncommon for an RTO of 14 days. Real people lost their businesses and some never recovered after being down for so long.”

“With virtualization, however, we’ve decoupled our apps from hardware and RTOs can be minutes and seconds, not days and weeks,” Robinson says. “With something as simple as losing a physical server, VMs can be automatically brought up on another host by using VMware vSphere HA, for example.”

Each application can, and might, have a different need for RTO and RPO. That’s why a risk assessment and business impact analysis should be performed on each individual application. In order to be cost effective and efficient, you’ll need to prioritize which applications can have longer RTOs and RPOs, and which you’ll need to spend more for faster recoveries.

5. To where do I need to recover?

For national enterprises with multiple offices, the typical solution has been to have infrastructure capabilities in each location so they act as DR for each other. For those businesses who don’t’ have the luxury of multiple offices and infrastructures, the common solution has been to replicate to collocated equipment with a company you trust, or in a community DR-set-up, and recover to that system.

“The downside with colocation DR is that it tends to get costly from a capital investment standpoint,” Robinson warns. “You need to buy the equipment and it’s going to sit there most of the time, unused. You’ve got to maintain the equipment, so there’s upkeep expense and you still need to figure out a replication software solution.”

“The latest trend, however, is cloud-based DR, which is referred to as Recovery-as-a-Service (RaaS),” Robinson explains. “The promise of cloud-based RaaS is that you only need to pay for the storage and the bandwidth which comes to a fraction of traditional DR costs. Then, when you failover, you pay for only what you use. And, with many cloud-based RaaS providers, they help make the replication a turnkey process.”

6. How do I return to normal functionality?

“This is one of the most important questions, but it doesn’t get asked nearly enough,” explains Robinson. “It’s great if you can recover to a colo or cloud-based RaaS solution, but until you are back up and running in your home environment with normal operating function, your DR plan is not complete.”

“If your replication solution does not support failback, then you may need to be running in DR mode for longer than you expected,” Robinson cautions.

Be sure to ask the question with both your DR solution and your replication solution, or you may find yourself with quite a headache after the disaster is over.

7. How much does it cost?

Everyone wants zero RPO and RTO, but, just like an insurance policy, the more coverage you have, the higher your deductible will be. The basis economic reality is that not everyone will be able to afford a low RTO and RPO for every application.

It’s not a matter of how much it costs, but rather, how much can you afford to pay and is that in line with the recovery needs of your applications.

“Be realistic when performing your business unit interviews, risk assessments and business impact analyses,” Robinson explains. “Really look at your worst case scenarios and decide ahead of time what your premium will be.”

You can’t predict the future, and you can’t know what will happen when a disaster strikes, but proper advance planning and analysis will save you time, money and potentially even your business when a disaster hits. The more time you take to plan today, the fewer problems you will have recovering from a disaster tomorrow.