Unix Backup and Recovery

Step 1: Define (Un)acceptable Loss

A disaster recovery plan is an insurance policy. If you’ve ever read anything about backups, you’ve heard that before. I would like to extend that analogy. Consider your car insurance policy. All insurance policies in the United States start with PIP, or personal injury protection. That way if you hit someone and get sued, you are protected. You can then add coverage for collision, personal property, emergency roadside assistance, and rental car coverage. These additional layers of coverage are called riders. Just like your car insurance policy, disaster recovery plans may include optional riders. You simply need to decide the types of riders that your company needs, or can afford. How do you do this? You have to look at the potential losses that your company will suffer if a disaster occurs and decide which ones are acceptable or unacceptable, as the case may be. You then select the riders that will protect you against the losses that you have decided are unacceptable. (This analogy is discussed in further detail in Chapter 2.)

You need to make the same kind of decisions on behalf of your company. If it is unacceptable to lose a single day’s worth of data when a disaster happens, then you need to send your volumes to an off-site storage vendor every single day. You must decide what kind of losses your company is not willing to accept, and then insure against those losses with your disaster recovery plan. You cannot design a disaster recovery plan without this step. Every decision that you must make will be based on the information you discover during this analysis. Doing otherwise might cause you to purchase riders that you don’t need or to leave out ones that you do need.

Classify Your Data

What is considered an acceptable loss for office automation data may not be considered acceptable when considering your customer database. Some data is easily re-created with effort, while other data is irreplaceable. Look at each type of data that you have and decide whether it can be re-created.

There are several types of re-createable data. Suppose you are a company that sells a software product. You have hundreds of developers working around the clock on a very important product. If disaster hits, they would hate it, but they could re-create their work. The schedule will slip, but with enough time, you could replace the enhancements that they made to the code. As a rule, if data is being created by a single person or group of people, without interaction from anyone outside your company, then that data is probably replaceable. This is not to say that this data should not be backed up. It means that you might decide not to send volumes off-site for this type of data every single day, since both the volumes and the storage vendor cost money. You might decide to send them off-site only once a week. On the other hand, the cost of re-creating that data must be taken into account, and you may not want to explain to a group of 200 developers why they have to re-create everything they did last week. If that is the case, then you have defined that losing more than one day’s worth of anyone’s work is unacceptable. Great! That’s the purpose of this step.

There are types of data that are always irreplaceable. Suppose that you work in a hospital where patients come in to have MRIs and CAT scans performed in preparation for surgery or medical treatments. These images are stored digitally—there are no films. The doctors and surgeons use these images to plan critical operations or delicate treatments. What if a failure occurred that destroyed these images? These scans are often a picture of a progressing illness at a particular point in time. The loss of these images not only would expose the hospital and doctors to possible lawsuits but also could cost someone her life.

There are also financial institutions and brokerage firms that process hundreds of thousands of transactions each day. These transactions can total millions of dollars. A loss of a single transaction could be devastating. Would you want your bank to lose the direct deposit of your paycheck? Would you want your brokerage firm to lose your buy request for that hot new Internet IPO stock?

Examples of irreplaceable data do not have to be so devastating. Suppose a customer asks to have his address changed. You update the system and then you suffer a disaster. Do you even remember which customers called you last week, let alone what they asked for? Probably not. Your customer will sit at his new address awaiting his statement or product while you ship it to the old address. The result is that your credibility is destroyed in the customer’s eyes. In today’s world, you may end up on 20/20 or Dateline NBC.

In some instances, sending your backup volumes off-site daily (or hourly) is sufficient. However, there are situations in which the data is so critical and irreplaceable, the data must be duplicated and sent off-site immediately.

Assign a Monetary Value to Your Data

It is not possible to assign a monetary value to all types of data. How do you decide what an angry customer will cost you? (A truly angry customer can significantly cripple your business—especially if she sues you.) With other types of data, though, it is very easy. If you have five people who will have to redo a week’s worth of their work, then the cost is a week’s worth of their salaries, plus overhead. There are other things that are more difficult to calculate, such as the loss of productivity due to a drop in morale.

Weigh the Cost

You should not just blindly spend money on a disaster recovery plan that is more expensive than a disaster would be. This sounds like a given, but it can happen if you are not careful. It is possible that there are certain types of losses that you feel are unacceptable, no matter what the cost is to insure against them; that is fine, but make sure that you are insuring against them deliberately—and for all the right reasons .