The fact is that most people think business continuity and disaster recovery are the same thing. They are not. To be honest, in today’s day and age, you actually need both to survive the many types of failures you can have. In order to really know what is right for you and your data, we must set the stage.
What is disaster recovery?
Disaster recovery is the process of saving data with the sole purpose of being able to recover that data in the event of a disaster. A great example is hurricane Katrina. In 2005, most of the city of New Orleans was underwater, without power and without some of the basics resources to even live. There were many companies that kept off-site copies of their data so in the event of a disaster they could recover the data. What they did not plan for was the inability to get that off-site data to their secondary site. In one case, the company kept all its data on off-site tapes that were kept in a secure location. The only problem was that the company could not physically get to the site to retrieve its tapes.
The root of disaster recovery is that data is kept in a secondary site and plans are made on how that data will be recovered so that the business can access it again. One thing to note is that the data is not accessible during the disaster. The data must first be recovered and the speed at which the data is recovered is solely dependent on the planning, infrastructure and process that are set forth and tested.
Business continuity is a completely different process. First, it is not data centric, it is business centric. The whole point of business continuity is to continue to do business DURING a failure or disaster. Business continuity basically means that when a failure or disaster happens, that data is still accessible with little to no downtime.
Usually business continuity is a combination of hardware and software technologies that keep data in two different places at the same time. For example, if the production server in one building goes down, the data and the application are “failed over” to a second system that the application can then use. Usually, the application only pauses and users do not even know there was a problem.
What this really means is that you have to have the infrastructure to support it. The most common example is clustering. Clustering allows you to replicate your data between multiple systems thus allowing you to have that data accessible from a secondary source in the event of some failure. Active/active clustering is a great example. If your mail application goes down on the production server, the replicated copy on the secondary server takes the load and the application stays up and people still have access.
But, business continuity is not really the safety net you think it is. Here is the “gotcha:” if the data that you replicate becomes corrupt or unusable, then that same issue will occur on the other system. For example, if you get a virus in your mail application on server A, it will be replicated to server B. Now, both systems are worthless.
Now the question becomes: if I have a business continuity strategy in place, do I need to worry about disaster recovery? Can I not just use business continuity as my safety net? The simple answer is you need both. To be truly protected you need a replication strategy and a backup strategy.
Disaster recovery is your backup and recovery application and the process of securing data to be RECOVERED. Business continuity is your real-time duplication of data between sites or servers for FAILOVER. Disaster recovery and backup and recovery are part of business continuity by necessity due to the fact that business continuity keeps exact copies of data on both sides and runs the risk of having data be corrupt in both places.
We have shown how the two are different, now the question becomes, “When should you use disaster recovery and when should you use business continuity?” That is a question for another day.