AUTOBACK for Bootable System Backups

You probably are familiar with smit mksysb. The script in Listing 1, autoback, uses this as a starting point. A shortcoming of smit mksysb is that smit.log does not show the output from the command. The idea here is to capture the output from stdout and stderr when this command is executed, so that you'll be able to start the backup automatically, from crontab. (See the sidebar, "Using crontab to Start Backups Automatically.")

The first section of autoback creates a subdirectory in which to keep listings and errors generated during backups, if the subdirectory has not already been created. Next, the tape devicename is set as a variable. In our environment, this is done by a call to a program that echoes the correct devicename. The listing shows this as commented out. You can create your own version of the program if you have different systems with various tapedrives you wish to use, and still keep the script standardized across all systems.

Notice the chdev command for setting the blocksize. With the command provided here, you never have to guess at the blocksize when you need to restore files from the tape (I once accidentally set the blocksize to zero -- the resulting tapes were unreadable!).

autoback generates output filenames based on the day of the week. That way, the names are reused after seven days, which limits the diskspace usage. This namery convention created problems when backups started after midnight on one day, then before midnight the second day: the second backup overwrote the files of the previous backup. The dayofwk command shown in Listing 2 solves this problem nicely.

Next comes the requisite /bin/mkszfile -f command (the -f option causes a forced increase of work area if required), which creates the list of filesystems and their sizes in the root volume-group. Then the mksysb command captures the listing files in Ddd.listing and the error output in Ddd.err (where Ddd is the first three letters of the day of the week).

Finally, autoback ejects the tape from the drive. I chose to do this for several reasons: (1) it is more convenient to set up the next day's backup if the tape is already ejected, and (2) if someone forgets to change the tape, then the backup from one night will not be overwritten when the next night's backup is started. Instead, someone will be notified the next day that the tape was not ready when the backup tried to start. However, I sometimes work on a weekend on a system in another city, over a modem, when no one is in the remote office to load the tape. I like the safety net of having a complete tape backup before I start, but I also like to be able to restore files by modem, if needed, before people come in the following Monday morning. So if I create a file /bin3/nounload, then for one time only the tape eject does not occur.

The autoback script in Listing 1 creates bootable backup tapes reliably, and backs up all the files in the root volume group. At a certain point, however, some of the systems needed so much disk space that it became impossible to add all the disks to rootvg. Since mksysb uses the tar command, a similar script, shown in Listing 3, was developed. The script's name, qbback, derives from the application we run on our systems, QBridge (C) (trademark of Qantel/Decesion Data Inc).

QBBACK for Non-Root Volume Group Data

qbback is similar to autoback, except that it uses the tar command instead of mksysb, and requires some additional parameters. The tape devicename is set to rmt0, but in the future the devicename could become a parameter, which would allow us to back-up separate directory hierarchies to multiple tapedrives simultaneously.

The first parameter provides an additional qualifier to specify the output listing and error files. I suggest starting the parameter with a dot. For example, if the first parameter was .jack and it was Monday, then the resulting files would be Mon.jack.listing and Mon.jack.err. The second through fifth parameters are pathnames for directories to be included in the backup. For example, the command line:

qbback .jack ./home/jack ./home/sally

would back-up everything under jack and sally directories.

Error Notification

Error notification with Listing 4, bkpchk, scans the error files by checking the file sizes. When no errors occur, the filesize will be zero for the tar command. For the mksysb command, certain messages are normally output to stderr, and with AIX release 3.4 the size is always 181 bytes when nothing unusual occurs. If the user responds affirmatively to the prompt, the files are renamed to .sav to prevent the message text from displaying at every login, but still are kept available for later study.

Epilogue

Since writing this article, I've encountered a situation whereby the error output from the backup did not indicate any problems during the backup, but several files came off the tape with zero bytes. It seems that two of the commercial backup software offerings advertised in Sys Admin magazine have a tape data verification capability, which is something the tar and backup from IBM do not have. As a result I have placed orders for evaluation copies of each package, with the expectation of purchasing one of them in the near future.

About the Author

Steve Peterson is employed by The Travelers Plan Administrators, a subsidiary of The Travelers Corporation, involved with healthcare insurance. He has worked as a VM Systems Programmer, an MVS Systems Programmer, and, in the last two years, as an RS/6000 Systems Administrator. He holds a B.S. in Physics from the University of Massachusetts, and an M.S. in Computer Science from Renuselaer Polytechnical Institute. He has also started a software company with a product for reading and writing 9-track tapes on the RS/6000.