Develop a Backup Plan for Your Backup Plan
Step No. 4: Develop a backup plan for your backup plan
Over the past nine years, I have been either directly or indirectly involved with over 1,600 business continuity implementations and there was always something to learn with each scenario. One such situation was planning a backup for the backup. During a disaster recovery implementation for over 70 virtual servers, the batteries of the uninterruptible power supply (UPS) that was the backup power supply for the data center ended up exploding. Because the main power supply ran through the UPS, it took out the power to the entire data center and about 40 servers that were offline. Luckily, we had just finished the implementation but hadn't actually completed the exercise training, so we had to do it as a live test.
Thanks to the brilliant engineers I work with-and the fact we had implemented these solutions a few hundred times-we were able to bring up all the business-critical systems at a disaster recovery facility within fifteen minutes. HazMat was called to begin cleaning up the contents of the exploded batteries in the data center, and we were able to recover all the data center operations to the original data center about five days later. This shows that even though you have a backup plan, you don't necessarily have a backup.
Step No. 5: Understand your business
During the initial Business Impact Analysis (BIA), the BCP team will identify and prioritize the level of protection and recovery for each of the business systems required. I have seen some companies skip the BIA and just apply the same solution to all servers; this isn't necessary and can increase the costs of the actual BCP solution. Not all servers need to be highly available with very little Recovery Time Objective (RTO) and Recovery Point Objective (RPO); only the servers that are identified as being business-critical to restoring operations to a functional level.
This is usually your messaging and communication systems, followed by internal and external-facing Websites (or any other system that services your customers and clients or allows your company to book revenue). All other systems such as file or print servers might be okay if it takes 12-24 hours to bring that back online, as long as the other systems are intact.
Step No. 6: Learn your cost of downtime
Identifying and understanding your business-critical systems during the BIA will help you calculate the cost of downtime. Putting a dollar value to the number of hours or minutes a specific system is unavailable will not only help you sell the need for infrastructure improvements to executives, it will help them understand the reality of doing nothing. This will also help define which business continuity controls should be put in place.
Obviously, business-critical systems will cost more if downtime occurs and will require more of the funds for the plan to keep them highly available. Less critical systems will not require a solution with a very little RTO and might be okay with existing tape recovery procedures already in place.