Despite popular beliefs to the contrary, disaster recovery (DR) tools and technologies by themselves aren't enough to make effective DR a reality. The other half of the DR equation involves effective planning, testing and execution. Unfortunately, some IT managers take an overly simplistic view of what's required for a successful disaster recovery procedure. Here are some common misconceptions and pitfalls to avoid as you embark on...
your DR planning journey:
Disaster recovery planning pitfall #1: The belief that DR tools and technology will take care of your DR challenges. While tools and technologies are an important enabler, they cannot do the job by themselves. To be effective, their use must be governed by a coherent and well-defined disaster recovery plan.
Pitfall #2: Lack of sufficient planning upfront. We have seen some small- to medium-sized businesses (SMBs) charge ahead with various DR initiatives, only to find that not all of the pieces are in place to make their DR intentions a reality. For example, a snapshot-and-replication approach can enable an organization to protect its production virtual servers, but only if it has the administrative resources and processes in place to manage the images at the remote site. In the end, a set of DR practices will only be as effective as the plan they are based on.
Pitfall #3: Setting overly ambitious goals. While passion and enthusiasm are important ingredients for launching and sustaining a disaster recovery procedure, these ingredients should be tempered during the objective-setting procedure. While goals should not be set too conservatively, they should still be achievable given the resources and expertise available. The objective-setting process should also account for the possibility that DR preparedness may take a back seat, at least temporarily, to projects with a higher near-term payoff, such as expanding production-level infrastructure to support growth or higher demand. We are aware of a number of SMBs whose DR initiatives got off on the right foot, only to flounder due to disappointing progress and resource constraints later in the process.
Pitfall #4: Not investing enough time and resources in testing and documentation. You should test your disaster recovery plan, both as the infrastructure is being built and as the processes are later put into production. Processes should also be re-tested for reliability and performance upon significant changes to IT infrastructure, such as the deployment of new data storage arrays or applications. Detailed and up-to-date documentation is the lifeblood of any DR initiative, and is absolutely crucial in the event of an actual outage or large disaster. Proper documentation will allow all participants to understand their roles along with the hundreds of operational details that make recovery possible.
Pitfall #5: Assuming "you're done" once the initial DR plan and procedures are in place. Disaster recovery must be viewed as a living and breathing process. The DR infrastructure and process must constantly evolve to accommodate shifting organizational priorities and the ever-changing demands of a growing business.
About this author: Jeff Byrne is a senior analyst and consultant at the Taneja Group, an analyst firm focused on storage and storage-centric server technologies with a concentration in the developing area of virtualization. He can be reached at firstname.lastname@example.org.