Got Critical Data?

With modern business dependent upon technology availability, it’s no wonder your leadership may be pressuring you to implement a successful IT disaster recovery (DR) solution to guard against downtime. Yet, some IT departments are taking shortcuts in implementing and managing their DR solutions – which puts companies at major risk. To prevent making these mistakes yourself, it’s important to learn from other’s failures.

Here are five worst-case pitfalls to avoid, so you can ensure a smooth and effective recovery of your most crucial data and IT systems.

1. Only Planning for Select Types of Events

There are a several types of events that could trigger the need to execute a full or partial failover. For this reason, you should prepare for the traditional natural disasters, like fires and power outages, but also more newly-recognized threats like human error, cyber-attacks (such as ransomware) and hardware failures.

• Do this instead: Consider everything that could likely and unlikely happen to your business and plan accordingly. Begin doing this by performing a full assessment of all technology dependencies. What applications must be recovered first, second and so on and so forth? After you have catalogued every application by order of importance, look at how they can be protected to ensure quick uptime. Your DR strategy should cover everything from a full datacenter failover to a single application failover.

2. Not Having a Regular Testing Schedule

A survey of the legal industry, conducted by Bluelock (now InterVision) and ILTA, found that 62% of IT professionals didn’t know what testing methods they used or didn’t test at all. Has your DR plan been tested? If not, good chance your IT team will be clueless when a disaster strikes. Plus, if your IT environments have changed, different steps may be required to protect everything in the recovery process.

• Do this instead: Test your DR plan! If you are already testing it, make sure to test it more than once a year. Also try multiple methods of testing, like sandbox, tabletop and full failover, all of which help to double-check that you can recover during a real event.

3. Going Without Detailed Recovery Plan Documentation

Too often, companies do not have a written plan and instead, rely on IT personnel to be the point-of-contact for knowing what to do when an event occurs. For those companies that do have a written plan, it’s too common that these plans assume key personnel will be available to execute the plan. This is evident in the language of the plan itself, presuming the reader has an intense knowledge of your IT systems. The problem here is that, if your city is wiped out by a tornado for example, odds are those IT personnel will be more concerned with their families than recovering your company data.

• Do this instead: Write a detailed recovery process and document it in written form. This runbook or Playbook should be written in such a way that a person without any knowledge of your IT systems can pick it up and execute your recovery strategy. Once your documentation is complete, store it in a secure, yet accessible location.

4. Having Recovery Plan Documentation, But Not Updating It

Why test a DR plan and not learn from it? Adjust your playbook with any changes in the testing process, so you won’t be relying on outdated information during a disaster. Think of it like putting a puzzle together with only half of the pieces and supplementing it with pieces from another set – you’re destined for confusion and failure.

• Do this instead: Gather your team after the test and talk about what went well and what didn’t. Take notes and document any changes in the playbook, and be sure to share the latest version  so people don’t have different versions during future executions.

5. Tossing All Applications into the Same Bucket

Every company has crucial applications and a budget to protect them. Every company also wants to recover their applications within a set timeframe. However, throwing every application into the same bucket and hoping for the best implies two things: either you are paying too much for recovery or you’re not fully protected.

• Do this instead: Recovery is not a one-size-fits-all solution. For this reason, ensure applications receive their proper sequence of attention by tiering them into groups of importance. Then, select a recovery solution for each group that complements your priorities and lets you stretch your budget for full coverage across the board.

DR Isn’t Easy, But You Need to Do It Right

An IT disaster recovery plan’s implementation, maintenance and testing are complex and time-consuming tasks, but doing them right will yield monumental rewards when a failover is necessary. If your IT team is busy with other projects and doesn’t have the time to focus on avoiding these DR pitfalls, perhaps enlist a third-party provider of Disaster Recovery as a Service (DRaaS) to serve as an extension of your IT team. This way, you’ll receive assistance for the day-to-day management and execution of your DR strategy.

If you’d like to learn more about DRaaS or speak with an expert about your DR plan, contact InterVision.