A common theme in the world of data backup is the confusion of business continuity with disaster recovery. When it comes to protecting your data, it’s important to understand that these are two different concepts. The misunderstanding of the terms could result in organizations being left at a significant risk due to inadequate planning. According to IBM in 2011, of the companies that had a major loss of business data, 43 percent never reopen, 51 percent close within two years and 6 percent will survive long-term.
Let’s be honest. In a disaster, few people care about the definition of terms. However, one sure way to get through the chaos of losing data and facilities is to know the difference between recovery and continuity.
Disaster recovery is a subset, a small part of overall business continuity. It is the process of saving data with the sole purpose of being able to recover it in the event of a disaster. Disasters in IT range from minor to major: the minor loss of an important set of data to the major loss of an entire datacenter, though recovery of the corporate database may take the same herculean effort as the reconstruction of the company’s infrastructure. From the point-of-view of panic, pain and pressure, the range in size of a disaster—either minor or major—could arguably be very similar.
A great example is Hurricane Katrina. In 2005, most of the city of New Orleans was underwater, without power and without some of the basic resources to even live. There were many companies that kept off-site copies of their data so that 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 of 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 item to note is that the data is not accessible during the disaster. It must first be recovered, and the speed at which the data is recovered is solely dependent on the planning, infrastructure and processes that are set forth and tested.
On the other side, business continuity typically refers to the management oversight and planning involved with ensuring the continuous operation of IT functions in the case of system or enterprise disasters. The elements necessary for successful business continuity include the plant (location), staffing and equipment, as well as the actual data recovery procedures.
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. In basic terms, it means that when a failure or disaster happens, that data is still accessible with little to no downtime.
Typically, 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 must have the infrastructure to support it. The most common example is clustering. Clustering allows the replication of data between multiple systems thus enabling 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.
Regarding business operations and management of the staff and facilities, continuity represents a much larger scope of maintenance than the recovery of just the data and equipment. Most companies come from a practical analysis of how long recovery will take. During the planning process for recovery reality starts to set in. Time factors to get back in operation count heavily toward what must get recovered first. The matter of time to recovery introduces these business continuity questions:
What do we need recovered first to stay in business?
- What do our customers need to remain assured of our stability?
- What do our business partners require to continue order, fulfillment and delivery?
- What do our vendor relationships insist upon to work with us?
Prioritization of what to recover first points to the more important analysis of these business relationships and how they line up. Every corporate entity lives with different ordering lists that determine their ability to remain in business.
Recovery of data may well be the only issue that the bulk of IT managers and C-level officers have time to address. It’s a good start, but not the whole story. You must understand the “what” and “how” in order to get your data back in operation. During that recovery planning, these same managers and officers will run into the continuity questions. The better the recovery system in terms of reliability, scope and scalability, the better the chance of stepping up to the continuity issues. The more feeble and antiquated your recovery planning, the more certain corporate failure at continuing business as usual during a disaster.