gus@frame.UUCP (Gus Fernandez) (07/30/89)
The Apple tape backup 40SC application supports two forms of backup - Volume (Image) backup and file-by-file backup. Each DC2000 tape cartridge holds about 38 megabytes of data. Image backup works by saving each block of the hard disk sequentially on tape exactly as it is written on disk. This is how the Mac can keep the tape running continuously as it is reading the disk. Normally this would mean that backing up a 40 meg disk would always take up two tapes, 38 meg for the first, and two meg for the second. The backup application makes an optimization, however. It looks for the last block which is allocated on the disk and only writes up to that point. That way, for example, if you initialize a disk and copy 20 megabytes of data, the backup will only write 20 meg and take up half as long. As a disk gets used, however, it gradually fills up. Even if you delete files so that you never top off the disk's capacity, the HFS file allocation algorithm will use the higher numbered blocks as it sees fit in order to cut down on disk fragmentation. The backup application backs up these "holes" as well as the real data. This is done so that programs such as the tape disk driver which comes with Tape Backup 40SC software version 2.0, which I wrote, can read and write the various blocks on the tape in random access mode. The best way to solve this problem is to copy all files to a second disk, initialize the original, and copy them back. Of course this assumes that you have that much free disk space somewhere else! The fact that many disks are 40 meg and 80 meg and tape cartridges are 38 meg each is unfortunate. One way to get around this problem is to partition the disk so that each partition takes up 38,000K or less. Even if that means that two meg is wasted, this is sometimes less agravating than using two tapes when one will almost do. Unfortunately, there is a bug in the Tape Backup 40SC application version 2.0.1 which can leave the last 5% of your disk un-backed up if you use a non-standard partition size. Apple has been informed of this problem. (Actually, it turns out that there is about a 50-50 chance that, given an arbitrary disk size, that this bug will show up. Fortunately, none of that Apple standard disk sizes are affected.) This is a dangerous problem, since you don't know that anything is wrong until you restore your files and find that a few are garbage. Fortunately, there is a simple patch for this bug which can readily be applied using ResEdit. At resource CODE 2, offset 726 find 74 00 34 28 00 2E E6 8A 24 42 52 8A 22 3C 00 00 and change to 36 68 00 38 96 E8 00 2A 60 24 52 8A 22 3C 00 00 I call this version 2.0.1p1, so please change resource DITL 25117 as appropriate. To clear up some missinformation on the net, All tape backup units that use the 'QIC 100' format such as Apple's store each 8K block of data as three 4K frames. The first two store the first and second halves of the block. The third stores the first frame XOR the second. This provides 50% redundancy. If any one of the three frames goes bad, you can recover the data from the other two. This improves reliability tremendously. When working on Tape Disk, I actually had a hard time generating certain types of errors. I had to resort to physically damaging test tapes much worse than could reasonably be expected in normal use. Gus Fernandez Disclaimer: I worked as a contractor for Apple in 1987 when I wrote Tape Disk. Tape Backup 2.0 shipped after I left and I only discovered the above mentioned bug well after the product had shipped. I informed Apple about the bug, including the patch, but have not received any information about update plans. This work does not reflect my present work or that of my current employer. I'm providing this information solely for the benefit of the people on the network.
cy@dbase.UUCP (Cy Shuster) (08/01/89)
Thanks for the patch, Gus! Does this also fix my problem where a volume backup can't be restored to any other volume save the original? --Cy--