Technical specifications Go wild. If anyone has made it this far, they're either really interested or a true computer techie just like you! If this report is the cost justification for a new backup drive, find a table that compares the relative cost per MB of all the various options. Include hard numbers and any white papers that are included with the proposed product. If you think it is relevant, but possibly too long and boring, this is the place to put it. Good Luck The chapters that follow explore in depth the various methods that you may employ to back up your systems. Most of these topics also are covered in documentation from the appropriate vendor; this book is not meant to be a replacement for that documentation. I try to explain things that are not covered in the documentation and possibly address some subjects more frankly than a manual provided by the vendor can. Welcome to the world of backups. Page 67 II FREELY AVAILABLE FILESYSTEM BACKUP & RECOVERY UTILITIES Part II consists of the following two chapters: • Chapter 3, Native Backup & Recovery Utilities, describes the backup utilities that are part of a standard Unix distribution. • Chapter 4, Free Backup Utilities, discusses additional, free utilities that can support a backup/recovery plan. Page 69 3 Native Backup & Recovery Utilities Native utilities are the backup utilities that you find in a standard Unix distribution. I'll admit that these utilities are rather boring. They do nothing fancy and they have many limitations, some of which have been there since they were originally written to back up a PDP-11 to a 9-track tape. (In sixth and seventh edition Unix, it was still called restor- a throwback to the Multics days.) Some of these utilities have bugs that persist to this very day. (They've finally fixed the "tape-rewinding" bug in dump, but only on some Unix versions.) Yet these native backup utilities do have a few features that have not been duplicated by commercial backup vendors. These features will always be there, and they don't cost extra. They also work basically the same everywhere, with only a few minor differences. Whether you're just starting out in the backup world or you're an experienced systems administrator, you need to be familiar with these utilities. An Overview This chapter describes the benefits and pitfalls of several utilities. dump and restore are usually the best option if they are available. After dump and restore, cpio has the best functionality, but it is slightly less user friendly than its cousin tar. tar is incredibly easy to use and is much more portable than either dump or cpio, If you have to back up raw devices or perform remote backups with tar or cpio, dd will be your new best friend. This chapter begins with an overview of each of these backup utilities. It then goes into detail about the syntax for each command for both backup and recovery. Finally, near the end of the chapter, there is an invaluable comparison chart that can be used as a quick reference guide for comparing dump, tar, and cpio. Page 70 The dump and restore Utilities If you are responsible for backing up at least one Unix server, can't afford a commercial backup product, and don't want to trust your mission-critical backups to a public domain utility, then hopefully your version of Unix supports the commands damp and restore. You can't beat their flexibility and versatility for backing up and restoring and entire system. dumpand restore are relatively sophisticated commands, with simple interfaces whose essential options are the same on most Unix systems. Some versions of Unix have changed the name and a few of the features of dump, but most of the changes are minor.* dump can even be found on Unix-like systems such as Linux** and Network Appliance boxes. Even if you don't plan on using dump for backups in the future, chances are you've got several dump volumes in a cabinet somewhere that you may need to read someday. When you do need to read those volumes, hopefully you will have this book handy. The cpio Utility If you do not have dump or you can't use the version you have, then cpio is your next best choice. cpio has been around longer than any other backup utility and has some very important features that other commands do not have. First, there are a few things that cpio will not do for you that dump can. cpio cannot: • Perform incremental backups without the use of touch files and find • Leave both atime and ctime unchanged after a backup (see the section on mtime, atime, and ctime in Chapter 2, Backing It All Up) • Perform an interactive restore, like the -i option in restore cpio can be a very powerful backup tool. The main thing that sets it apart is its ability to accept the list of files to be backed up from standard input. Some newer versions of tar support listing the files via standard input, but most native versions of tar do not support it. See "Backing Up with the dump Utility" in this chapter for more details. * Some, however, include major modifications, and in some respects dump is not really dump at all! Let the user beware! Make sure you read the manpages for your version of dump. ** Remember that Linux is just like Unix, but it doesn't carry the Unix brand. Therefore, it is Unix-like. Page 71 Why isn't cpio more popular? If cpio is so wonderful, why is tar more popular? The most probable reason is that the basic operations of tar are much simpler (and more standard) than the same operations in cpio. For example, every version of tar supports tar cf device and tar xf device, whereas cpio sometimes supports the -I and -O options and sometimes does not. If you add all the cpio options available on all the various versions, you would find more than 40 of them. There are also some arguments that use the same letter but have completely different functions on different version of Unix. However, I believe that if you use only the options that are standard on most (if not all) platforms, cpio can have almost the same simplicity as tar-almost. The tar Utility If you need to back up your entire system on a regular basis, dump is probably your best choice if it is available. Your second best choice is cpio, since you can use it with find to perform incremental backups. But if you're like most people, you do a whole lot of backups that don't need this level of functionality. You may want to make a quick backup of a user's home directory. The user has a huge directory that you would love to delete, but the only way she'll let you back up her directory is if you give him a copy of it on a tape or CD. You don't care about atime; you don't want to do regular, incremental backups; you just want to get the stuff onto a backup volume, and you want it to be easy for someone else to get it off the backup volume. In this case, tar is your best bet. There are some things that cpio can do for you that most native versions of tar can't (GNU tar does not have these limitations, thanks to a lot of work from a lot of people. See the sidebar on GNU tar later in this chapter.): • Accept a list of files to back up from stdin. (Again, a few native versions of tar support this. See the section on tar later in this chapter for more details.) •Reset atime of the files it backs up, although this changes ctime. The native versions of tar are not able to reset atime, but the GNU version of tar can. Although tar hasn't been around as long as cpio, it has gained much wider acceptance. This is perhaps its greatest feature. Nearly everyone knows how to read a tar volume, and if they don't it's really easy to show them how. If it is a tar file on disk or even a compressed tar file, programs like WinZip* can automatically * WinZip is a registered trademark of Nico Mak Computing, Inc. You can download a demo version from their web site at http://www.winzip.com. Page 72 decompress it and read what's inside. (WinZip cannot open a cpio archive.) It is also much more portable between Unix platforms than dump or cpio. * The dd Utility The dd command is not a backup command used by most people. It is a very low-level command and is designed for copying bits of information from one place to another. It does not have any knowledge of the structure of the data it is copying-it doesn't need to. Therefore, unlike dump, tar, and cpio, it is not used to copy a group of files to a backup volume. It can copy a single file, a part of a file, a raw partition, or a part of a raw partition, and can even copy data from stdin to stdout while modifying it en route. Again, although it can copy a file, it has no knowledge of the filename or contents once it has done so. It simply copies the bytes that are in the place from which you told it to copy. It then puts those bytes where you told it to put them. Although it is rather simplistic in this manner, it is extremely flexible. It can copy files or partitions regardless of format. It can translate data between two different platforms, such as EBCDIC to ASCII, or big endian to little endian.** A perfect example of dd's flexibility is the Oracle backup script included in Chapter 15, Oracle Backup & Recovery. Oracle data is allowed to be in files in the filesystem or on raw disk partitions. Since the script could not predict which configuration each DBA would use, it used dd, since it is able to copy both files and raw partitions. That way the DBA can use whichever configuration makes most sense for his application, and the script will automatically back up either configuration. It even backs up a mixed configuration, where some of the data sits on files and some sits on raw partitions. This is the kind of flexibility that ddgives you. Other Utilities There are other native backup utilities that are less well known or are available only on certain platforms. The most popular among these are listed here: pax The portable achieve exchange, or pax, utility produces a portable archive that conforms to the Archive/Interchange File Format specified in IEEE Std. 1003.1-1988. pax also can read and write a number of other file formats such as tar or * The DJGPP project, a port of gcc and the GNU tools and utilities suites to MS-DOS and Windows, made cpio its portable archive standard and has ported both GNU cpio and GNU tar to DOS and Windows as 32-bit executables. ** The concept of big endian/little endian is explained in detail in "The Little Endian That Couldn't later in this chapter. Page 73 cpio. Like many things in the Unix world, pax has a group of devoted followers that swear it's the best way to go. fbackup The fbackup utility is available only on HP-UX and is the utility that HP's System Administration Menu (SAM) supports. Backups made with this utility can be read only on another HP-UX machine using frecover. Although the utility does have several advantages over traditional cpio and tar, I do not like its complete lack of portability. Even though you can't use SAM to perform a dump, cpio, or tar backup, I believe the portability of these three commands is worth the extra effort that it takes to use them. The explanation of dump, tar, cpio, and dd that follow are not meant to replace the manpages for those commands on your particular version of Unix. The syntax here should work on most Unix platforms, but you definitely should become familiar with the manpages for your Unix platform(s). They may contain anything from minor to major caveats for that particular OS. In some cases, vendors document an extra feature or two. Always stay up to date with the manpages for your backup command-whatever it is. Backing Up with the dump Utility For many environments, dump may be all you need to ensure good-quality backups. To use dump and restore for regular system backups, you need to understand the following: • How to use dump to back up a filesystem (with the appropriate options) • How the backup ends up on the volume • How to get the table of contents of a dump volume • How to manipulate the volume and restore from a backup created by dump • The limitations of dump and restore • What you should be doing if you are using dump on a regular basis The first thing to understand is what your dump command is and what its options are. See Table 3-1 for a listing of dump commands on various Unix versions. What follows is essentially a unified manpage for these dump-like commands on specific operating systems. Page 74 Table 3-1. dump-Like Commands on Different Unix Versions HP-UX 9.x HP-UX 10 SunOS IRIX Solaris SCO Network Appliance AIX Linux SGI Digital Unix SunOS IRIX Solaris SCO Appliance AIX Linux SGI Unix (r)dump ufsdump xdump a dump backup and rdump dump dump and xfsdump b dump and vdump a SCO's xdump, a link to xbackup, works only with XENIX filesystems. There is another command, called backup, which is really a link to cpio, which works with non-XENIX filesystems. SCO's xdump is also missing two options-the b ''blocking factor" and the n "notify" options-which are standard on other Unix systems. SCO's xdump does not support remote devices. Its companion, xrestore, is also quite different from the other versions of restore. b SGI's xfsdump is the least standard dump-like command. It does not "work and play well" with other dump commands. For example, it rewinds the tape before it starts (regardless of the device you use), makes multiple tapes files per dump, and does not support remote devices on non-SGI systems. One of the ways to get around some of these errors is to pipe the output of xfsdump through dd. dump and restore Save the Day It had been a long, hard week and we were trying to finish up a few things so we could go home. That's when we got the call. That's always when you get the call. A very important directory, which contained a seldom used but essential utility, was missing from the system. "No problem," I said, "we've got it on tape." So I thought. When I went to recover the files, I realized that this directory had been missing for a while. In fact, it had been missing for so long that it had not been backed up by the commercial utility we were using. You can imagine the feeling that was in my stomach. I looked up on the old filing cabinet where we kept a pile of poorly organized, inadequately labeled, and almost forgotten ufsdump tapes. But right now, they were the most important tapes in the world, since they had been made before we started using the commercial utility. I put those tapes in the drive, one by one, using the table of contents option of ufsrestore, in hopes that one of them would be the right one. The stack was getting shorter and shorter. Finally, one of the tapes looked like it could be the one. I switched modes, using the interactive option, and there it was. I selected the directory and extracted it. The directory was saved, and the customer never even knew that we almost weren't able to restore the data. That was one day I was really glad that I knew dump and restore. (I also learned how important it was to archive monthly full backups.) Page 75 Syntax of the dump Command Let's start with the basic dump commands: # dump levelunbdsf blkg-factor density size device-name file_system The following are examples of running this command: • Command to create a full backup of /home to a local tape drive called /dev/rmt/Ocbn: # dump 0unbdsf 126 141000 11500 /dev/rmt/0cbn /home • Command to create a full backup of/home to an optical or CD device called /backup/home.dump: # dump 0unbdsf 126 141000 11500 /backup/home.dump/home • Command to create a full backup of /home to the remote tape drive /dev/rmt/Ocbn on elvis: # (r)dump 0unbdsf 126 141000 11500 elvis:/dev/rmt/0cbn /home The preceding commands are comprised of three options (o, u, and n) that do not require arguments and four options (b, d, s, and f) that do require a "companion" argument. The dump command accepts as its first argument a list of options, then each option's argument is placed on the command line in the same order in which the options are listed. This is illustrated in Figure 3-1. Figure 3-1. Sample dump command The Options to the dump Command The dump utility has seven main options that are available on most platforms: 0-9 Specifies the level of backup that dump should perform. b Specifies the blocking factor that dump should use. u Tells dump to update the dumpdates file. Page 76 n Tells dump to notify the members of the operator group when a dump is completed. d and s Tell dump how large the backup volume is. dump uses these numbers to estimate how much "tape" is available. f Tells dump what device to use. W, w These little-used options tell dump to perform a dry run that tells you what filesystems need to be backed up. If you are using dump for regular system backups, you should be using most of the preceding options. It is important to note that many of these options have default values-eliminating the need to specify that option and its argument in the dump command. For example, the default backup level is usually 9. The problem with the default values is that they vary between operating systems and may also vary even on the same operating system, depending on factors such as media type. It is better to specify each of these options the same way on all your dump backups, to make restores at a later date easier. The dump utility options are described in detail below. Option: specifying a complete or incremental backup (0-9) The first argument that you can specify is the dump level. You use any number from 0 to 9. (See Chapter 2 for an explanation of backup levels.) Incremental dumps refer to the dumpdates file for the date of the last lower-level backup. (This file is discussed later under the -u option.) For example, if you are performing a level-5 backup, dump backs up all files that have changed since the last level-4 or lower backup. It gets the date of this backup from dumpdates (usually /etc/dumpdates). Since the dumpdates file is needed for incremental backups, you must use the -u option to update it. (The -u option is discussed later.) Option: specifying a blocking factor (b) The b option specifies the number of blocks to write in a single output operation. This refers to the number of physical blocks. The size of the entire block that dump will write depends on the size of the physical block multiplied by the blocking factor. For most versions of Unix, the physical block size for dump is 1024 bytes. So, if you specify a blocking factor of 10, the size of the actual block that dump will write is 10,240, or 10K. This option is not available on SCO. (See the section, "What is a block and why should I care?" at the end of this chapter for more information about block sizes.) Page 77 There was at least one flavor of Unix that allowed you to change the blocking factor for dump but not for restore. This means that you would be allowed to make dump volumes that you could not read! Make sure that your flavor of restore allows you to change the blocking factor. (The particular flavor of Unix was Ultrix, and they have now added code to the restore command that automatically detects block sizes up to 32K. They then limited dump to a blocking factor of 32. This sounds like the wrong way to go, but at least it works.) Option: updating the dumpdates file (u) The -u option causes dump to update the dumpdates file for the filesystem that you backed up. (The dumpdates file is usually /etc/dumpdates but is /var/adm/dumpdates on HP-UX 10.x.) This is plain text file that lists each filesystem's raw device and the date that the last backup of each level was taken on that device. Here is an example /etc/dumpdates file taken from a Solaris box: /dev/rdsk/c0t1d0s0 0 Thu Sep 30 23:07:22 1999 /dev/rdsk/c0t1d0s0 1 Sun Oct 3 02:49:51 1999 /dev/rdsk/c0t3d0s0 0 Wed Oct 20 00:31:49 1999 /dev/rdsk/c0t3d0s0 1 Fri Oct 29 01:33:33 1999 /dev/rdsk/c0t3d0s0 5 Sun Oct 31 00:28:14 1999 /dev/rdsk/c0t3d0s4 0 Thu Jul 22 17:41:25 1999 /dev/rdsk/c0t3d0s4 1 Sun Jul 25 01:01:24 1999 You can see that device c0t1d0s0 had a level-0 backup on September 30, 1999, and a level 1-backup on October 3, 1999. Device c0t3d0s0 had a level-0 backup on October 20, 1999, a level 1 on October 29, and a level 5 on October 31. There are a few important things to note about the dumpdates file. (See Table 3-2 for the various names and locations of the dumpdates file.) The first time you run dump on a system, you must first create an empty dumpdates file, and it must be owned by root. If it is not there or is not owned by root, dump does not create it. Your dump will continue, but it will complain. Note that dumpdates is updated only if the entire dump completes successfully. If there are any errors that cause dump to abort, then dumpdates will not be updated. This means that it is a good file to use for an automated script that checks to see if your dumps worked. You might not want to use the -u option when making a special "one-time" backup volume, since doing so will change the behavior of other backups. For example, if you are making a one-time level-0 backup for someone and used the -u option, your automated level-1 backups would reference that level-0 backup that has been given to someone else and is not a part of your normal backup pool. Page 78 Table 3-2. Locations and Names of the dumpdates File HP-UX 9.x, SunOS, Solaris, AIX, Linux, IRIX HP-UX 10.0 SCO /etc/dumpdates /var/adm/dumpdates /etc/ddate The dumpdates file, whatever it may be called, can be viewed or modified with a standard text editor. You might want to do this, for example, if you know that this week's level-0 backup has been eaten by a hungry tape drive. You don't have time to return a full level 0 again, but you want some sort of backup. However, if you run a level 1, it will reference this week's level 0-backup, which you know is no good. You can edit the level-0 line for the appropriate filesystem, changing the date to the date of last week's level 0 that has not been eaten. Your level 1s will then reference that last week's level 0, rather than this week's level 0, which was destroyed. This can allow you to sleep a little better after that level 0 is destroyed, without having to rerun a complete level 0. Option: notifying your backup operators (n) The n option causes dump to notify everyone in the operator group, as specified in the /etc/group file, if a dump backup requires attention. This notification looks similar to a wall message. (This option is not available on SCO.) A dump backup may require attention when any of the following occurs: • A dump backup reaches the end of a tap, or your CD fills up. • A backup drive is malfunctioning, causing write errors. • There are difficulties reading from the disk drive. Option: specifying density and size (d and s) The density (d) and size (s) options do not affect how data is written to the backup media. The dump command uses them only to determine how much data can fit on a given volume and to determine when it has reached the logical-end-of-tape (LEOT, or the point at which dump thinks the volume is full) before it reaches the physical-end-of-tape (PEOT). dump then prompts the operator to switch volumes. The logic behind this is to keep the volume from hitting PEOT, since older versions of dump do not handle this well. Here is a quick explanation of these two flags: d (density). By specifying a density, you are telling dump how much data will fit on one inch of tape. (This value is really a throwback to the nine-track tape days, but dump uses it in combination with the s option to figure out how large the Page 79 backup volume is.) If you want to make sure that dump uses the entire volume, use a large value like 80,000. s ("tape" size in feet). This option tells dump how long the tape is. It then calculates how much data will fit on the tape using the values provided for size and density. If you want to make sure that dump uses the entire volume, use a large value like 500,000. Using 80,000 as the density and 500,000 as the size effectively tells dump that your volume is capable of storing 480 GB! (Yes, this and the d option both seem silly if you're backing up to disk or CD, but they [...]... level of backup to perform, what device to use, what file to log to, and what systems to back up To do this, issue the following hostdump.sh command: # hostdump.sh level device logfile system_list For example, to perform a level 0 backup of apollo and elvis to /dev/rmt/Ocbn on apollo and log it to /tmp /backup. log, issue the following command on apollo: # hostdump.sh 0 / dev/rmt/Ocbn /tmp /backup. log apollo... restore flexibility If a table of contents of your cpio file shows /home1/directory/somefile, you can restore it only to /home1/directory/somefile (Sometimes it is possible to use chroot to fix this, but it is very tricky!) On the other hand, if the table of contents shows /home1/directory/somefile or home1/directory/somefile you could restore it to anywhere you want by changing to another directory and. .. a blocking factor that your version of restore cannot automatically detect, then use it to tell restore which blocking factor was used If you are using dd to read the data and pipe it into restore, then you do not need to use the b option (See "What is a block and why should I care?" near the end of this chapter for more information about tape blocks and their role in backup and recovery. ) Option:... /home2 and /home3 on another What happens when you add /home4? Unless someone or something tells the backup program, it will never get backed up You'll never know it either, until someone asks you to restore /home4/yourboss/really-important-presentation-to-the-board-of-directors.doc So, whenever you are in a situation like this, whether you are using this program or not, you need to find a way to back... v option results in verbose output B, C The B and C options let you specify the block size In addition, you can specify a device or file to which cpio will send its output, rather than sending it to stdout All of these options and more also are available in the GNU version of cpio, as is the ability to use remote devices Option: specifying the output mode (o) The o option is one of the three modes of... hurt Option: requesting verbose output (v) The v option causes cpio to print the list of files that it backs up to standard error (stderr) The actual data of the cpio backup will go to standard out (stdout) (The Page 107 backup data will always go to stdout, unless your version of cpio supports the -O option, which can specify an output file or device.) Option: specifying a blocking factor of 5 120 (B)... restore to attempt to recover from read errors The following sections explain these options in more detail Option: creating a dump volume table of contents (t) The t option is used to see what files are contained on a dump volume This is a good command to include in any automated shell script that controls yourdump backups It is also handy on the backend if you are unsure of things such as the case or... variations between Unix flavors, so read the appropriate manpage Other options: interesting options for Solaris's ufsdump utility Solaris's ufsdump has a few options not found in other versions of Unix It supports the -l (autoloader), o (off-line), a (archive file), and v (verify) options: • The l, or autoloader, option ejects the tape if it reaches PEOT before dump is done It then waits up to two minutes... qualified domain name It is important to know this, since this is the name that you must put into the rhosts file Suppose your system is called apollo, and the remote system is elvis If you want to rsh from apollo to elvis, you should try the easy step first On elvis, you would enter this command: echo apollo >>/.rhosts If that doesn't work, then apollo appears as something else to elvis (e.g., apollo.domain.com)... (You will need to continue to specify the name of the system that contains the filesystem as well.) # hostdump.sh level device logfile system:/filesys system:/filesys *Or a separately named file for a disk-based backup Page 88 For example, to perform a level-0 backup of apollo and elvis's root drive to /dev/rmt/Ocbn on apollo and log it to /tmp /backup. log, issue the following command on apollo: # hostdump.sh . backup of apollo and elvis's root drive to /dev/rmt/Ocbn on apollo and log it to /tmp /backup. log, issue the following command on apollo: # hostdump.sh 0 /dev/rmt/Ocbn /tmp /backup. log apollo:/. and elvis to /dev/rmt/Ocbn on apollo and log it to /tmp /backup. log, issue the following command on apollo: # hostdump.sh 0 / dev/rmt/Ocbn /tmp /backup. log apollo elvis hostdump.sh automatically. CD. You don't care about atime; you don't want to do regular, incremental backups; you just want to get the stuff onto a backup volume, and you want it to be easy for someone else to get