Disaster Recovery and Business Continuity: Defined
At some point in time, everything will fail — Simply acknowledging the possibility of a failure is never going to be enough. The real winners are the ones that have not only acknowledged the most remote possibility of a failure, but have set up a plan to address such a failure. This is the plan that eventually will help run businesses when everything else has failed. In the world of Information Technology, the failures of systems that incapacitate businesses or lead to massive financial loss due to their inability to perform revenue-generating or revenue-affecting functions is termed as a Disaster. The plan to address these scenarios is coined as the Disaster Recovery and Business Continuity Plan.
Every IT organization’s goal is to ultimately design an architecture that “never fails” or can gracefully respond to, any failure. Many organizations often confuse or misuse three core IT Disaster Recovery concepts:
- HA = High Availability
- FT = Fault Tolerant
- DR = Disaster Recovery
The concept of HA means that you have more than one system for a business critical application available to use either in an active-active configuration where both systems are utilized during normal business operations or active-passive where only one of the two systems is available for use during normal business operations. In both configurations the key is to design each system such that it can function by itself, even if the other system or its “mirror” is not available. With such an architecture you would think that you have planned for a disaster, yes? No… you have planned for an outage that is not expected to last an extended period. Disasters are typically defined as instances in time when systems are not expected to be available for an extended period. This is when you plan to run your business-critical applications from a pre-built and sometimes, highly available “stand-by” platform that offers the same level of service and enables business continuity.
FT systems are usually classified as a component of HA designs, meaning that you have a separate system that is fully configured and available to be used in the event that the primary system goes down for any reason whatsoever. It is key to remember that your architecture for HA, FT and DR needs to be failure reason indifferent.
DR strategies are incognizant to the actual reason for the failure; they are designed to take over service. The actual reason for why they are being used cannot be a factor in a decision to activate the DR service components.
DR is a component of IT, but BCP = Business Continuity Planning is the umbrella over the 3 pillars of business governance despite disruptive events; namely people, processes and technology. You may have the greatest IT plans to activate in a disaster situation, but the plan is useless if you have not planned for how people and processes will be governed to continue running the business in the event of disasters. In the simplest sense, you can think about how your staff will connect to these systems if they are not able to come to their actual work location, need to work from home or operate remotely. If organizations don’t plan their people and processes around DR, they should expect a bit of chaos from their users and as a result, lost productivity. Declaring a disaster is stressful enough; make sure your DR plan is complete and thorough.
Protect your business from possible failure. Thrive has a team of Subject Matter Experts with expertise in the areas of Disaster Recovery as a Service (DRaaS), Cloud (Public/Private), Cyber Security, and Compliance.