DRJ Spring 2020

Conference & Exhibit

Attend The #1 BC/DR Event!

Winter Journal

Volume 32, Issue 4

Full Contents Now Available!

Monday, 19 August 2019 21:22

What Companies Get Wrong About Disaster Recovery

Written by  ERIC DYNOWSKI

Dynowski1

Disaster recovery is tricky. It’s not sexy, it’s not exciting, and it’s more or less invisible until something is really wrong. No wonder so many companies are missing the mark when it comes to DR. Out of sight, out of mind.

One of the big problems with DR is that it’s easy to have a false sense of security: 95 percent of businesses have a DR plan, according to a recent study. That’s great, right?

Not so fast.

Twenty-three percent of those companies admit to never testing their plans. Another 29 percent claimed to test “every couple of years,” which, in DR testing time, is about the same as never.

This is a problem. Even when we test DR plans every quarter, we always find variables which need to be changed: new functionalities to account for, new applications that have become critical to business operations, new policies to adapt to, and so on. The point is, if you have a disaster event even one year after putting together a plan – without having tested it in the interim – you will likely be totally out of luck.

This may sound grim. To be even grimmer: failing to regularly test is not the only mistake companies make with their DR plans.

Now for the good news: all these problems are solvable. Here are four things businesses commonly get wrong about disaster recovery and how they can shift course to make sure their backup plans are ready to support them in a crisis.

1: Not Getting C-Suite Buy-In for DR

Solve this problem, and you’ll have a much easier time addressing all the others. Briefly, leadership buy-in for DR matters because, to be effective, DR has to be a full-company effort. That means IT leaders need the support and help of leaders from every other part of the company – and if they aren’t hearing from their bosses that disaster recovery is a priority, they’ll get back to you approximately never.

And who can blame them? As I mentioned, DR is not something we need every day. It’s important but never urgent (until, of course, it is).

One of the most valuable things IT leaders can do is to convince the C-suite that disaster recovery is a financial imperative for the company as a whole. To do that effectively, IT leaders should…

  • Treat it as a process: leadership and priorities change, meaning someone you’ve convinced of DR’s value may leave and be replaced by someone who thinks DR is a needless expense. That’s part of the process.
  • Put it in financial terms: The whole point of disaster recovery is to prevent unnecessary business losses. Help C-suite leaders understand the exact dollar amount that’s at stake when your business goes down, and you’ll have an easier time advocating for your DR budget, even in the face of larger budgetary changes.

That second point leads me to the next common mistake I see with DR plans.

2: Not Tying DR to Business Outcomes

This is a two-part issue: first, when you don’t tie DR to business outcomes, you’ll have a harder time getting buy-in from leaders and others in your business who need to participate to make it work (think everything from budget approval to testing).

The second reason it’s important to tie DR to business outcomes is that, in the absence of external guidance, IT teams have a tendency to get too creative with their solutions.

Too creative, you’re saying? How can that be a problem?

It becomes a problem when the very smart people in charge of building and maintaining a company’s IT systems seek ways to make sure every part of those systems is able to withstand an outage – regardless of how important any individual system is to the functioning of the business as a whole.

It becomes a problem, in other words, when you build a DR plan which is more robust than what your business requires because it inevitably means it’s more expensive than it needs to be.

The typical measures here are RTO and RPO: the time your business can survive offline without serious damage being caused and the time you can afford to go between backups. Your DR plan should aim to get you back online within that time frame, and your backup cadence should happen at intervals no greater than your RPO.

It is important to remember not all applications are going to have the same RTO / RPO values. Each application will have different requirements that make a one-size-fits-all DR strategy either too much or too little.

Said differently, your DR plan should be right-sized. It should allow your business to carry out essential functions and avoid revenue loss – but not more than that.

3: Not Testing

I mentioned this above, but it bears repeating: DR plans are worthless unless you test them regularly. I know it’s a hassle to coordinate everyone and everything you need to conduct a test. I also know it’s hard to fit a test into your schedule when you have a hundred other more-pressing deadlines.

That’s why it’s so important to get your C-suite on board with DR from the beginning. When a company’s top leaders are invested in the outcomes of DR testing, that testing becomes a priority for everyone. It becomes much easier to convince the heads of marketing and sales to lend you a few team members for testing. You’ll have fewer people cancel last minute on DR-planning meetings.

Another helpful strategy for making sure DR testing happens is to make it part of someone’s job. When a person’s performance assessment (and compensation) is tied to the outcomes of DR tests, those tests are much more likely to happen.

4: Not Updating a DR Plan

Every time a company’s operations change, its DR plans need to adjust.

Just as buying new property or a new car requires an update to your insurance policy, adding new functionalities or shifting to a new CRM should trigger an update to your company’s DR plan. A DR plan built for an outdated version of your company’s operations won’t do much good if anything other than that version faces an outage.

Again, getting leadership buy-in makes this process easier – because it is, in fact a process. Too often, updates are neglected because the IT team creates a DR plan as a way to quickly meet the needs of an auditor or check off a compliance requirement. In reality, the DR plan should be a living, breathing document which is maintained as the business evolves.

Getting DR Right

Consistently hitting the mark with DR will require an internal culture that values disaster recovery. If that doesn’t yet exist in your organization, your first step should be to figure out how you can spark a cultural shift. Remember: the facts are on your side. Eighty-seven percent of large businesses experienced an outage of some kind in the last year, along with 79 percent of mid-sized businesses and 71 percent of small firms.

It’s not a matter of if your organization will experience an outage, but when. When it does, having a DR plan that actually fits your needs can make a world of difference in your business outcomes.

Dynowski EricEric Dynowski is the chief technology officer at ServerCentral Turing Group (SCTG). SCTG offers cloud-native software development, AWS consulting, cloud infrastructure, and global data center services.