
        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.