The title of this chapter reflects the three rules of system administration: 1) Backup; 2) Backup; and 3) Backup! Although this advice may sound trite, the number of people who have lost important or valuable data, not to mention all the configuration information they spend days getting correct, is enormous. Even if you don't have a tape drive or other backup storage device, get in the habit of backing up the most important pieces of information. This chapter looks at how to properly back up information.
If you run a system that has many users, network access, e-mail, and so on, backups are a very important aspect of the daily routine. If your system is used for your own pleasure and is not used for any important files, backups are not as important except as a way to recover your configuration and setup information. You should make backups either way; the difference is the regularity with which you make them.
A backup is a copy of the filesystem or files on part of a filesystem stored onto another medium that can be used later to recreate the original. In most UNIX systems, the medium used for backups is tape, but you can also use floppy disks or secondary and removable hard disks.
So many potential sources of damage to a modern computer system exist that they can be overwhelming. Damage to your hard disks and their filesystems and data can occur from hardware failures, power interruptions, or badly typed commands. Part of the potential for damage with Linux is the nature of an operating system itself. Because Linux is a multiuser and multitasking operating system, many system files are open at any moment. At most millisecond increments, data is being written to or read from a hard disk (even when the system has no users or user-started background processes on it). Also, Linux maintains a lot of information in memory about its current state and the state of the filesystems. This information must be written to disk frequently. When CPU processes are interrupted, system files and tables can be lost from memory. Disk files can be left in a temporary state that doesn't match the real filesystem status.
Although damage to a filesystem can occur from many sources, not all of which are under the control of the system administrator, it is the administrator's task to make sure the system can be restored to a working state as quickly as possible. Having a backup is sometimes your only chance of getting back lost information. Although the process of making backups can be tiresome and time-consuming, this inconvenience is often outweighed by the time required to recoup any lost information in case of problems. With utilities like cron available, the task of backing up is much easier, too.
One final aspect about backups you need to consider is where to keep the backup media after it has been used. For most home users, the only option is to store the tapes, drives, floppy disks, or other media in the same place as the Linux machine. Make sure the location is away from magnetic fields (including telephones, modems, televisions, speakers, and so on). For systems that are used for more than pleasure, consider keeping copies away from the main machine, preferably away from the same physical location. This type of off-site backup enables you to recover in case of a catastrophe, such as a fire, that destroys your system and backup media library.
By far the most commonly used medium for backups is tape, especially tape cartridges. Tape is favored because it has a low cost, a relatively easy storage requirement, and reasonable speed. The process of writing and reading data from a tape is reliable, and tapes are portable from machine to machine. All you need, of course, is a tape drive. If you don't have one, you need to find another usable medium for backups.
Possible alternative media include removable hard disks of many different types, such as the Iomega Bernoulli or ZIP drives. These cartridges use magnetic head technology just like a normal hard drive. You can remove these disk-platter systems, which usually come in a protective cartridge, from the main system and store them elsewhere. You can then cycle through several of these disks as you would with tapes. In some cases, removable cartridges are available for a competitive price compared to tape cartridges, although some high-capacity removable cartridges cost more (but also offer more storage). The cost of the removable cartridge drive varies depending on the capacity, manufacturer, and technology, but it is also competitive with a tape drive in many cases.
Several new magneto-optical cartidge systems for DOS and Windows are usable under Linux, too. These systems tend to be small 3.5-inch cartridge systems that fit into a small drive unit. A 230M magneto-optical cartridge and drive can cost less than some tape drives, and they present a more secure backup medium because magneto-optical systems are not susceptible to magnetic fields. They have a potentially longer life, too. Large-capacity magneto-optical systems, now approaching 2.4G, are currently available, although they tend to cost as much as a new computer.
Another possibility is another hard disk. With the price of hard disks dropping all the time, you can add another hard disk just for backups to your system (or any other system connected by a network) and use it as a full backup.
The popularity of writable CD-ROM and WORM (write once, read many) drives makes them a possibilty as well, although you must bear in mind that this type of media can only be written to once (the disks can't be reused). This type of media does have an advantage for archival purposes where you may need to prove certain file dates are accurate. CDs are also useful for permanent storage of important files like accounting records, personal letters, documents such as wills, and binaries. CD-ROM discs can hold 750M of data, although most consumer discs are designed for 650M.
Consider a floppy disk drive as a last resort backup device for large filesystems, although it is very good for backing up small files. High-capacity floppy disk drives are beginning to appear now, but the lack of Linux drivers make them unusable for most backup situations.
One of the most important aspects of making backups is to make them regularly. Regularity is much more important for systems that support many users and have constantly changing filesystems. If your Linux machine is used only for your own purposes, you can make backups whenever you feel there is material that should be backed up.
For most systems with a few users, constant Internet access for e-mail or newsgroups, and similar daily changes to the filesystem, a daily backup schedule is important. You don't have to make a full backup of everything on your hard drives every day, but you should consider using incremental backups, which copy only those files that are new or have changed since the last backup.
Most UNIX system administrators prefer to perform backups during the night or early hours of the morning because few users are logged in, there is no real load on the CPU, and the system has the least number of open files at this time. Because backups are easily automated using cron (see Chapter 23, "The cron and at Programs"), you can set the exact backup time to minimize the impact on any other background processing tasks that the system may be running. Because you don't have to manually start the backup process, you can do it at any time. All the system administrator has to do in this kind of backup schedule is check that the backup was completed properly, change the backup media, and log the backup.
For those systems with a single user and a lightly loaded Linux system, backups can be done practically anytime, although it is a good idea to have the backups performed automatically if your system is on all the time. If your Linux system is only active when you want to use it, get in the habit of making a backup while you do other tasks on the system.
When DOS or Windows users move to UNIX, they sometimes have the bad habit of keeping a single tape (or other media) and continually recycling that one unit every time they make a backup. It is foolhardy to keep only one backup copy of a system as this prevents you from moving back to previous backups. For example, suppose you deleted a file a week ago and had it safely stored on a backup tape at that time. When you reuse the backup tape, the old contents are erased and you can never get the old file back.
Ideally, you should keep backup copies for days, or even weeks, before reusing them. On systems with several users, this habit is even more important because users only remember that they need a file they deleted two months ago after you have recycled the tape a few times. Some backup scheduling methods can help get around this problem, as you will see in a moment. The ideal backup routine varies depending on the system administrator's ideas about backups, but a comprehensive backup system requires at least two weeks of daily incremental backups and a full backup every week.
A full backup is a complete image of everything on the filesystem, including all files. The backup media required for full backups is usually close to the total size of your filesystem. For example, if you have 150M used in your filesystem, you need about 150M of tape or other media for a backup. With compression algorithms, some backup systems can get the requirements much lower, but compression is not always available. Also, you may need several volumes of media for a single full backup, depending on the capacity of the backup unit. If your tape drive can only store 80M on a cartridge and you have to backup 150M, you need two tapes in sequence for the one backup. Because the Linux system's cron utility can't change tapes automatically, full backups over several volumes require some operator interaction. Obviously, making a full system backup on low-capacity media (like floppy disks) is a long, tedious process because there are many volumes that must be switched.
Incremental backups (sometimes called differential backups) back up only the files that have been changed or created since the last backup. Unlike DOS, Linux doesn't have a file indicator that shows what files have been backed up. However, you can use the modification date to effectively act like a backup indicator.
Incremental backups are sometimes difficult to make with Linux unless you restrict yourself to particular areas of the filesystem that are likely to have changed. For example, if your users are all in the /usr directory, you can backup only that filesystem area instead of the entire filesystem. This kind of backup is often called a partial backup, as only a part of the filesystem is saved. (Incremental backups can be made under any operating system by using a background process that logs all changes of files to a master list, and then uses the master list to create backups. Creating such a scheme is seldom worth the effort, though.)
How often should you back up your system? The usual rule is to back up whenever you can't afford to lose information. For many people, this criteria means daily backups. Imagine that you have been writing a document or program, and you lose all the work since the last backup. How long will it take to rewrite (if at all possible)? If the rewriting of the loss is more trouble than the time required to perform a backup, make a backup!
So how can you effectively schedule backups for your system, assuming you want to save your contents regularly? Assuming that your system has several users (friends calling in by modem or family members who use it) and a reasonable volume of changes (e-mail, newsgroups, word processing files, databases, or applications you are writing, for example), consider daily backups. The most common backup schedule for a small, medium-volume system requires between 10 and 14 tapes, depending on whether backups are performed on weekends. (The rest of this section uses tapes as the backup medium, but you can substitute any other device that you want.)
Label all backup tapes with names that reflect their use. For example, label your tapes Daily 1, Daily 2, and so on up to the total number of daily use tapes, such as Daily 10. Cycle through these daily use tapes, restarting the cycle after you have used all the tapes (so that Daily 1 follows after Daily 10). With this many tapes, you have a two week supply of backups (ignoring weekend backups, in this case), enabling you to recover anything going back two weeks. If you have more tapes available, use them to extend the backup cycle.
The backups can be either full or partial, depending on your needs. A good practice is to make one full backup for every four or five partial. You can make a full backup of your entire filesystem on Mondays, for instance, but only back up the /usr directories the other days of the week. Make an exception to this process if you make changes to the Linux configuration so that you have the changes captured with a full backup. You can keep track of the backups using a backup log, which is covered in the next section.
An expansion of this daily backup scheme that many administrators (including the author) prefer is the daily and weekly backup cycle. This backup system breaks up the number of tapes into daily and weekly use. For example, if you have 14 tapes, use 10 for a daily cycle as already mentioned. You can still call these tapes Daily 1 through Daily 10. Use the other four tapes in a biweekly cycle and name them Week 1, Week 2, Week 3, and Week 4.
To use this backup system, perform your daily backups as already mentioned, but use the next weekly tape when you get to the end of the daily cycle. Then you cycle through the daily tapes again, followed by the next weekly tape. (Your backup cycle is Daily 1 through Daily 10, Week 1, Daily 1 through Daily 10, Week 2, and so on.)
This backup cycle has one major advantage over a simple daily cycle. When the entire cycle is underway, there are 10 daily backups, which cover a two-week period. The biweekly tapes extend back over four complete daily cycles, or eight weeks. You can then recover a file or group of files from the filesystem as it was two months ago, instead of just two weeks. This backup method gives you a lot more flexibility in recovering information that was not noticed as missing or corrupt right away. If even more tapes are available, you can extend either the daily or biweekly cycle, or add monthly backups.
Many system administrators begin their careers by making regular backups, as they should. However, when they get to the point where they have to restore a file from a backup tape, they have no idea which tapes include the file or which tapes were used on what days. Some system administrators get by this problem by placing a piece of paper or stick note on each tape with the date and contents on it. This solution means you have to flip through the tapes to find the one you want, though, which can be awkward when you have lots of tapes. For this reason, you should keep a backup log. (A log is a good idea for backups on other operating systems as well.)
Whenever you make a backup, you should update the backup log. A backup log doesn't have to be anything complex or elaborate. You can use the back of a notebook with a couple of vertical columns drawn in, use a form on the computer itself (which you should print out regularly, of course), or keep a loose-leaf binder with a few printed forms in it. A typical backup log needs the following information:
You can record these four bits of information in a few seconds. For larger systems, you can add a few other pieces of information to complete a full backup record:
The dates of the backup help you keep track of when the last backup was performed and also act as an index for file recovery. If one of your system users knows they deleted a file by accident a week ago, you can determine the proper backup tape for the file restoration from the backup log dates.
For convenience, keep the backup log near the system. Some administrators prefer to keep the log in the same location as the backup media storage instead. Some system administrators also keep a duplicate copy of the backup log in another site, just in case of catastrophe. Do what is appropriate for your system.
The tar (tape archiver) program is usually the command you use to save files and directories to an archive medium and recover them later. The tar command works by creating an archive file, which is a single large entity that holds many files within it (much like PKZIP does in DOS, for example). The tar command only works with archives it creates.
The format of the command is a little awkward and takes some getting used to, but fortunately most users only need a few variations of the commad. The format of the tar command is as follows:
tar switch modifiers files
The files section of the command indicates which files or directories you want to archive or restore. You probably want to archive a full filesystem such as /usr. In the case of recovery, you may want a single file such as /usr/tparker/big_file.
The switch controls how tar reads or writes to the backup media. You can use only one switch with tar at a time. The valid switches are as follows:
| c | Creates a new archive media |
| r | Writes to end of existing archive |
| t | Lists names of files in an archive |
| u | Adds files that are not already modified or archived |
| x | Extracts from the archive |
You can add a number of modifiers to the tar command to control the archive and how tar uses it. Valid modifiers include the following:
| A | Suppresses absolute filenames |
| b | Provides a blocking factor (1-20) |
| e | Prevents splitting files across volumes |
| f | Specifies the archive media device name |
| F | Specifies the name of a file for tar arguments |
| k | Gives size of archive volume (in kilobytes) |
| l | Displays error messages if links are unresolved |
| m | Does not restore modification times |
| n | Indicates the archive is not a tape |
| p | Extracts files with their original permissions |
| v | Provides verbose output (lists files on the console) |
| w | Displays archive action and waits for user confirmation |
The tar command uses absolute pathnames for most actions, unless you specify the A modifier.
A few examples may help explain the tar command and how to use tar switches. If you are using a tape drive called /dev/tape and the entire filesystem to be archived totals less than the tape's capacity, you can create the tape archive with the following command:
tar cf /dev/tape /
The f option enables you to specify the device name, /dev/tape in this case. The entire root filesystem is archived in a new archive file (indicated by the c). Any existing contents on the tape are automatically overwritten when the new archive is created. (You are not asked whether you are sure you want to delete the existing contents of the tape, so make sure you are overwriting material you don't need.) If you include the v option in the command, tar would echo the filenames and their sizes to the console as they are archived.
If you need to restore the entire filesystem from the tape used in the preceding example, issue the command:
tar xf /dev/tape
This command restores all files on the tape because no specific directory has been indicated for recovery. The default, when no file or directory is specified, is the entire tape archive. If you want to restore a single file from the tape, use the command
tar xf /dev/tape /usr/tparker/big_file
which restores only the file /usr/tparker/big_file.
Sometimes you may want to obtain a list of all files on a tape archive. You can do this with the following command:
tar tvf /dev/tape
This command uses the v option to display the results from tar. If the list is long, you may want to redirect the command to a file.
Most tapes require a blocking factor when creating an archive, but you don't need to specify a blocking factor when reading a tape because tar can figure it out automatically. The blocking factor tells tar how much data to write in a chunk on the tape. When archiving to a tape, you specify the blocking factor with the b modifier. For example, the command
tar cvfb /dev/tape 20 /usr
creates an new archive on /dev/tape that has a blocking factor of 20 and contains all the files in /usr. Most tapes can use a blocking factor of 20, and you can assume this factor as a default value unless your tape drive specifically won't work with this value. The only times blocking factors are changed are for floppy disks and other hard disk volumes. Note that the arguments following the modifiers are in the same order as the modifiers. The f precedes the b modifier so the arguments have the device before the blocking factor. The arguments must be in the same order as the modifiers, which can sometimes cause a little confusion.
Another common problem is that a tape may not be large enough to hold the entire archive, in which case more than one tape will be needed. To tell tar the size of each tape, you need the k option. This option uses an argument that is the capacity in kilobytes. For example, the command
tar cvbfk 20 /dev/tape 122880 /usr
tells tar to use a blocking factor of 20 for the device /dev/tape. The tape capacity is 122880 kilobytes (approximately 120 M). Again, note that the order of arguments matches the order of the modifiers.
Floppy disks create another problem with tar, as the blocking factor is usually different. When you use floppy disks, archives usually require more than one disk. You use the k option to specify the archive volume's capacity. For example, to back up the /usr/tparker directory to 1.2M floppy disks, the command would be
tar cnfk /dev/fd0 1200 /usr/tparker
where /dev/fd0 is the device name of the floppy drive and 1200 is the size of the disk in kilobytes. The n modifier tells tar that this is not a tape. As a result, tar runs a little more efficiently than if the modifier had been left off.
This chapter looked at the basics of backups. You should maintain a backup log and make regular backups to protect your work. Although tar is a little awkward to use at first, it soon becomes second nature. You can use the tar command in combination with compression utilities such as compress. Alternatively, you can use utilities like gzip and gunzip that combine both utilities into one program. Although this program may be more convenient, tar is still the most widely used archive utility and is therefore worth knowing.
A number of scripts are beginning to appear that automate the backup process or give you a menu-driven interface to the backup system. These scripts are not in general distribution, but you may want to check FTP and BBS sites for a utility that simplifies backups for you.
