You’re Not Ready For Disaster Recovery, Despite What You May Think

You’ve covered all the milestones, including:

• Performing a Business Impact Analysis (BIA) to determine the recovery times you’ll need for your applications.
• Tiering your applications and documenting their interdependencies so you know which order your servers should be restored in.
• Putting your recovery infrastructure in a geographically-diverse data center.
• Created a comprehensive recovery playbook and tested each and every step.

Bring on the storms … the floods … the power outages … you’re ready. But are you really?

Here’s the catch: your applications and IT environment are dynamic. New applications are developed. Network topologies are simplified. LAN speeds are upgraded. Operating systems are patched. New security protocols are implemented. Do you have a process in place to ensure that your DR environment keeps up with all the changes that are constantly being made to your production environment?

Unfortunately, if your company is like most enterprises, you’ve got a problem—with the massive work of establishing a DR plan behind you, your team is likely focusing on activities that will drive revenue to your company. While this is obviously important, it makes it difficult to give your DR plan the ongoing attention needed to keep it in line with the improvements you are even now making to production IT.

Here’s the question you have to ask yourself: If you have to declare a disaster, will you be able to meet your recovery time objective if your target DR environment is no longer current?

Perhaps. Perhaps not.

Right now, you might be thinking, “Great … I thought we finally had the bulk of DR behind us, and now we have to dive into it again!”

If you’re feeling frustrated, don’t worry. There are solutions to this quandary. The first is that you can assign internal resources to maintain your DR environment and keep it aligned with production IT. Your people have been through the DR implementation process: they know your business, they know your systems, and they know your plan. They can do it.

The only problem with an in-house solution occurs when you need to apply those internal resources to other strategic business initiatives. In that case, you are faced with the problem of people not being able to be in two places at once. Splitting a resource between two directives too often results in both projects being performed at less than maximum effectiveness.

If you are strapped for internal resources, giving the task of DR upkeep to an outside provider can make a big difference. A good disaster-recovery-as-a-service partner will work with you on an ongoing basis to ensure that your DR environment evolves along with the production environment. They will interface with your change management team to record any updates you have made and reflect those in your DR plan. They will periodically review your assumptions and requirements to ensure that they are still current. They will ask questions such as: Have your RTOs and RPOs changed? Have you virtualized any of your environment? Are there new regulations you have to adhere to? Have you updated your OS levels?

By working with DR experts at a recovery service provider, you will save time and money because you won’t have to pull your people off of maintaining and improving your production applications. You can stay focused on business strategy while the recovery service provider stays focused on DR strategy.

Instead of using your sleep time to worry about whether or not your recovery would be successful in the event of a disaster, you can dream up new ways to improve your IT infrastructure to bring increased revenue and productivity to your company.

In many ways, the toughest work is behind you. You did it! The BIA, the tiering, the recovery infrastructure, the playbook, the testing … you and your team deserve to feel a huge sense of accomplishment and pride. Just make sure you safeguard all that hard work by keeping your DR plan up to snuff, either by assigning it the internal resources necessary, or by calling for reinforcements. Either way, you win.

This post was first published on the Sungard Availability Services blog.