The Sun Observer, Volume 8 No.10
Peter V. Radatti
radatti@cyber.com
CyberSoft
October 10 1995
Notice: Copyright September 24, 1995 by Peter V. Radatti, All rights reserved.
Welcome to the seventh in this series of articles. Many of you have taken advantage of my email address published at the end of each article to let me know how you would like this column to develop. As a demonstration of the power of communications this month's article is at the request of one of you that wrote to me. Feel free to write, send gifts, money, or what have you. Visa, MasterCard accepted! Seriously, the more feed back you provide to me the more you will enjoy this column.
Today we discuss a job that so very many people seem to despise but is essential to happy computing. The subject is backup. It is essential that systems be backed up on a regular basis. We here at CyberSoft perform regular backups and just received the benefits of this policy when the hard disk crashed on one of our critical business systems. The system was repaired and everything was recovered from our backup tape except for 2 or 3 days of work which happened to be located on a separate system. This could have been a catastrophe but wasn't.
The backup script is written in my favorite script language, C-shell and executes on a SunOS 4.1.3 system. Since I use this program on different systems with differing peripherals I like to set all of the most important values as variables at the beginning of the program. Notice directly below the "Setting backup variables" that I do this. Then the program tests to see if it is executing as the "root" user. If not, it tells me and aborts the program. The next if-then structure tests to see if the program is running on the server with the tape drive, "rinc1". If the program is not on the correct system it tells me and aborts.
The next few blocks of code looks around the network to see if the systems the program wants to backup are on-line. There are two reasons to do this. First, I like to build an index of what is going to be on the backup tape. This is a normal procedure with me. I want the first file on the tape to be a report of what is on the tape along with a date stamp. I don't trust what someone may have written on the label of the tape, I want to know what I may be restoring. Since we reached this part, the program is running on the "rinc1" system and there is no need to test if "rinc1" is on-line. We start the report file by putting out a message that the tape contains trade secret material of CyberSoft, Inc. along with telephone numbers and the date stamp. The program then starts to build the table of contents. The first file on the tape is always the report followed by the partitions on the "rinc1" system. We then set a counter that will be incriminated as we locate system partitions on the network.
In the next paragraph of code we start by setting a flag called "bamflag" to "no". This is the default value and means that the system is not on-line and available for backup. We then test to see if the system is on-line by attempting to "ping" it. Remember that the "$status" variable contains the execution status of the previous command. If the "ping" was successful then we write a message for every partition on the "bambi" system to the report file. Notice that we increment the "counter" variable after every partition. The "counter" variable is keeping track of the file numbers on the tape. In this case, the "/dev/dsk/c0t3d0a0" partition will be the 5th file on the tape. This will make it easy to know how many files to skip on the tape if I need to restore part of a partition. Finally, we reset the "bamflag" to "ok" to indicate that it is ready for backup. We then repeat this process for the "egate" system. There are other systems on our network but the code looks the same and was not presented as redundant.
Once the tape table of contents is complete we save the disk partition information to the report by executing a "dkinfo" for "egate" which is running SunOS 4.1.3 and a "prtvtoc" for "bambi" which is running a Solaris 2.4 operating system. This information will be a big help if the disk drive has a crash and has to be reformatted.
Next, we check the 8mm tape drive to insure everything is ready for backup. We rewind the tape followed by checking the status. Notice that if the tape is not ready the program aborts leaving the message "TAPE NOT READY" on the screen. This has saved me from wasting lots of time in the past. All of the code to this point executes in about one minute and I used to have the program pause for me but long ago I determined that there was no reason to pause since if there was a problem the program would abort and wait for me to return. I commented out the old code that said "PRESS RETURN TO CONTINUE" and not the program goes directly to writing the report to the tape. I like to use the "tar" command for the report even though I used the "dump", "rdump" and "ufsdump" commands for the actual disk partitions. This is a matter of preference and you can change it to "cpio" or anything else that you prefer.
The first system dumped is "rinc1" there is no conditional code for this system since we are executing on it. The next code block tests to see if the "bamflag" is set for backup and then performs it. Since the "bambi" system executes Solaris 2.4 we use the "ufsdump" command to back it up. Notice that the "ufsdump" command is executed as a remote command using "rsh" with the results being returned to "$rdumpdev" which we set to "rinc1:/dev/nrst1" at the beginning of the program. Next we backup "egate" using "rsh" and "rdump" again returning the results to "$rdumpdev". Notice that there is some extra code at the beginning of the "egate" backup. The "egate" system is considered untrusted since it has a modem. CyberSoft has taken special considerations to insure the security of this system and its isolation from the internal network. First, only the "rinc1" system knows the address of "egate" and "rinc1" does not have "egate" in it's "/.rhosts" files. It is necessary for "egate" to be listed in this file, one "rinc1" so that the backup program will be allowed to access it for writing to the tape drive. We therefor save a good copy of the "/.rhosts" file to /.rhosts-backup" and append "egate" to the original file. We then execute the dumps followed by restoring the original contents to "/.rhosts" at the completion of the dumps. Notice that we are careful to only allow access for the period in which the dumps are being executed. In addition, we custom designed an ethernet switch which requires manual intervention to allow "egate" access to the internal network. There is no software interface to the switch and it can not be operated without the physical presence of an operator. While "egate" has access to the network we disable the modem by turning it's power off. Finally, the system performs cryptographic and virus checks using our VFind anti-virus scanner and CIT cryptographic integrity subsystem. This may seem like overkill but it is very important to us that outsiders not access our internal network.
The program finishes up by rewinding the tape and ejecting it from the tape drive. If you are using a Sun Microsystems computer then I strongly suggest you review the "dump" and "ufsdump" commands as options for backing up your system. I personally feel that the "restore" portion of these programs make them worth the cost of using. They are certainly better than using "cpio" or "tar". Feel free to modify this program for your own use and let me know how it works for you!
Pete Radatti is the founder and CEO of CyberSoft, Inc. CyberSoft manufactures, VFind the an antivirus software product that executes under Unix and simultaneously scans for Unix, MS-DOS, Macintosh and Amiga destructive software. You can reach Pete at radatti@cyber.com. Thanks for all the nice letters!
