6.3 The Painful Rules of Backup

only for RuBoard - do not distribute or recompile

All backup and restore operations, including SAN backup and restore operations, are subject to the Painful Rules of Backup. These rules must have been formulated by a man named Murphy, who recognized that the universe is far from perfect.

Rule 1. You will have a loss of data.

You don t know where. You don t know when. However, it will happen. You will lose important data. Either file corruption, accidental overwriting, accidental deletion, deliberate deletion, device failure, or volcanic eruption will make some data unavailable.

There s a great data processing cartoon from the 1970s showing a distraught programmer being consoled by two others. The caption went something to the effect: Well, you can recode it from the printout. You may personally know that gut-wrenching feeling when a vital file isn t there anymore. It s no great fun to redo source code, reenter the customer database manually, or process customer orders by hand for a few days.

Obviously, you hope to never find yourself in this position, whether you are dealing with a single source code file, gigabytes of stored video, or 100 TB of business data.
Rule 2. Do it. Do it right. Do it right now.

You must assure yourself that you have a suitable backup strategy in place and that it s operating successfully right now. This is true whether you have a SAN in place or not. In fact a good pre-SAN backup strategy makes it a bit easier to design for SAN backups .

Remember, disaster strikes only when you are unprepared, and ironically, if you re prepared, it s not so much of a disaster.

In the late 1970s, University Computing was promoting its backup package for mainframes. UCC had posters showing a hobo roasting weenies under a railroad bridge. The caption was something like: What ever happened to Bill after that little problem with the payroll master file? You don t want to end up like Bill.

Given the sheer volume of data most enterprises have, and given the demand for high speed and reliability, backup and restore is a daunting task. It requires a well-planned backup strategy. As you move to a SAN configuration, this requirement increases .
Rule 3. Plan your SAN with backup in mind.

Understand the potential for rapid growth of primary storage on a SAN, and plan tomorrow s backup strategy now. Unfortunately, the cards are stacked against you.

The developers of massive primary storage are outpacing the developers of secondary storage. Increases in disk storage capacity are commonplace; increases in tape capacity are not. In fact, substantial increases in tape capacity are usually considered a generational change.

The developers of Fibre Channel connectivity are outpacing the developers of secondary storage. And as the current 1 Gbps Fibre Channel evolves to 2 Gbps (which has just been announced for this year) and 4 Gbps, it will be more convenient to store and retrieve more data, and the increased bandwidth will allow more people to do so.

At the same time, the tape backup process will retain its limitations. The limitations are the relatively slow speed of tapes through the tape drive s transport, and the relatively slow speed of robotic tape changers. The good news is that tape density, compression, and lengths are improving all the time.
Rule 4. If you back up, nothing will go wrong. If you don t back up, everything will go wrong.

How can this make sense? There is no hard science behind this statement, but many system administrators will support this. Through some sort of information processing magic, the more you back up, the less likely you are to have a data loss.

Or to put it the opposite way, if you don t back something up, there s sure to be a need to restore it. The scope of the problem can range from the unavailability of a 30 KB printer driver to a 10 MB employee database, but it doesn t matter. This seems to be an immutable law of the universe.

Was prevention of data loss easier in the past? Not particularly. Even in the days of punch cards, the unit records (the cards) could be folded, spindled, and mutilated. An operator could drop a tray of cards, usually with a number of them falling in the cracks between the disk drives .

The funniest (if it hadn t been so tragic) case of data loss I (Barry) remember was in the 1970s on Spring Street, the heart of Los Angeles financial district . During a morning tickertape parade, bank employees threw tens of thousands of punch cards out of the office windows . That afternoon, the same bank employees were all on their hands and knees on Spring Street, trying desperately to gather the cards they had thrown out in error!

only for RuBoard - do not distribute or recompile