DRBC - To do or not to do… that is the question!



Need a life jacket?



Confusion reins over the difference between Disaster Recovery and Business Continuity. Business Continuity (BC) is a company-wide program that plans how a company continues to operate in spite of business interruption - including personnel, facilities and IT. Disaster Recovery (DR) is a narrower subset of BC. The IT aspect is an important part of each.

It's not that long ago that investing in DRBC infrastructure was outside the reach of most companies save for the large organizations. With advances in technology the cost of implementing an effective DRBC infrastructure has been substantially reduced by as much as 60 percent. So now it's more of a question of “Can you afford not to put some analysis into making an informed decision around DRBC?”

There are all kinds of statistics available about the low probabilities of a disaster hitting your company. Thankfully, natural disasters in Colorado are less likely except for large snow storms, or an eastern plains tornado. Many Colorado based companies have higher risks from man made disasters be it fires, power outages, localized flooding, or environmental hazards caused by proximity to highways or railroads. However, DR typically gets relegated to low priority status unless there is a board or industry mandate to take it seriously.

Business Continuity discussions seem more practical to many decision makers who hold the purse strings. Suffice it to say the risk of disruption from something simple is much higher than the risk of a large scale disaster. The typical causes, in order of occurrence, are human error, software failure/database corruption and hardware failure. But I hear you say, “I have backups of my data!” Yes you do, but have you recently recovered from a backup to test your recovery time; and do you have the requisite capacity or quick access to such capacity to get up and running quickly enough to meet your minimum business demands? Have you considered what the cost of the lost data and productivity is?

A very simple starting exercise is to name your top five applications/communication modes  for your company and assign a maximum downtime or Recovery Time Objective (RTO) for each one. The RTO will be the goal for maximum time that a recovery operation should take for that application. As a next step decide how often and when you will be completing backups of those applications to determine what is your Recovery Point Objective (RPO). RPO will be the goal for the maximum amount of data that will be lost due to a data destroying event. Have your management team complete the same exercise and see if there is uniformity of opinion on the answer. Then assign an estimated cost per hour for downtime and cost per hour of lost data to those applications. From here you can narrow down your business recovery requirements.

If you've already addressed these questions then you are in the advanced minority. If not, it's easy and does not cost anything except a little time and analysis to get started. Like most things in technology there is not a one size fits all scenario for DRBC. You can pick and choose what level of Business Continuity and how to apply it to a narrow list of applications or even users. Once you've defined your high level Business Continuity requirements it’s simple and cost effective to roll in offsite, disaster recovery elements into the plan.

Talk to your peers and find out what approach they are taking and why. Talk to a third party expert if you find that you are too close to your business to objectively assess the risks. More often than not it's the human intervention and not technology failure that causes a wide disruption (e.g., somebody triggering the sprinkler system on the floor above your datacenter, or an IT admin fat-fingering something). It's your job to be prepared for when, not if, disruptions or disasters occur.