Software and Manual are Copyright © 1989, 1991, Jeffrey A. Lomicka
An up to date backup is essential to prevent the loss of the data stored on your computer disk drive, in the event the data on the drive becomes inaccessible. A backup not only protects you against the failure of your hard disk hardware, but can also protect you against data loss due to system software errors, theft, natural disaster, and most often, against your own mistakes. Hours, days, or even months of work can be lost through simple mistakes, such as momentarily thinking that the trash can icon was for your floppy disk drive.
The GOOD Backup Utility is an Atari-ST compatible program that provides a convenient way to keep an up-to-date backup copy of your valuable data and programs. The program has features that make it quick and easy to keep your backup current.
Features of the GOOD Backup Utility:
- Easy to use form style user interface.
- Copies data from a selected active disk partition to a saveset of backup disks.
- You can keep your backup saveset on single or double sided floppy disks, removable cartridge drives, or keep a shadow partition on another hard disk unit.
- Backup saveset disks are ordinary TOS formatted disks. You can read the backup copies of your files the same as you read any other TOS disk.
- Any file that does not fit on a single saveset disk will be split across as many disks as needed.
- A backup can be interrupted before it is done, to be completed later. You aren't forced to perform the entire backup at once. - Updates to the backup will only copy the files that have actually changed. If you update your backup frequently, which you should do in order to protect your data, the update goes very quickly.
- No need to pre-format floppy disks used for the backup saveset. The GOOD Backup Utility can format single or double sided floppy disks as additional disks are needed.
- Checksums are used to verify that the files on the active disk drive and on the backup disks are all intact. Errors can be detected and corrected before they become costly.
- Write back disk cache technology is used to minimize the head motion on the disk drives. This makes the file copying go fast.
- Lost or damaged disks in the backup saveset can be replaced without replacing the entire backup saveset.
- Up to 16 wildcard file specifications can be given as a list of files that will not be kept in the backup saveset. The selections are automatically remembered and reused when the backup saveset is updated.
- Instead of specifying files to be excluded from the backup saveset, the 16 wildcard file specifications can list the files to include in the backup, excluding all others.
- Files can be restored as an entire partition, or by wildcard selection. When restoring an entire partition, only files that are actually missing need to be restored.
- A reference list can be produced for locating individual files within the backup saveset.
- Pressing the HELP key will provide additional information at every step.
The protection you get from the GOOD Backup Utility depends on how you use it. If, for example, you keep only one backup saveset and store it with your computer, you will not be protected against loss due to fire or theft. If you don't update your backup after a hard day's work, you run the risk of having to repeat a hard day's work. To minimize the probability of data loss, follow these guidelines.
- Always keep at least two savesets of each partition. There are times while a backup is in progres that a catastrophic event, such as a power failure, would leave some files off the backup. With two savesets, you can always recover an older version of any such files.
- Keep one saveset close to your computer, and update it every day that you use your computer. If you update often, the GOOD Backup Utility will run very quickly, and you leave the computer knowing that the work you've done is safe. Any work you do that isn't on a backup saveset, is work you must be willing to repeat in event of a disk problem.
- Store one saveset in a safe place away from your computer, ideally in another building. A safe deposit box would be a good choice, or just leave a saveset with a trusted friend. You can revert to this saveset in the event you lose both your hard disk and your backup saveset to the same calamity.
- Frequently swap the saveset in storage with the saveset kept near your computer. How often you should swap savesets depends on how much you use the computer. If you are a very active user, you should swap weekly. Even with infrequent use, you should not let the stored saveset go more than a month or two.
- Archive an entire saveset every six months or every year. Should a data problem go unnoticed for a long time, you may be able to retrieve the affected files from such an archive.
These guidelines may sound overly paranoid, but consider this: in the event of a loss, no amount of insurance can ever replace the data that you generated. If you were writing a novel, composing a score, or writing a new computer application, and you don't have a backup, the best anybody can ever do for you is give you some blank disks and say Sorry, you'll have to start again.
Running the GOOD Backup Utility
The GOOD Backup Utility is distributed on one single-sided floppy disk. The disk contains the program GOOD.TOS. To start a backup operation, you simply run this program. Insert the GOOD Backup Utility distribution disk, open the disk drive icon, and double-click with the mouse over the GOOD.TOS icon.
You should keep a copy of GOOD.TOS in a convenient place on your hard disk drive, where it will remind you to update your backup frequently. Remember, however, that if your hard disk drive fails, you will not have access to this copy, so you should also keep a spare copy of GOOD.TOS on a floppy disk, stored with your backup data. The program is self contained. To install the program on your hard disk, you simply copy the file GOOD.TOS to a suitable folder.
The GOOD Backup Utility presents you with some questions, each of which has a default answer. All questions and queries from GOOD.TOS are one of two forms:
- Multiple choice questions
- Fill-in-the-blank questions
Most of your interaction with GOOD can be accomplished using only the arrow keys, HELP key, and the UNDO key.
The keys on the keyboard can be used in the following ways:
Help - displays a help page that describes the current question in more detail.
Undo or Enter - confirms that you are done with the form, and that the program should continue. Think of this key as Do, rather than as Undo.
Up/Down arrows - moves from question to question within a form without changing the answers. The current question is highlighted in reversed color.
Left/Right arrows - changes the answer of multiple-choice questions, or moves the editing cursor in fill-in-the-blank questions.
Function keys - goes directly to a specific question, as indicated on the form. On forms that have more than ten questions, the shifted function keys are used to access the additional questions. Striking the function key for the currently selected question will change the answer of multiple choice questions.
RETURN - moves to the next question.
ESC - erases a fill-in-the-blank answer.
Control-C - cancels the current operation.
Pressing the first letter of a choice will change the answer of multiple choice question directly to that choice.
Fill-in-the-blank answers can be edited with Backspace, Delete, and the main keyboard keys in the usual way.
Creating or Updating a Backup Saveset
The GOOD Backup Utility operates on one disk partition at a time. The goal of the backup is to produce a stack of one or more disks that contain exactly the same files as a hard disk partition, and to be able to update the backup stack at any time.
The Active Drive is the disk partition or drive letter that will be saved. This is represented by the drive letter of the partition. This is any drive partition where you store data or programs.
The Backup Drive is the disk partition or drive letter that the backup will be written to, or restored from. This is usually a floppy disk drive, or may be a removable cartridge drive, or may be a hard disk partition that is set aside specifically as a backup.
The Backup Saveset is the set of disks that contain an exact copy of the files on the active disk, and the data file that the GOOD Backup Utility uses to keep track of the files stored on the backup saveset data disks. Note that you should not directly modify or delete any files in the backup saveset.
The Backup Saveset Data Disks are the disks that contain copies of the files on the active disk.
The Backup Saveset Data File is a data file used by the GOOD Backup Utility to record the name, location in the saveset, length, checksum, and creation date of each file in the backup saveset. The backup data file is usually stored on a separate disk that is set aside for this purpose. You may put the data files for each of your hard disk partitions on a single disk that is designated for keeping the backup saveset data files.
A Shadow Partition is a special case of a backup saveset, where a single partition is large enough to hold all of the files on the active disk. If you are keeping a shadow partition, it is permissible to keep the saveset data file on the same partition, so long as there is enough free space. A shadow partition does not have to be on removable media.
The initial backup of a typical 10MB disk partition onto double sided floppy disks will take about 45 minutes, more or less, depending on how fast your hard disk is, the average size of the files, and whether or not GOOD needs to format the floppy disks. You don't have to do this all at once. You can pause in the middle and finish at a later time.
Before starting your first backup, take note of the number of bytes used on the active drive, and make sure that you have enough backup disks. With standard formatting, a double sided floppy stores 726,016 bytes. The GOOD Backup Utility usually leaves between 1024 and 3072 bytes free on each disk. If your active partition has 6,000,000 bytes in use, you will need nine empty floppy disks, plus one more to contain the saveset data file.
If you are using floppy disk drive A: or B: as the backup drive, the GOOD Backup Utility can format single or double sided floppy disks as they are needed. The GOOD Backup Utility can put standard formatting on single or double sided floppies on drives A: or B:, but cannot format other kinds of removable media. If you choose to use a non-standard floppy disk formatting, in order to get more onto each disk, or if you are using any other drive letter as the backup drive, you must have your disks formatted before you start the backup.
Do not worry that you might unexpectedly be caught short, and need more backup disks than you have prepared, because you can always stop the backup at that time, and continue it later when you have prepared the needed media.
The initial GOOD Backup Utility form contains the following questions:
Active Drive: C:
Select the drive partition that you wish to back up. For most users, this is the only answer you would have to change from the default.
Backup drive: A:
Select the drive or partition that you will use for the saveset disks. The drive you select for the backup drive must either be a removable media drive, such as a floppy disk or cartridge disk, or if not removable, must have at least as much capacity as the active drive.
Saveset identifier: C1
This is the name of the saveset. You can use any 5-letter name you want, but the default is to use the active drive letter followed by a number. You should use a different name for each of your savesets. The saveset identifier is written in the boot sector of each disk of the backup saveset, along with the disk number, and is used to identify the disk. The GOOD Backup Utility checks the saveset name and number of each disk, in order to be sure you provide the disk that it has requested.
Saveset filename: A:\C1.SET
This is the name of the file that contains the GOOD backup saveset data. You can use any filename you want, but the default is to use the backup drive letter, with the saveset identifier as the filename, and with type .SET appended to it. When this file is on the same drive as the backup data, GOOD will ask for the saveset data disk explicitly, otherwise it will just access this file directly without asking.
If the saveset data file does not exist, the GOOD Backup Utility will assume that you are starting a new saveset, and create the saveset data file at the end of the run.
If you choose to use something other than the default values for the saveset identifier or the saveset filename, be sure to change them in order, drive letters first, then saveset identifier, then saveset filename. Changing the fields in the wrong order will cause the latter fields to automatically assume new default values.
Derive saveset data from data disks: NO
If you lose or damage the disk that contains the saveset data file, change this selection to YES. If this option is selected, The GOOD Backup Utility will construct the saveset data file by scanning each of the backup disks you have, and then proceed with the backup as usual.
If you are already using another backup program that generates ordinary TOS formatted disks, you can convert your current backup saveset to a GOOD backup saveset by using this option.
If you terminate a backup early without writing out new backup data, or anything else happens that makes you question the correctness of the data file, use this option to re-create an accurate data file.
Note that your exclusion list and cache parameters are also stored in the backup data file, but are not recovered by this procedure. If you have exclusion data, you should also select the Load or examine exclusion data option when deriving the data file, so that you can re-enter the exclusion list before the actual backup begins.
Disk number(s) of lost disks:
If you lose or damage one or more saveset data disks, list the disk numbers of the missing disks here, separated by comma or space. After reading the backup saveset data file, the GOOD Backup Utility will note that all files that were stored on the missing disks are now gone, and must be copied again.
Note that if you lose both the saveset data file, and some number of saveset disks, you should format an equivalent number of empty disks, and use these in lieu of the missing saveset disks when the GOOD Backup Utility is deriving the saveset data. In this case, do not bother to list the disks as missing. By the nature of these disks being empty, the GOOD Backup Utility will figure this out for itself as it derives the data file.
Load or examine exclusion data: NO
If this option is selected, you will be presented with a form for modifying the saveset exclusion data. Using the exclusion data form, you can specify up to 16 wildcard file specifications that will match files that will be excluded from the saveset.
Alternatively, you can specify that the only files that will be included in the backup saveset are those that match one of the 16 listed wildcard specifications. For details on this option, see the section entitled Editing the Exclusion List.
Set write back cache parameters: NO
If this option is selected, you will be presented with a form to examine or change the write-back cache parameters. For details on this option, see the section entitled Write back disk cache parameters.
Both the exclusion list and the write-back cache parameters are saved in the GOOD backup saveset data file, and re-used with each backup update.
Backup a partition: YES
If this option is selected, GOOD will present a file processing options form with all the default answers set for a run in BACKUP mode. This will create or update the backup saveset disks to contain the same files as the active drive.
Restore entire partition: NO
If this option is selected, GOOD will present a file processing options form with all the default answers set for a run in RESTORE mode. This will copy from the backup saveset any files that are different from those already on the active drive. This is usually used to recover an entire disk partition. Because it only copies the files that are different, you do not have to do the restore in a single sitting. You can stop any time, and automatically pick up later wherever you left off.
Perform selective restore: NO
If this option is selected, you will be presented with a form that will allow you to specify up to 16 wildcard specifications of files you wish copied from the backup saveset disks to the active drive. For more information about this form, see the section entitled Restoring Individual Files.
The actions of Backup a partition, Restore entire partition, and Perform selective restore are mutually exclusive. No more than one of them may be selected at a time. When one is selected as YES, the others will automatically change to NO. You may, however, select all of them as NO.
List saveset contents: NO
If this option is selected, you will be presented with a form that will allow you to specify up to 12 wildcard specifications. The files in the saveset whose names match any of the 12 selections will be listed in a directory listing. The directory listing is made after all other requested backup operations are performed, and can be output to a file, the printer port, the serial port, or the screen. For details of this option see the section entitled Listing the Saveset Contents.
After selecting answers for all the fields on the title page, press the UNDO key and the GOOD Backup Utility will read (or derive) the saveset data file. Unless you selected the derive saveset data option, this should only take a few moments. Various status messages will be printed along the way. After reviewing the status messages, you proceed by pressing RETURN or UNDO.
If you choose to proceed, you will be presented with the exclusion data form, if requested, and following that, the write-back cache parameters form, if requested.
If you have selected either Backup a partition or Restore entire partition, you will next be presented with the file processing form. If you selected Perform Selective Restore, you will be presented with the selective restore form. If you didn't select any file processing options, but did select List saveset contents, you will go directly to the saveset list form.
The File Processing Options form will appear when either Backup a partition or Restore entire partition is selected on the initial form.
This form allows you to select options for performing checksum validation on either the active drive or the backup saveset disks, and also allows you to select the specific disposition of files that are deleted, modified, or new since the previous backup update.
The only difference between the Backup a partition mode, and the Restore entire partition mode is the default values of the options in this form.
The files listed in the backup saveset data file are compared against the files found on the active drive, and each file is placed in one of four categories:
Category 1: Files that are up-to-date, having an identical creation date and length on both the active drive and in the backup saveset.
Category 2: Files that are in the backup saveset, but somewhere along the way these files have been deleted, and are no longer present on the active drive.
Category 3: Files that are on the active drive, but are not in the backup saveset. These files are new files.
Category 4: Files that are on both the active drive and the backup saveset, but that differ in creation date or length. These files are considered modified files.
The file processing form allows you to determine what will happen to the files in each of these categories.
Verify files on active drive: YES (backup) NO (restore) Action to take on errors: QUERY
If this option is selected, the GOOD Backup Utility will read from the active drive the entire contents of each category 1 file, those that are already up-to-date in the backup, and make sure that the file checksum still matches the checksum value recorded in the backup saveset data file. If the checksum matches, the data on the active drive is still readable and correct.
If there is a mismatch between the stored checksum and the computed checksum, you have the opportunity to either backup the file, or restore the file, or ignore the file. The default (Query) allows you to make this decision individually for each file in error. When an error is encountered, the usual action would be to restore the file from the backup saveset. The exception to this is when an error is discovered after deriving the saveset data from the saveset disks. In this case, the checksum value was computed by performing a checksum on the backup copy of the file, rather than the original. In this case, you should IGNORE the error, and carefully check to see which of the two files, the backup copy or the active copy, is the correct one. Copy the correct one to the active drive, and reset the creation date so that it will be copied on the next backup update.
Verify files in backup saveset: NO Action to take on errors: QUERY
If this option is selected, the GOOD Backup Utility will read the entire contents of every file stored in the backup saveset, and make sure that the computed file checksum still matches the checksum value recorded in the backup saveset data file. The verification is performed on each disk after all the copy and delete operations, so the result of the current backup update is verified.
If there is a mismatch, the problem is treated similarly to that of an error on the active drive. Note, however, that RESTORE is not an option in this case.
Because it reads every file on every backup disk, this option can take considerable time, but it is suggested that you periodically verify your backup saveset in order to ensure that you could restore the files if you need to. Floppy disks are not the most reliable data storage medium in the world. It is strongly recommended that you verify your backup savesets and correct any problems before intentionally destroying the data on your hard disk partitions, such as when renewing your low-level formatting or moving to new disk drive hardware.
Files deleted from active: DELETE (backup) RESTORE (restore)
These are category 2 files, those that are in the backup saveset, but are no longer on the active partition. The possible disposition of these files is one of Query, Ignore, Delete, or Restore.
When updating a backup saveset, these are deleted from the backup saveset, so that the backup saveset will contain copies of exactly the same files as are on the active drive.
When doing a restore, these are the missing files that are restored from the backup saveset.
The IGNORE option will leave these files in the backup saveset, which will defer deleting them until your next backup update.
As usual, the QUERY option will allow you to choose how to dispatch each file individually.
New files, not in saveset: BACKUP (backup) IGNORE (restore)
These are category 3 files, those files that are on the active drive, but not in the backup saveset. The possible disposition of these files is Query, Ignore, or Backup.
When updating a backup saveset, these are copied from the active drive to the saveset. When doing a restore, these are usually ignored. Modified files: BACKUP (backup) RESTORE (restore)
These are category 4 files where either the creation date of the backup copy is not the same as the file on active drive, or the length of the backup copy is not the same as the file on the active device. Note that even if you do not set your system clock every time you use your computer, it is highly unlikely that a modified file will have the same timestamp as an earlier copy.
When doing a backup, these files will be copied from the active partition to the backup saveset.
When doing a restore, these files will be restored from the backup saveset, replacing the potentially newer files that are already on the disk partition. If you do a restore to a disk partition that already has files on it, be sure that this is what you really want to do!
You can also select query mode, or ignore these files.
The archive bits, a backup related feature in the disk structure, are not used anywhere in the backup process. Because the archive bits are stored with the active file, rather than with the backup saveset, they do not allow you to maintain more than one saveset. The GOOD Backup Utility supports an arbitrary number of parallel savesets of the same disk partition.
The GOOD Backup Utility is careful to always delete old files from the saveset before it copies over a new version of a file to the backup saveset. This serves two purposes:
- Free as much space on a disk as possible before copying files to it.
- To allow you to interrupt the backup at any time, without having multiple copies of any one file on the backup saveset.
Hitting any key on the keyboard during the backup will elicit a query as to whether or not you wish to continue or stop where you are. This will come as soon as the current file copy or checksum completes. In some cases, such as when comparing checksum value, stopping will simply take you to the next step. In other cases, it will take you to the end of the backup, and write out an up-to-date backup saveset data file that reflects the current state of the backup. Using the information in the backup saveset data file, any incomplete backup or restore operations will be discovered and performed the next time you run the program.
Be sure that you do NOT cancel out of writing the backup saveset data file. If for any reason you cancel out of writing the data file, you will need to perform the derive saveset data from data disks option, in order to be sure that the saveset data file accurately reflects the contents of the saveset disks.
Special Concerns for Large Files
Large files, those larger than a single saveset disk, must be deleted from each of the saveset disks that it occupies before the program can start to copy the new version. In this case, the GOOD Backup Utility will, after deleting that last segment of the file, send you back to the first disk that the file occupied, in order to re-use that space.
If you have large files in your backup saveset, watch carefully the disk numbers and be sure to insert the correct one. If you insert the wrong one, the GOOD Backup Utility will notice and allow you to insert the correct disk.
The largest files are copied first, in order of size, so that files larger than the backup media are always given the first opportunity to use an empty disk. Files below 50,000 bytes are copied alphabetically, rather than by size, in order to prevent the last disk from being overrun by tiny files. Files that are smaller than the backup media are never split across more than one disk.
One side effect of deleting files before copying new versions is that files tend to migrate toward the latter disks in the saveset, and never migrate back to a lower numbered disk. Ordinarily this is not a problem, as the earlier disks are filled with new files that you create, but if, over time, your usage pattern is causing the lower numbered disks to have too much free space, then simply intentionally lose the last disk or two of the saveset. Losing the last disk will cause the GOOD Backup Utility to save the lost files into the first available free space, which will be on the lower numbered disks. Be sure to erase the disks that you lose this way, so that they don't get mixed up with the actual saveset data.
A checksum is a simple scheme for determining if two files are likely to be the same. The general idea is to use the data in the file to compute a unique number. If two files generate different numbers, you can be sure that the files are different. If two files generate the same number, there is a good probability that the files are the same.
Because the checksum is a single number, it is easy to store this number in the backup saveset data file. You can then go back and recompute the checksum at a later time, and if the number changes, you are sure that the data in the file has changed.
The checksum is computed as follows. Every file, every program, and every document on your disk can be interpreted as just a sequence of numbers, each between 0 and 255. The checksum of a file is simply the sum of all of these numbers. By computing this sum at the time the backup is performed, the GOOD Backup Utility can go back to the file at a later time, and re-compute the checksum to be sure that the sum hasn't changed. The GOOD Backup Utility can be used to verify the checksum values of the files in either the active drive, or the backup saveset.
A matched checksum does not guarantee that the file is not corrupted, it's just a high probability indication that it is okay. There is always some chance that a block of junk will, by coincidence, have the same sum. For example, if you took the sequence of numbers 5, 1, 12, 3, 5, 7, 19, which sum to 52, and scramble the order so that it comes out 19, 5, 12, 1, 3, 5, 7, the sum is still 52.
Restoring Files to a Different Partition
When restoring to a different partition than the original, you should edit the saveset identifier to match the original saveset identifier. The default value will have the drive letter of the new partition, and it should be changed to that of the old partition.
If you fail to do this, the GOOD Backup Utility will complain that each disk you insert is from the wrong saveset. You can override this, and if you do, GOOD will re-label each disk with the new saveset name. Changing the saveset name recorded on the backup disks may be desirable if the new disk partition is the new permanent home of these files.
Specifying Wildcard File Names
Wildard file names can be used to select more than one file with a single name. In GOOD, wildcard file names are used for the exclusion list, the selective restore, and for selecting files to include in the savest listing.
A wildcard file name expands into the list of all files that match the wildcard pattern. Most characters must match exactly, but the wildcard character * can match any sequence of zero or more characters, and % can match any single character.
For example, the name ABC*DEF will match ABCXYZDEF, ABC2DEF and ABCDEF. It will NOT match DEFABC.
The name ABC%DEF will match ABCQDEF or ABC1DEF, but will not match ABCDEF or ABC75DEF.
The wildcard filenames in the GOOD Backup Utility are matched slightly differently than is usual for the Atari ST. The comparison is performed on the entire filename, including the path or folder name, without giving special treatment to the special characters . or \. The GEM file selector, and other Atari ST programs that accept wildcards, will not allow * to include the folder delimiter \, or the file type delimiter .. Thefore, in the GOOD Backup Utility:
The name FOO* will match FOO., FOO\FILE.EXT, and also FOO\WORK\FOO.PRG.
Similarly, *.TMP will match all of T.TMP, AUTO\INIT.TMP, and also LIB\STUFF\FILE.TMP.
This generality is very powerful, in that you can easily specify wildcard sequences that will match entire directory trees, or files of certain types over the entire disk partition. A bare * will always match every file on the partition.
Because the GOOD Backup Utility operates on one disk partition at a time, the drive letter is not included as part of the filename when performing wildcard compares. The wildcard specification begins comparing with the character after the first \ in the filename. If you want to exactly match C:\AUTO\START.PRG, you say AUTO\START.PRG. The C:\ part is assumed to be the current active or backup drive letter, and is not considered when testing for a wildcard match.
This is important: the drive letter and : must not be included when specific a wildcard filename to GOOD. If you include them, the result will never match any files. The first \ is optional. The wildcard names WORK\* and \WORK\* are equivalent.
The exclusion list form contains 16 wildcard entries, and an option to exclude all listed files or include only listed files. The default is to exclude all listed files.
Note: If you change the exclusion list after the initial backup, files that were once included, and are now excluded, will be deleted from the backup saveset.
Use caution when excluding files with wildcards, so that you do not inadvertantly exclude files that should be included.
The selective restore form contains 16 wildcard entries. Each file in the backup saveset that matches one of the wildcard specifications will be copied from the backup saveset to the active drive.
If a file is larger than what can be stored on a single backup disk, you must restore it with the GOOD Backup Utility. If you prefer, smaller files may be restored by simply copying them from the appropriate backup saveset disk. Refer to the backup saveset listing to determine if more than one disk is used. If only one disk number is listed, you can safely copy the file directly from the indicated disk.
The saveset listing form allows you to choose a destination for the listing file, and up to 12 wildcard filenames that select the files you wish to list.
List to: PARALLEL Filename: C:\C1.LST
The GOOD Backup Utility can list the saveset contents to the serial or parallel printer, screen, or disk file. The default is to use the parallel printer. If a disk file is selected, the listing is directed to the selected file.
Up to 12 wildcard file specifications can be selected. The first entry defaults to *, which will list all files.
Use the List Saveset Contents form to locate files in the backup saveset floppies, or to check their length, checksum or last edit date.
You can also use the listing if you are unsure about the effect of your choice of wildcards on the selective restore form or the exclustion form.
Each file in the saveset uses two lines in the following form:
C:\USRBIN\PROG.TOS Disk 2 Length 453 Checksum 3188 Date Sun Jul 25 08:09:44 1989
The first line contains the filename, and the disk numbers that this file occupies. The second line contains the length, checksum, and file creation date.
The GOOD Backup Utility is a very flexible program - so flexible that it will not prevent you from doing disastrous things to your data if you ask it to. Be careful when changing your answers from the defaults, and be sure that you understand what have selected. Some specific examples where the wrong answer can cause problems:
- You rarely need to override the checks on proper disk insertions. To do so could be a disaster that leaves your saveset useless. You should only need to do this when converting the backup saveset of another backup program to the GOOD Backup Utility, when changing the saveset name of a saveset, or when writing the backup saveset data file to a shadow partition.
- An exception to the above is that if you use a bootable disk in the backup drive, you must acknowlege with ACCEPT instead of with READY. This will prevent modifying the boot block of the disk. GOOD writes it's disk labels in the application specific section of the boot block, and modifies the boot block checksum, which will render the disk unbootable. The ACCEPT option is will prevent any modifications to the boot block.
- When correcting a checksum error, be sure you know which file is the correct one, the one on the hard disk, or the one in the saveset data. If the checksum was computed from the saveset data, such as when Derive saveset data from data disks is selected, it is very possible that the file that FAILS the checksum is actually the correct file. Often, you are best advised to take note of the filename, select the IGNORE option, and check both copies after the backup is complete, to be sure you keep the correct one.
- Be sure that you do not QUIT when asked for the backup saveset data disk. In order for the GOOD Backup Utility to operate properly, it must always have an up to date copy of the saveset data. If for any reason you fail to write a proper backup saveset data, or if you accidentally run the program on a stale copy of the saveset data, you should perform the derive saveset data from from data disks operation, in order to be sure that this file is correct.
- Be sure that you do not remove a disk while the program is in operation, particularly with the write-back disk cache enabled, unless you are explicitly asked to replace the disk in the backup drive. Removing a disk before the write-back cache is allowed to complete it's final write operation will, in all likelihood, render the disk useless until it is reformatted.
- The disk cache used by the GOOD Backup Utility can may be incompatible with other disk cache utilities that are available. It is recommended that GOOD be run without the use of other disk caches. GOOD attempts to check for incompatiblity, and will disable it's own disk cache if it discovers an incompatible cache is present.
There are limits to the normal operation of this program. Beyond these limits, the program will fail.
- The GOOD Backup Utility will use memory in proportion to the number of files on the target drive, about 64 bytes per file. If you run out of memory, GOOD will print a message and exit immediately. When this happens, you will have to reboot. Use the Derive saveset data disks option to bring the data file up to date. If a crash happens while a saveset disk is in the disk drive, you should indicate that disk as lost and reformat it, because important disk cache data may not have been written back to the disk. If memory size becomes a problem, use should use smaller disk cache sizes, remove unneeded RAM disks or desk accessories, and/or divide your hard disk into more partitions. Note that using the exclusion data does not reduce the memory requirements.
- No backup may exceed 255 saveset disks. If you are using single sided floppy disks for the saveset, this limits the size of a hard disk partition to about 80 megabytes. With double-sided floppy disks, 160 megabytes.
Write-back disk cache parameters
A disk cache is an in memory buffer where recently accessed disk data is kept, and in the event the data is needed again, it can be obtained immediately without having to actually access the disk.
The GOOD Backup Utility includes a write back disk cache. Whenever the Atari's GEMDOS operating system requests a disk sector, the disk cache will read a larger block of disk sectors into memory. So long as this block of sectors is in memory, all disk I/O to this group of sectors can be performed without any further disk accesses. Each of these memory buffers is called a Cache Segment. If all of the cache segments are occupied, the disk cache will write the least recently accessed cache segment back to the disk, and re-use the memory for the next segment. This delayed write makes this a write back cache. Note that, of course, a segment is written back to the disk only if the data in the segment has been modified. The nature of the backup program is that it does a lot of I/O to consecutive disk blocks. A cache of this variety can substantially speed up file I/O by eliminating much of the need to seek back to directory blocks and FAT blocks.
The default settings for the write-back disk cache should be adequate for most users. There are some cases, however, where you may wish to adjust the cache parameter numbers. For example, if you have two megabytes or more of main memory, you could enlarge the floppy disk cache to contain an entire disk. This would eliminate much of the need to stop and start the disk drive while the backup is in operation. If you are using another disk cache product that you are happy with, or if you have very fast disk drives, you may not need any disk cache at all. If you are short on memory, you may have to lower the segment count or the segment size to get the cache to operate. If the disk cache cannot get enough memory, it will not be activated.
The write-back cache form allows you to specify three parameters for each of two caches. One cache is dedicated to the selected active drive, and the other is dedicated to the selected backup drive. These parameters work as follows:
Enable write back cache: YES
If you select NO, the cache is disabled, and does not get involved in optimizing disk I/O. You might want to try this once, just so that you can see how much faster the backup runs with the caches enabled.
Number of cache segments: 4 (active) 8 (backup)
The cache operates on some number of segments of contiguous sectors. This is the number of segments that it keeps. If you have extra memory to devote to the disk cache, it is usually better to increase this number, rather than to make the segment size larger.
Size of each segment in sectors: 50 (active) 20 (backup)
This is the number of sectors in each cache segment. This is the number of sectors that will be read at once. For best performance, this should be a small multiple of the track size of the media. It doesn't take much longer to read an entire track than it does to read one specific sector from a track.
Whenever a read operation is performed on the disk, a check is performed to see if the data is already resident in memory in a disk cache segment. If so, the operation completes without any disk access at all. If not, the entire segment is read from the disk, replacing the least recently accessed segment in memory. If the replaced segment has been modified, it is written back to the disk.
Whenever a write operation is performed on the disk, a check is made to see if the data is already resident in memory. If not, the least recently used segment is replaced with the new segment. Data is not read from the disk unless needed to fill gaps in a segment that are not written by the program. Whenever a segment that has been written to is bumped out of the cache, it is first written back to the disk.
Before asking you to remove a disk, all remaining modified segments are written back to the disk.
GOOD Backup Utility data file format
The GOOD Backup Utility data file contains infomation about each file in the backup saveset, and additional information about the saveset disks and user preferences. This file format information is provided for those that might want to write programs to interpret this data, and for the curious.
The file is a text file, consisting of lines of hexadecimal coded data separated by a single linefeed. Each line has the following form:
sddddddddccccccccllllllllnndd...filename
Where: s is a status code or record type. dddddddd is the 32-bit GEMDOS date code for this file. cccccccc is the 32-bit checksum for this file. llllllll is the 32-bit length of this file in bytes nn is the number of backup disks this file occupies, minus 1. dd is repeated nn times, and is the disk number of each backup disk this file occupies. filename is the full pathname of the file, with the device letter replaced by an underscore character.
The status codes are as follows: F - Disk data record. In these records, the date field is actually a flag indicating if the disk is known to be empty, the checksum field is the number of free clusters on the disk, and the length field is the cluster size used on the disk. There is always 1 disk (nn field is 00), and the disk number is the disk these values apply to. The filename field is empty.
< - Exclustion data record. In these records, the checksum field contains a 0 if exclude listed files is selected, and a 1 if include only listed files is selected. The filename field contains the exclustion wildcard filespec. There may be up to 16 of these entries.
Note that all of the checksum field values for all exclustion data records must be the same.
$ - Cache parameters record. In these records, the date field contains the active drive sectors per segment, the checksum field contains the backup drive sectors per segment, the first disk number is the number of segments in the active drive cache, the second disk number is the number of segments in the backup drive cache, the low order word of the length field is 1 if the active drive cache is enabled, and the high order word is 1 if the backup drive cache is enabled. The filename is empty.
O - Ordinary file record. These files are up to date in the backup. In a backup that is terminated early, files can also have status codes of M, D, U, A, and various other letters, which are indicate the internal state of the file when the backup was terminated. Except for the special codes F, <, $, and *, the value of this status code is ignored by the GOOD Backup Utility.
* - End of file record.
If you have any problems or comments about this program, please write to the address given on the inside of the front cover. All letters will be answered promptly. Please be sure to include your return address.
When writing to Tidbit Software about a problem with one of our programs, please include the serial number of your copy, the name of the program, and the program creation date that is given on the title screen.
Also, please return your registration card. Registered users will be notified when any substantial upgrades to the program are made availble.
If for some reason the floppy disk containing this program is unreadable, you may return it to Tidbit Software for replacement, free of charge.
At this time, Tidbit software is a part time endeavor, and therefore we cannot offer telephone support.
Included as an extra bonus with the GOOD Backup Utility is the program CHECKSUM.TOS. This program will repeatedly accept a list of wildcard filenames separated by spaces, and will display the checksum value for each of the files listed. To exit, enter an empty line.
Note that unlike the GOOD Backup Utility, the CHECKSUM utility interperets wildcard filename in the standard TOS fashion, where . and \ are barriers to expanding *.
The CHECKSUM program can be used to check individual files against the file list that is generated by GOOD.TOS, and can be used as a quick check to see if files of the same name and length are actually identical.
If you have a command shell, the CHECKSUM program will accept the filenames directly from the shell command line.