Today's Corporate Disaster Recovery Plans Should Begin with a Plan to Automate DR

A company is now more likely to use disk as part of its backup process and deduplicate backup data as it is stored to minimize capacity requirements. This combination of technologies should result in marked improvements in backup and recovery success rates. But disk-based backup, deduplicated data stores and successful backups and recoveries do not necessarily translate into a successful disaster recovery plan. All it means is that long broken backup processes are working and the company can finally turn its attention to recovering its business.

The entire focus of the aforementioned SearchDataManagement article is to enlighten companies as to why disaster recovery plans fail. "Backups not working" appears as point 8 in the article though it should probably be the first point. Until a company verifies it is successfully protecting its data, it makes no sense to develop a disaster recovery plan of any kind. If anything, it underscores why companies are putting so much money and effort into disk storage systems to ensure that their backups complete successfully.

But overall this article is on target in that it astutely points out that there are many other aspects of a disaster recovery plan that a company needs to execute on beyond just having good backups. Lack of people, inadequate planning, no cooperation between departments and insufficient money and time are all reasons that can still preclude a disaster recovery plan from succeeding even when backups complete successfully. In fact, if one reads through the reasons as to why DR plans fail, one has to question if any company can confidently recover its business given all of the variables that it must manage and account for when developing a DR plan.

As anyone who has ever worked for any size company knows, executing on all of the details required to deliver a working enterprise wide DR plan is often an exercise in futility, especially if a high degree of manual intervention is required. The only DR plans where I have witnessed consistent success in recovering data is when the companies implemented some level of automation as part of the DR plan. Of course, this option was generally high cost and limited to just a few high end applications so companies often did not extend this DR option to the majority of their applications.

This is why any company that is serious about recovering its business should begin to look beyond just fixing its backup problems and instead seek to automate DR for as many of its application servers as possible. To do that, a company first needs to select software like InMage Systems' DR-Scout that offers it the means to not only protect the data on its production application servers but also automate the recovery of data either locally or remotely.

What further makes DR-Scout unique is that it supports both Linux- and Windows-based servers as well as virtual machines found on VMware ESX, Citrix XenServer and Microsoft Hyper-V hosts. Supporting this combination of operating systems provides a company with a means to automate the recovery of the servers that they are most likely have in-house without needing to spend inordinate amounts of time or money to implement and manage the process.

The SearchDataManagement article that appeared over three years ago was right on in its assessment of why DR plans fail. But to conclude as it did that these problems can be overcome with better manual processes is a bit idealistic. Companies are far better served by admitting up-front that the best way to deliver a workable DR plan is to automate it from the outset and take as much of the human factor out of the equation as possible for as many of its application servers as possible. By making InMage Systems' DR-Scout part of its DR plan, companies can accomplish that exact objective.