Hello again from Little Rock. As regular readers may remember, I am supposed to be writing about intellectual property law. Supposedly we will be fielding questions eventually when some interesting ones accumulate. As followers of the column (if there are any!) might appreciate, this article was supposed to be about "copyrights." I was supposed to follow up on our previous articles on patents and trademarks distributed in the last months. However, I want to digress. This office uses so many computers and has tried so many operating systems that a persistent and persuasive PITA has yet again troubled us! That is the problem of conveniently "backing up" software. As basic as that sounds, too many people ignore the problem. Even those who have worked out "backup" routines may be in for a shock when they try to "restore" if they ever have to! I was partially motivated to mention this issue after visiting the Arkansas River Valley BBS one night two weeks ago to work on some multi-node networking software. A client has developed a little network program called LANUS, that allows a BBS to operate with several "nodes." The sysop, Michael Gray, is beta testing the program. ARVOS BBS is located in central Arkansas (501) 968-1931, and violent weather involving high winds and tornadoes is not infrequent. We were faced with six computers all hooked together, and in the middle of everything, the lights went out. The sky turned grey and green, and suspicious tumbling and twisting clouds blew over us. The lightning and thunder was not as threaten- ing as the radio report of three tornadoes on the ground. Needless to say, it is not real productive working on computers by candlelight! Power failures like this undoubtedly can result in a "crash," especially when a new software installation is only half finished. At my office we use an uninterruptible power supply for the network server. But "power" backup is not what I want to talk about. It is increasingly difficult for my office to run software back-ups properly. We have struggled with different forms of doing this and tried many different systems. The problem is getting worse, especially with the larger 32 bit operating systems that we've tried. These are so cumbersome that you usually cannot even boot up with a single disk. So I want to take the liberty of giving a few pointers on software backups from what we have learned the hard way. So many times, people warn that these back-ups are necessary because your hard disk may "crash." That may be, but we have had a variety of lost-file problems having nothing to do with hard disks mechanically crashing. We do lose a hard disk about once a year. However, even without the disk mechanically "crashing" there are a number of ways you can lose important files. For example, some 32 bit operating systems install a little boot program on your hard drive that lets you switch between two or more operating systems when you boot up. OS2 is this way. It can install a "boot manager" program that lets you choose between OS2 and DOS when you boot up. (It is a bear to install properly!) LINUX, a "freeware" version of the unix operating system, comes with a neat CDROM and a single floppy that facilitates installation. It can create a "lilo boot" program that lets you have an OS choice at boot time. If you try either of these, watch out for DOS virus checking programs! If for example, you run DOS's virus checker MSAV.EXE on the dos partition, your system may go crazy when the "foreign" boot program is discovered. With OS2 I lost the contents of my entire hardrive after a laborious installation, with the DOS file allocation tables corrupted irretrievably. Low and high level formats followed by a tape restore were necessary. I could give numerous other examples. But the point is you better be ready to restore. More on that in a minute... On some of our older 286's we are still spinning some old MFM Seagate drives which are five to eight years old. We replace old MFM drives with modern IDE drives. They usually warn you about a week in advance that troubles are imminent. The IDE drives are pretty neat, they seem to spin pretty reliably, and although they have their disadvantages, they are certainly better than an NFM drive. Newer computers have IDE hard-drive ports on the motherboard, but with older systems you need a separate IDE controller card. Simple IDE controller cards are available for roughly Fifteen Dollars from a variety of vendors. One problem is that with older '286-class machines you might not be able to configure your CMOS memory properly for IDE. You need to tell your system that you have a "type 47" user defined hard drive. Entering the IDE parameters is required to make that work. Older computers may need a new "bios" chip to facilitate this. Anyway, we have lost important data a variety of ways. We have frequent thunderstorms and power outages here during the summer when high velocity winds and storm fronts move through at regular intervals, and unless you have a well powered back-up system, the device is likely to shut down right in front of you. Although we have our critical file servers backed up with a "Best Technologies" battery back-up system, which so far has proven infallible, the remainder of our computers are not so backed up. I have noticed that computers with "cheap" over-the-counter power supplies crash the fastest the A.C. power flickers. If this occurs in the middle of something important, you may be in for a "restore." Thus we often use little batch files to repeatedly back up critical files. It is quite common for folks to use little batch files to copy recently edited documents to an appropriate location. A simple approach is just "COPY *.* A:\BACKUP." I would usually rather use "XCOPY." One way to make a limited backup of a crucial subdirectory, for example, is with XCOPY. This command can create a series of floppy disks that are not compressed or encrypted, and that can be readily used to retrieve files. Unlike a compressed backup disk, floppies that have "X-copied" files on them are easier to use for a "restore." You simply locate the corrupted file, and copy it over, without running dos's tedious "restore.exe." Windows ".ini? files, for example, should all be backed up this way. Within a given directory, try something like this: XCOPY *.* A:\ /M /E /V If you do this, you can keep putting floppies in the A drive, and have a matching directory structure from which a recovery can be done very easily. The parameters set the "archive attribute" in the files to be backed up. This enables you to simply stick in another floppy and continue the process after one floppy is full. Or you could direct the backup to a large hard drive. You can seek out back-up files directly from these floppies this way, without having to go through the whole series of floppies as you would with a traditional restore command. Afterwards, go back into the subdirectory you just backed up and execute an "attrib +A *.*" For more complicated networked systems, where mission critical information simply *must* be available, we make backups from the server to the local machine. A "cute" batch file approach from PC Computing Magazine helps make backups for us with the XCOPY command. Something like this might advantageously be put in your utility or batch subdirectory, and should be properly "pathed" in. It is particularly advantageous since it switches files between hard drives. (By the way, if you type "set" at the command prompt, you should be able to see what your path is on your system). In the local machine's batch subdirectory we include the files zz.bat and current.bat. ZZ.BAT is as follows: @ECHO OFF ECHO.|DATE>D:\TEMPBAT.BAT CALL D:\TEMPBAT.BAT DEL D:\TEMPBAT.BAT IF NOT EXIST L:\USR\SDC\BACKUP\NUL GOTO ONE ECHO "COPYING TO NETWORK" XCOPY *.* L:\USR\SDC\BACKUP\%DAY% /D:%DATE% GOTO TWO :ONE ECHO "CANNOT COPY TO NETWORK!" GOTO THREE :TWO XCOPY *.* C:\BACKUP\%DAY% /D:%DATE% ECHO "COPYING TO LOCAL BACKUP" :THREE CURRENT.BAT is as follows: @ECHO OFF SET DATE=%4 SET DAY=%3 When you invoke this batch file, a couple of interesting things happen. Files are "xcopied" to an appropriate subdirectory labeled MON or TUE or WED etc. within a \backup directory. The piped echo statement takes today's date, and forces it into a temporary file called "tempbat.bat." This records the time and in tempbat.bat, the first word of which is "current." Since the first word in "temp.bat" is "current," a call to the latter batch file invokes the separate batch file "current.bat" and executes it. The "%3" variable is the day, and the "%4" variable is the date. In effect for any newly created file or batch file, the x-copy lines effectively take a recently edited file and copy it to a suitable subdirectory within the network and on the local hard drive. For absolutely critical files, we don't want to write over "yesterday's" draft necessarily, so we end up with a separate back-up file for Monday through Sunday. Now this little technique can work very well and save you some precious hours on particularly difficult cases, especially when you use it often and on a local daily routine. (It depends upon the program you are using changing the time and date stamp on new files- some programs, perhaps like WordPerfect, do not do this!) For the larger serious back-ups, we have tried virtually everything. Of course, one can use the old "backup.exe" command from older versions of DOS. This is a terribly slow way of doing it, but it is better than nothing. Files are slowly backed up in compressed form across a number of floppies. Although this is faster and requires less disks than the XCOPY example above, it has flaws. For one thing, you cannot easily inspect what is on each backup disk. Secondly, the "restore" process is a tedious time consuming chore that "overkills" simple jobs that merely demand the recovery of a few files. Unfortunately, in my humble opinion, the new version of MS back-up in DOS 6.2, is pretty bad; regrettably, one has to jump through a number of graphical hoops, which even further complicate and slow down the procedure. For critical programs, I would prefer not to encrypt the back-up through DOS's back -up or other back-up programs like Fastback and others. We have also tried backing up with tape drives. They have their advantages in certain circumstances. With unix, for example, back-ups can be scheduled to run unattended in the background while other users are running other programs. Multiuser operating systems offer this flexibility. Even with DOS, backups can be scheduled at night, and it's an advantage. It comes on by itself and finishes without any human intervention. One problem with tape drives is that every time you stick a tape in, you have to wait seemingly forever for the tape to rewind and reposition itself. A bigger problem is that they have at least one thousand ways to screw up when you try a critical restore. It's unbelievable how many error messages tape drives have. In my view tapes simply are not "real world" devices, at least for those on limited budgets. It seems to me that with the declining cost of large IDE hard drives, a better way to backup is to add a hard drive, and either "backup" or "xcopy" to it. In our critical CAD machine, for example, we use two IDE hard drives, and on that subject, we have configured them both as "masters." One way to hook two IDE drives together is to run a single cable from your hard drive controller (or motherboard) to a pair of IDE drives, one configured as "master" and one configured as "slave." When the high level formatting progresses, both of those drives are united into one logical drive unit. I recommend against this. The second drive cannot be used as a reliable backup this way; if the master crashes, the FAT on the second drive is irrecoverable! A better way is to run two drive cables to two separate IDE drives, both configured as "masters." Before install -ing the second drive, make it "bootable." Disconnect the first drive, change the computer cmos parameters if necessary, and format /s the new drive. Make sure you can boot from it. Then put the first drive back, and make the new drive "drive d:" or something. If we end up with two drives complete with system files and critical back-ups, then you could modify the above file, "zz.bat" for example, to "xcopy" back-ups from one hard drive to another. In fact, if you could afford it, and if you're thinking about buying a tape drive, why not spend a little bit of money for a cheap hard drive instead? The back-ups go from one hard drive to the other. If you have a real bad crash, simply disconnect the dead drive, plug its 40 pin IDE connector into the former second drive, change cmos, and boot from that! This is at least ten times faster and more reliable than restoring from tape! And I think it costs about the same. The real problem with tapes occurs when you try and restore; if you haven't tried this yet you may be if for a horrible surprise! Another good idea is the "removable" hard drive. IMHO, cheap IDE drives are removable too, in five minutes the thing can be popped in or out if you simply go "under the hood." Anyway, we have an SCSI network server running LANUS SERVER. The Bernoulli-brand SCSI-2 drive has been used on our network server with great success. These come in a variety of flavors, and the model we use has replaceable 150 megabyte platters. The unit plugs into an SCSI-2 Adaptec EISA controller card, and it installed easily and quickly. The unit powers down after inactivity; it powers up and spins when you address that drive (in our case D:). It is fantastically better than a tape drive. You don't have to sit for 20 minutes listening to tapes go WHRRRRRRRRRRRRRRRRRRRR! Tremendous back-ups can be made very, very quickly and dependably, without waiting for the seemingly infinite rewinding of tape back-up units. Since the cost of these drives is dropping, I think you should carefully consider using a removable hard drive or just a duplicate IDE drive. SDC here.