Lots of error checking
-
I have seen too many shell scripts over the years that assume things. Do not assume that a simple command worked just because it always does. When you are automating things, check the return code of everything. If you can anticipate what causes a given error, try writing the script so that it fixes that error before you completely give up.
Notification, notification, notification
-
I cannot emphasize this enough. If your script sees something that it isn't used to seeing, you should be notified. All good activities should also be logged so that you can check those logs to make sure everything worked. Too many restores have failed because someone didn't read her backup log. If you do have a script that notifies you when things go wrong, don't assume that nothing is wrong if you don't get mail. What if cron is down? What if some minor change that you made to the script causes it to abort without a notification? What if sendmail was or is down? Never assume anything.
Proper checking of an rsh or ssh command
-
Too many scripts check the return code of the rsh/ssh command and not the return code of the command that was executed on the remote machine. Try this sometime: issue one of these commands:
$ rsh remote-system do_stuff ; echo $? $ ssh remote-system do_stuff ; echo $?
where remote-system is a system that you can rsh or ssh to, and do_stuff is a command that does not exist on that system. You will see that the command that you issue fails on remote-system, but ssh/rsh returns a successful return code of 0. That is because the rsh/ssh command succeeded, whether the command it issued succeeded or not. That is why you need syntax such as the following (ssh works here as well):
rsh apollo "ls -l /tmp/* ; echo \$?>/tmp/ls.success" SUCCESS=\Qrsh apollo cat /tmp/ls.success ; rm /tmp/ls.success\Q if [ $SUCCESS -eq 0 ] ; then #everything worked echo "Everything worked." else echo "Something bad happened!" fi
This shows you the return code of the remote command, instead of just that of the rsh or ssh command.
The preceding syntax does not work with csh, because it does not allow output redirection in the same way. One way to get around the csh problem is to create a small script that you rcp over. That script can explicitly call /bin/sh, so you can be sure you are getting that shell.
Get the table of contents from the backup volume
-
You always should reread your backup volumes, for two reasons. The first is that it is the best verification that the backup worked, short of actually restoring the data. The second is that you can store these tables of contents into a file and use that file during an actual restore to find out which volume has the file you are looking for.
The best way to verify that the dump volume is intact is to list the table of contents with the verbose option turned on, sort by inode number, and restore the last file. This reads the whole volume and ensures that the dump is intact all the way to the last file.
