The 4 Disaster Recovery Planning Steps You Can't Afford to Skip

Disaster recovery planning is one of those things that often falls into the same category as diet and exercise. Yeah, I know it’s important to eat healthy… but it’s so much easier to throw a couple nutrient-packed Hot Pockets into the microwave and catch up on the latest episodes of Judge Judy (or whatever you’re into). In reality, those little grease balls are probably doing more harm than good, and my body would surely see more benefit from a little P90X rather than sitting on the couch. *Disclaimer – I’m not a doctor, and I happen to enjoy Hot Pockets.

Rather than merely assume the best, we encourage our customers to test their assumptions and walk through a comprehensive disaster recovery plan with the key stakeholders in their organization. In our ever-changing world of IT, being passive is no longer something we can afford. We must proactively know the cost of data center downtime and put a plan in place that ensures business continuity and enables task workers to know exactly what to do when disaster strikes.

IT disasters are unpredictable, but your recovery plan shouldn’t be.

Before we begin developing a DR plan, there are a few things we must consider. It’s vitally important that we engage the right people, ask the right questions, and follow a process that is proven to work. That process can certainly vary depending on the firm, but the overarching principles remain the same.

So without further ado, here are the first four steps we recommend businesses follow when building a business-oriented disaster recovery plan:

1.  Conduct an asset inventory

Yes, it probably goes without saying, but you can’t start planning without first knowing what your environment looks like. This is where you’ll want to collect information on all IT assets. Which applications is the business running? Are there any dependencies inside this system? There’s a great table in our latest e-book that shows what this looks like.

 2.  Perform a risk assessment

Once you’ve mapped out your infrastructure and identified dependencies, this is where you answer the question of “what if” X, Y or Z happens. Regardless of what causes the outage, what’s the risk of, say, your Exchange server crashing? This is also where you’d want to assume the worst and plot out the risk of an entire location going dark. Do you have satellite sites? Can you replicate and fail over between your locations?

 3.  Define the criticality of applications and data

At face value, this one’s pretty simple. Your company’s SQL database is more important than your co-worker’s secret BitTorrent server. However, this step shouldn’t be skipped or quickly worked through. Restoring business-critical applications requires you to first understand which ones are actually critical, and more importantly, gain mutual agreement on the level of criticality across business units. This would likely include application owners, business leaders and IT.

 4.  Define Recovery Objectives

Here’s where a lot of people get tripped up. We oftentimes see IT pros set recovery objectives without consulting application owners and business line managers. Guess what happens when your IT-defined SLAs don’t match the business expectations? Not a great place to be. It’s important we set our objectives collaboratively to ensure our plan is effective.

Hopefully this is useful information regardless of whether you’re interested in disaster recovery planning. We believe there are nine steps total, and each one is explained in the below e-book. We’re very excited to release this new installment of our e-book series. It’ll cover all the steps in a business-oriented disaster recovery plan, as well as some of the tools and techniques associated with completing such a project. This is one you won’t want to miss – it’s jam-packed with great info. Download your free copy today!

 


P.S. If you missed the first installment of this e-book series (Downtime Costs How Much? Calculating the Business Value of Disaster Recovery), you can download it here

Anonymous