Building a disaster recovery site can be an exciting project for ambitious IT teams. It involves a great deal of planning and results in a high degree of satisfaction once the environment is complete, the budget is justified and the equipment is procured and configured. Overall it is a gratifying experience– until it’s time to test the solution.

I’ve been writing about the hidden hazards of do-it-yourself disaster recovery. One of these hazards is hardware/software drift. Since your disaster recovery site represents a working replica of the production environment, it will need to be maintained on an ongoing basis. There are several strategies for how hardware and software are provisioned for your DR site. The strategies you choose will determine the how much maintenance will be needed to keep your DR site running at an optimal level.

Choosing a disaster recovery location is critical to the success of any DR project. One of the biggest mistakes that you can make is to choose a colocation site that is too close to your production site. It’s way too easy for a power grid failure to knock out both your primary and your colocation site if both sites are located in the same metropolitan area. (It happens!) But the challenge of in-house DR is that the technical team responsible for bringing your DR site online will need access to that site. This means that the approach and technology used to deliver a disaster recovery solution must be capable of remote activation. Learn more about remote activation in the nScaled white paper The 5 Things That Can Go Wrong With DIY Disaster Recovery: 5 Things That Can Go Wrong With DIY DR

It might be tempting to create a “do-it-yourself” disaster recovery solution by purchasing additional hardware and installing it in a branch office or colocation facility. But creating an effective disaster recovery solution is a complex project and there are several unplanned costs and other hidden hazards associated with it. I’ll identify some of these hidden hazards over the next few weeks.