7 Things to Think About Before a Disaster Hits

Featured article by Jake Robinson, Solutions Architect at Bluelock

Hindsight is 20/20. It’s easy to see where the gaps in your disaster recovery plan are after you’ve recovered. But, hindsight could be too late to save crucial systems that are required for your business to operate at its highest level.

So, what are the most important to consider before a disaster hits that will save your systems?

Here are seven questions to ask yourself that could help you better protect your applications if 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 is always, “yes.”

You should always have a disaster recovery plan. While that plan may not involve recovering every single workload if some are expendable, you will need to at least perform a risk assessment and a business impact analysis in order to have the most complete DR plan.

That doesn’t, however, mean each application’s recovery plan is the same level of complexity or importance. If your application is currently hosted as SaaS, most of the time the DR plan and the BC plan is built into the service itself. Focus most of your energy and time on a plan for applications you are hosting in-house, with PaaS and with 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 significant time investment. You may not know what apps are the most critical without interviewing each business unit and discovering where their core applications.

Each business unit should have it’s own DR plan, in addition to the company’s overall DR plan.

Don’t be afraid to get too granular. In order to decide which applications take precedence you need to perform a risk assessment and a business impact analysis for every single application.

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 ideal RPO (Recovery Point Objective). RPO refers to the time point in the past from which all your data will be recovered.

Every application is unique. If you’re in the banking industry you can’t afford to lose transactions. It will be important to have the smallest RPO as possible so you don’t lose those upon recover. If your website has a low rate of change and is only updated once a week or less, you would be able to afford a much longer RPO, saving you money on your recovery solution.

4. How quickly do I need to recover?

You will also determine how quickly you need to recover in your risk assessment and business impact analysis. Referred to as your RTO, or Recovery Time Objective, this is the amount of time it will take to stand your application back up.

Pre-virtualization RTOs were dreadfully long. If a piece of hardware failed and there wasn’t a spare in the back room, the supplier would need to be called. If they didn’t have it, it would need to be ordered. It wasn’t uncommon for an RTO of 14 days. Some businesses never recovered after being down for so long.

With virtualization, however, we’ve decoupled apps from hardware and RTOs are now minutes and seconds, not days and weeks. 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 will have different RTO and RPO needs. 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 will I recover?

For enterprises with multiple offices, a typical solution is to have infrastructure capabilities in each location acting as DR for each other. For businesses who don’t have the luxury of multiple offices and infrastructures the historical solution was to replicate to collocated equipment with a company you trust, or in a community DR-set-up.

The downside with colocation DR is that it tends to get costly from a capital investment standpoint. You need to buy the equipment and it’s going to sit there most of the time, unused. You need 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, referred to as Recovery-as-a-Service, or RaaS. 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. 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. 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 premium 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 if that is in line with the recovery needs of your applications.

Be realistic when performing your business unit interviews, risk assessments and business impact analyses. 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. Proper planning and analysis will save you time, money and maybe 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.