###   Projekte und Informationen rund um den KC85   ### 



CFOG's PIP, July 1986, Volume 4 No. 9, Whole No. 45, page 8

Backups: A Real World Analysis

Copyright 1986 James Ayres. All Rights Reserved.

When computer systems first gained widespread acceptance in the business world, two very important procedures became almost universal practices. First, the inevitable practice of destroying one's data and second, the wise practice of making regular backups for use after completeing the first procedure. Until recently, the chant heard throughout the user community has been "Backup, backup, backup".

Every user has his or her favorite story about someone they know (we all know what that phrase means) who:

a) Left their diskette in the sun,
b) Formatted a diskette or hard disk,
c) Allow a magnet to have its way with an unsuspecting diskette, or
d) Lost their data to sun spots.

For example, a cousin of my wife's mother-in-law's brother's son once formatted a diskette that contained the only back up copy of the machine's operating system.

Most users of CP/M machines would not consider running their machine in a business environment without making, on a regular basis, backup copies of their data and program files. This article is not directed to them. However, they may continue reading and bask in a warm glow of self-satisfaction.

In the MSDOS world, there is a strange practice called copy protection. For those of you who don't know what copy protection is, copy protection is a practice whereby some software vendor, deciding that a significant portion of its customers are criminals, does some completely unorthodox programming and provides the user with a program that either secretly modifies the hardware or the operating system.

Copy protection has provided many programmers hours of entertainment. First, we have the group of programmers who spend many hours devising copy protection schemes. They are entertained by the fact that someone is paying them to do this because we have a second group of programmers (most likely men and women made of the same stock as those who founded this country and settled the West), who, living for the opportunity to challenge the unknown, spend a few hours developing ways to unprotect copy protected software.

For a point of clarity, it is this author's opinion that unprotected software is the best protection against a disaster (but by now I think you knew that).

Some early copy protection schemes used unorthodox techniques. For example, I am told that some early schemes used that fact that a floppy disk controller would write to track 41 of a 40 track diskette and used that fact to write copy "protection" information there. This apparently didn't work too well when subsequcnt upgrade to the operating system fixed this bug. (Come on, using a bug in the operating system as a required part of your program!)

The most recent attempt at copy protection on hard disk machines involves writing invisible files on the hard disk. Because these files are invisiblc, they cannot be backed up. Even if one made them visible and made backups, these files must also reside in the same physical location on the hard disk as when they were first "installed".

Which brings me to the point of this article -- if you seriously intend to use a program to automate a significant part of your livelihood (like accounting, data base management, etc.), and you cannot be with out the use of that information for an extended period of time, then you cannot afford to use copy protected software. If you can't make backups and restore your lost files (and we all know "someone" who has done this), then you should not be using copy protected software. Using copy protected software is about as rational a business practice as keeping your accounts receivables on flash paper next to the furnace.