---------------------------------------------------------------------------- ****************************** Legal Stuff ***************** Aug. 18, 1992 * ---------------------------------------------------------------------------- BackUP V3.5 © Felix R. Jeske BackUP is a shareware, freely distributable hard drive backup program for the Amiga under Workbench 2.0. If you like BackUP and regularly use it, I would appreciate being sent a $15 contribution to the following address: Felix R. Jeske 3746 North Oleander Avenue Chicago, IL 60634-3210 USA Contributors will receive the latest version of BackUP (I am already adding context sensitive help and a few other goodies) plus a few other programs I've written but not published. Contributors of $25 or more will receive the complete copyrighted source. Suggestions, comments and criticisms (ouch) are also welcome at the above address. I am quite proud of BackUP and will gladly support it. DISCLAIMER FELIX R. JESKE MAKES NO WARRANTIES EITHER EXPRESSED OR IMPLIED, WITH RESPECT TO THIS SOFTWARE, ITS QUALITY, PERFORMANCE OR FITNESS FOR ANY PARTICULAR PURPOSE. THIS SOFTWARE IS PROVIDED "AS IS." THE ENTIRE RISK AS TO QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH THE USER. IN NO EVENT WILL FELIX R. JESKE BE LIABLE FOR DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM ANY DEFECT IN THE SOFTWARE. ---------------------------------------------------------------------------- ********************************* Credits ********************************** ---------------------------------------------------------------------------- Many thanks go to the developers of ARP who have created an extremely useful collection of routines in one library and have made it easy to program as well. Also, thanks go to Holger P. Krekel and Olaf Barthel for use of their lh.library. This is an excellent version of the LZH compression algorithm that, again, is very easy to program. ---------------------------------------------------------------------------- *************************** System Requirements **************************** ---------------------------------------------------------------------------- BackUP requires Workbench 2.0, 1MB of RAM, a hard drive (obviously) and as many floppy drives as you can afford. BackUP also requires arp.library V39 (available on FF123, not distributed with BackUP) and lh.library V1 (available on FF436, distributed with BackUP) ---------------------------------------------------------------------------- ***************************** Historical Info ****************************** ---------------------------------------------------------------------------- BackUP was initially developed on a A500 under Aztec C 3.6a. Workbench 2.0 additions were made on a A3000 under Aztec C 5.2a. V3.5 - First public release V3.4 - Added compression using lh.library V3.0 - Discontinued use of req.library and added custom gadgetry V2.0 - Added gadgets using req.library V1.0 - Added primitive interface using autorequestors and the console V0.9 - Initial development of the backup and restore engines I started developing BackUP after my purchase of a $700 (groan) 30MB Supra hard drive. Not wanting to spend any more money than I had to, I started on BackUP after reading about programming the trackdisk.device in an issue of Transactor for the Amiga by Bob Rakosky (August '89: Vol. 2, Issue 5). After figuring out how to do raw reads and writes to the floppy drive, I learned about parsing a partitions directory structure. I heard about ARP in another issue of Transactor and finally got my hands on it. I incorporated req.library after buying CygnusEd which uses it quite heavily. The current version of the code is almost identical to that under req.library except for cosmetics. I borrowed the current gadgetry style from AVS (Application Visualization System), a scientific visualization package I program and use at work on UNIX workstations. Finally, I found lh.library on Fred Fish Disk #436 and included compression as an option. ---------------------------------------------------------------------------- ******************************** Benchmarks ******************************** ---------------------------------------------------------------------------- The target machine for BackUP is any Amiga with at least two (2) floppy drives. Being restricted to one floppy drive eliminates the continuous write feature. BackUP does not support tape drives since I don't have one. Compression is only recommended for fast machines or if you really want to save disks (55% compression is typical) as the on-the-fly compression does slow down the backup. Compression actually speeds up the restore since the speed bottleneck is the floppy read/write time. The decompression process is so fast that reading in less data, decompressing it in memory and writing it out to the hard drive is faster than reading and writing out the original uncompressed data which took longer to load from the floppy. My only real comparison of the capabilities of BackUP to other hard drive backup programs is my experience with HDBackup (shipped with my A3000) and other PD backup programs I've uploaded. Since most of the PD backup programs I've obtained are CLI based, I only compare BackUP and HDBackup since the CLI is not well suited to perform such an operation. Therefore, the following is a comparison of BackUP and HDBackup working on 294 files comprising about 1.1MB of data with compression and verify on. It shows the following: BackUP HDBackup ------ -------- Executable Size 30K 81K Memory Usage 430K 475K While Backing Time to Backup 2:56 4:03 Number of Disks 1 3 I could not figure out why HDBackup needed three (3) disks to backup 1.1MB of data, especially when full compression was enabled. In uncompressed form, it should have only occupied two disks. ---------------------------------------------------------------------------- ******************************* User Docs ********************************** ---------------------------------------------------------------------------- BACKUP The backup procedure consists of selecting the partition to backup, the specific directories and files to backup within the partition, selecting which floppy drives to use during the backup and finally the swapping of disks in and out of the floppy drives. When BackUP boots up, it polls the machine for all hard drive partitions and all floppy drives. A gadget for each is created on the main screen. The user need only press on one of the labeled partition buttons to start reading the complete directory contents into memory. When done, a standard file requestor displays the entire directory structure. A few methods are available to the user as to how files are selected to be included in the backup. The order of the methods chosen is important. For example, selecting a particular file in a directory and then deselecting the entire directory will deselect that file. The following lists the order in which the selection process should proceed. 1) The Incremental/Full button changes whether files with their archived bits set are included in the selected file list. 2) The Include and Exclude wildcard patterns are convenient ways to include/exclude large groups of files. A file is selected for backup if it matches the Include pattern and does NOT match the Exclude pattern. The ARP pattern matching system is used and therefore asterisks (*) can be used in place of Commodore's global wildcard (#?). Also patterns can be ORed together via the pipe (|) operator to form more complex pattern such as: *.(c|h)|a* which would match all files ending with either a .c or .h extension or files beginning with a. 3) Whole directories can be manually included or excluded by single clicking on them in the file requestor. Double clicking on a directory name changes to that directory. All non-empty directories have a much-greater-than sign (») appended to their name denoting that they may be entered. 4) Finally, individual files can be selected (unselected) by single clicking on them in the file requestor. After choosing the files to be backed up, the user can press the buttons for each of the floppy drives BackUP will use during the procedure. It is recommended that as many drives be used as available. BackUP automatically formats disks as it writes and also switches between drives without any user intervention (continuous write). This speeds the process up by constantly writing to one drive while the user is changing the disk in another. Finally, two options may be set in the menu bar: compression and verify. BackUP performs on-the-fly compression by reading in small (11K) blocks of files, compressing them and asynchronously writing them to disk. The asynchronous part allows BackUP to read from the hard drive and write to the floppy drive simultaneously. Compression can reduce the number of disks used by a factor of two (I have seen 2MB written to 1 disk). Compression can, however, slow down the backup since the compression process takes time and degenerates the backup to a synchronous process (read, compress, write). The verify option specifies whether a read pass of the tracks written to the floppy is made after the format/write pass. The backup process is sped up considerably with verify off, however, it is not recommended since the integrity of the data is unknown. All of the options (include/exclude wildcards, compression state, verify state, backup type and floppy drives used) can be saved as the defaults by choosing the "Save Configuration" option in the menu. Upon subsequent boot ups, BackUP will load the configuration file and automatically set the previously saved defaults. After all this is completed, the user need only press the "Start Backup" button and begin swapping disks. During the backup, a fuel gauge bar fills representing the completion of the backup. Also, the current file being backed-up as well the current disk being written to and the total number of files and bytes backed-up is constantly updated. The disks should be labeled by date and disk number since BackUP will request numbered disks during the restore procedure. The user may halt the process at any time by pressing the "STOP" button. Note that the process will not actually stop until the current file is completely written. After the files are copied to floppy, BackUP writes out the directory structure. Only the directories that contain backed-up files are written in order to save space. This means that, on full backups, empty directories will not be saved, and, therefore, cannot be restored. ---------------------------------------------------------------------------- RESTORE The restore procedure is very similar to the backup procedure with the exception that the list of files is read from the floppy set instead of the hard drive. When BackUP boots up, the user need only press the "Start Restore" button to have BackUP read a partition's directory structure off floppy. BackUP will request that the last disk of a backup set be inserted into the first available drive to start this process. BackUP may ask that the previous disk be inserted depending if the directory structure write overlapped multiple disks. When finished, the user can select and deselect files just as in the backup procedure with the exception that the Incremental/Full button is not available. After choosing which files to restore the user should press the "Start Restore" button again. The same window with fuel gauge bar will appear and BackUP will request particular numbered disks to be inserted in the available drives. Files are restored to their previous location with date stamp, file note and protection bits restored as well. Directories will be made if necessary. ---------------------------------------------------------------------------- ***************************** Known Problems ******************************* ---------------------------------------------------------------------------- There are two known problems with the program. The first is that although a "CANCEL" button is included on a number of popup requestors, it is not always implemented and therefore pressing it just brings up the same requestor. This is true only for requestors with red text (as opposed to white) that appear in the middle of screen that usually request that a disk be placed in a drive. The second problem is with BackUP's handling of bad disks. BackUP makes three (3) attempts at writing to a track. If all three fail, a requestor will come up asking if you wish to continue or abort. Aborting will blow the user out of the program (not graceful). Continuing will simply skip that track on proceed to the next one (recommended). However, if BackUP encounters a large number of tracks that are bad sequentially, it seems to get confused an cannot recover them (ouch). The moral, use known good disks. These problems are currently being looked into, and, when dealt with, an update to BackUP will be made. ---------------------------------------------------------------------------- **************************************************************************** ----------------------------------------------------------------------------