CHAPTER 18

Backup and Restore

by David Pitts

IN THIS CHAPTER

• Qualities of a Good Backup
• Selecting a Backup Medium
• Selecting a Backup Tool
• Backup Strategy
• Restoring Files
• What Is on the Tape?

Data is important. Both the time it took to create it and the uniqueness of the data make it valuable. Therefore, care should be taken that data is not lost.

Data can be lost several different ways. The first is through carelessness. I do not know how many times I have restored data for people who have been in the wrong directory when they issued an rm -r command. The second way that data can be lost is through hardware failure. Although newer hard drives are more reliable than the older ones, they still fail, and data is lost. A third way that data is lost is faulty software. Too many times I have programmed a tool to perform a task, only to have the tool destroy my data instead of manipulating it. The rule of thumb these days is that programs are released before they are ready. If there is a bug, then the people who developed the software will put out a patch. Still the data, and time it took, are both gone. Finally, the earth can just swallow up entire buildings; or there can be earthquakes, or tornadoes, or volcanoes, or hurricanes, or aliens from outer space.

Backups can protect that investment in time and in data, but only if they are actually successful in backing up and keeping the information. Therefore, part of a successful backup procedure is a test strategy to spot check backups. The easiest way to spot check your backups is to perform a restore with them. This is something you should attempt before you need to perform a restore with them.

Backups can take on many forms. I worked for a company once that had six servers. Their backup method was to tar servers and store a copy of that tar on another server. In addition, they did tape backups of the servers, which included the online version of the backups. These tape backups were used for disaster recovery purposes and kept offsite. This example actually shows a couple different ways of performing backups: One way is to store tarred copies on other machines, and the other is to store copies on tape backup (and to keep the copies offsite). The combination of these two methods provides a fairly reliable way of doing backups in that it covers everything from the simple "Oops, I accidentally deleted your database!" to "Godzilla just stepped on our building, and we need the data back in less than two days!"

This chapter covers what the qualities of a good backup are and the process of selecting a good backup medium and a backup tool. Finally, backup strategies are considered, including incremental and full backups and when to perform each.

Qualities of a Good Backup

Obviously, in the best of all possible worlds, backups would be perfectly reliable, always available, easy to use, and really fast. In the real world, this is not the case. There are trade-offs to be made. For example, backups stored offsite are good for disaster recovery, but would not always be available.

Above all, backups need to be reliable. A reliable backup medium should last for several years. Of course, if the backups are never successfully written to the backup medium, then it does not matter how good the medium is.

Speed is more or less important, depending upon the system. If there is a time window when the system is not being utilized, and the backup can be automated, then speed is not an issue. On the other hand, the restoration might be an issue. The time it takes to restore the data is as important as how critical it is to have the data available.

Availability is a necessary quality. It does no good to perform regular backups if, when they are needed, they are unavailable. Backups for disaster recovery would not be available to restore a single file that a user accidentally deleted. A good backup and recovery scheme includes both a local set of backups for day-to-day restores and an offsite set of backups for disaster recovery purposes.

It does no good to have fast, available, reliable backups if they are not usable. The tools used for backup and restoration need to be easy to use. This is especially important for restoration. In an emergency, the person who normally performs the backup and restores might be unavailable. A nontechnical user might have to perform the restoration. Obviously, documentation is a part of usability.

Selecting a Backup Medium

Today the three common backup options are floppies, tapes, and hard drives. Table 18.1 rates these media in terms of reliability, speed, availability, and usability.

Table 18.1. Backup medium comparison.

Of course, there are other options, including CDs and floptical disks. Writable CDs are good for archival purposes, but they cannot be overwritten; therefore, the expense tends to be high. Flopticals, with attributes of both floppies and optical disks, tend to have the good qualities of floppies and tapes. They are good for single file restoration, and they can hold a lot of data.

Selecting a Backup Tool

Many tools are available for making backups. In addition to numerous third-party applications, Red Hat Linux comes with some standard tools for performing this task. This section examines two of them, tar and cpio.

tar and cpio are very similar. Both are capable of storing and retrieving data from almost any media. In addition, both tar and cpio are ideal for small systems, which Red Hat Linux systems often are. For example, the following tar command saves all files under /home to the default tape drive:

$ tar -c /home

The -c option tells tar which directory it is gathering files from—/home in the preceding example.

cpio, while similar, has several advantages. First it packs data more efficiently than does the tar command. Second, it is designed to back up arbitrary sets of files (tar is designed to back up subdirectories). Third, cpio is designed to handle backups that span over several tapes. Finally, cpio skips over bad sections on a tape and continues, while tar crashes and burns.

Backup Strategy

The simplest backup strategy is to copy every file from the system to a tape. This is called a full backup. Full backups by themselves are good for small systems, such as those typically used by Red Hat Linux users.

The downside of a full backup is that it is time-consuming. Restoring a single file is almost too cumbersome to be of value. There are times when a full backup is the way to go, and times when it is not. A good backup and recovery scheme will identify when a full backup is necessary and when incremental backups are preferred.

Incremental backups tend to be done more frequently. With an incremental backup, only those files that have changed since the last backup are backed up. Therefore, each incremental builds upon previous incremental backups.

UNIX uses the concept of a backup level to distinguish different kinds of backups. A full backup is designated as a level 0 backup. The other levels indicate the files that have changed since the preceding level. For example, on Sunday evening you might perform a level 0 backup (full backup). On Monday night, you would perform a level 1 backup, which backs up all files changed since the level 0 backup. Tuesday night would be a level 2 backup, which backs up all files changed since the level 1 backup, and so on. This gives way to two basic backup and recovery strategies. Here is the first: