CFOG's PIP, December 1988, Volume 7 No. 6, Whole No. 68, page 94

Computers, Insurance, and Risk Management

by Benjamin H. Cohen

Insurance is wonderful. You buy a computer, buy an insurance policy, pay premiums, the computer is stolen or burns up in a fire, the insurance company buys you a new one (you did get replacement cost coverage, didn't you?), and everything is hunky dory, right? Wrong.

There's a lot more at risk than your computer in that fire or theft. There's your software. There's your data. The following note in the back of the August 1988 issue of Foghorn under the heading Stolen Osborne Alert, tears at my heart: "The data, collected for the past 23 years ... is extremely valuable."

My office has a lot of time invested in entering data in the office diary. It's the only central repository of all dates for all matters pending in the office. Losing it would create an almost impossible task. So instead we protect it.

If you don't want to cry over your lost data and software, there's only one reasonably sure way to manage the risk. Insurance won't do it: no amount of money will replace your data. Even if insurance does cover the cost of recreating the data, and even if the source information still exists from which to recreate the data, by the time you can recreate it you'll be out of business (if you're in business). If it's just your hobby stuff insurance won't pay for the loss at all, and if you've spent hundreds of hours over the past half-dozen years cataloging your hobby inventory you're not likely to be overjoyed at the prospect of doing it again.

In the first place, lock up your data. If your computer has a key to prevent access, lock it when it's not in use. And don't leave the key in the lock. If you have boxes of floppy disks around, put them away in a locked cabinet at night. Bernoulli boxes are a neat solution to the risk management problem because they have removable cartridges that can be taken out and locked up. I'm seeing reports on new hard disks that have removable cartridges, too. Not only do these systems let you expand your data storage capability at reasonable prices, but the allow you to manage the risk of lost data, too.

But the securing of on-site data is only the first step. A locked cabinet won't help much in the case of a fire. And if they really want to, burglars can open the cabinet, or failing that, simply take it. So you need to make extra copies of your data and store them off-site.

The standard way to handle off-site backups is to work with three disks, or sets of disks. On day one you back up to three disks and take disk one home. On day two you back up on disks two and three, and take disk two home. On day three you bring disk one back to the office, back up on disks one and three, and take disk three home. On each subsequent day you back up on two disks and take one of them home, bringing back the previous day's backup the next morning. Of course, some data doesn't need to be backed up daily, but each time it should be backed up the same routine should be followed: make two backups, take one home, bring back the old backup the next morning. If the data is at your home, take the backup somewhere else: if you run your business out of your home, store the backups it an off-site storage locker, at your brother-in-law's home, anywhere, so long as it's not at risk to be burgled or burned at the same time as the house.

There are a number of ways to do backups, all of which depend on how your system is set up and whether you're using CP/M, MS-DOS, or something else. For CP/M users SUBMIT routines and for MS-DOS users BATch routines are great. Set up the last command in the batch or submit file as an automatic backup.

For example, my main system is a Kaypro 1 with a 2 Mb Drive C2 RAM disk. I keep my working files on floppy disks as backup. There are about 50 or 60 active disks, and I need a master catalog so I can find files quickly. Each time I put a new file on a disk I turn it sideways in the storage box. When it's time to update the catalog, DOCAT.SUB takes care of the reminder to back up the MAST.CAT file:

l ncat b:
echo is the master catalog disk in B:?
pause
crunch mast.cat b:
era *.bak

The first line runs NCAT372 out of my COMMAND.LBR. The "L" command is actually LDIR23.COM, which defaults to a LBR called COMMAND. This is a neat space saving device on the RAM disk where files are stored in 4K blocks. NCAT prompts me to put a disk in drive B: and enter a "Y" when ready, an "N" when done.

When I'm done updating the catalog, the second command reminds me to put the master catalog disk in drive B:. The third command, PAUSE, is a little SUBMIT utility that asks you to enter "A" to abort the process, or any other key to continue when ready. When the master catalog disk is in drive B: I hit any key other than "A".

The next command crunches a copy of the mast.cat file onto drive B:. Finally, DOCAT erases all the ".BAK" files on the disk: NCAT creates a MAST.BAK file that I want to delete now, and I might as well clean up any other BAK files at the same time.

I have similar SUBmit or ZCPR Alias commands for many of the data entry routines that I do on a regular basis. At the end of the process I'm forced to make a backup copy of the database that has just been updated.

Insurance is only one aspect of risk management. If you spend the dollars on backup and off-site storage you won't need the insurance AND you'll be up and running as soon as you can get a replacement computer going. Don't think about it: act on it.