The right disaster recovery strategies can mean the difference between a swift recovery and a business-imploding
We know. Disaster recovery isn’t a fun subject. Sometimes it can
When developing functional disaster recovery strategies and plans, planners should consider these 10 ideas to ensure effectiveness:
- Don’t confine yourself to traditional methods or thoughts. For example, you may develop the documentation during an exercise while the individuals are performing the tasks. Participants can note the steps and take screen shots while performing the actions.
- Maintain risk management, conduct risk assessments, and develop a risk management culture. Your risk profile will drive changes to the defined strategies and requirements. Mitigation of risk may allow for less complex or lower cost solutions. It also creates a “risk and continuous improvement” environment vs. a “recovery is a project with an end” based culture.
- Consider whether the workarounds you use for operational incidents can be adapted to disaster situations. As long as we are dependent on technology, there will be a period of time when applications will not be available. The functional teams have workarounds in place to follow when application outages occur. They understand that everything may not be highly available. These workarounds will likely be useful until the technology has been restored. Don’t rely on those to be a longer-term solution, thinking the recovery strategy can be delayed or minimized, but think, rather, in terms of lessening the impact.
- Be adventurous in your thinking – use creativity and common sense. Sometimes the simplest solution is the best, though not necessarily the most common. For example, rather than developing a complex or automated script or process for recovering data or an environment, there may be a manual solution that is slightly longer, but easier and less risky. People are still the most effective problem solvers.
- Use group thinking to develop and review disaster recovery strategies. If you have not leveraged the individuals performing the tasks, do so. They know the details and can be helpful in providing ideas or identifying gaps in the processes.
- Infrastructure, support functions, and interdependencies are major considerations. As automation and virtualization have made our recoveries quicker and less task dependent, we have become complacent in performing detailed verification on our infrastructure and interdependencies. We assume that if the tools are “green” or successful, everything is successful. In today’s complex computing environment, dependencies and data synchronization are the areas of concern related to validation.
- Mitigation is an important recovery strategy. In today’s environment, resiliency and prevention of issues may be a more appropriate recovery strategy, rather than planning to restore at an alternate site or in the cloud.
- Strategize but don’t become committed to any single recovery strategy. Where possible, the recovery strategy will have more than one recovery technology. In the ability to use the technologies together, flexibility is important and allows for quicker adaption to business needs. An example would be using backup and restore for a database server that you recover using the virtual infrastructure. There may not be a need for replication, or even for the virtual server, but leveraging the solutions in place may be cheaper and quicker than implementing an additional technology.
- In a recovery mode, you can’t do anything until you know the type and extent of the damage and the affected environment. Include in your plan some time to assess the current situation, impacts on the business functions, and the state of the recovery sites. Include how people will access the recovered environments. Are there relocation impacts? Remember, without people or access capability, recovered systems are just power sinks.
- Educate, train, and exercise. We have discussed this in previous blogs. Hope is not a strategy. No one wants fire fighters who are not trained to respond. Don’t worry – they have read the plan on how to fight a fire, they will be able to respond to it effectively. Knowing your actual capability and providing your teams with time to practice is important to a functional program.
In the end, disaster recovery strategies and plans should be functional – otherwise they are only theoretical. If they are not functional, then your efforts will only result in checking a box, and will not fulfill the needs of the organization.
We updated this post from a previous version published in April, 2013.