gord@spycal.UUCP (Gord Delaney) (11/12/87)
Hi I am looking for information on programs used to backup files from my hard disk to diskettes. I know this isn't the best solution, but I don't have a tape and I thought diskettes would be better than nothing. The program should use an 'archive' bit and be able to do incremental backups to a 'backup set'. Other options, like data compression, etc, would be of interest. Any information on either PD, Shareware, or commercial programs (or the PD programs themselves) will be appreciated. Thanks Gord
carlos@io.UUCP (Carlos Smith) (12/03/87)
I use bru, by Fred Fish to back up my hard disk. It is very fast because (for better or worse) it does not write the floppies in AmigaDos format. So you must use bru to extract files. On the other hand, I timed it at about two to three minutes a disk while backing up, so backups finish in about a half an hour. Since the Amy multitasks, I usually play a game or two of Shanghai while the backup runs, replacing the disk when I/O stops! Pretty painless really. I have found it to be reliable. It does NOT make use of the archive bit in the current version, but I find it useful by doing an incremental backup specifying all files since the date of the last full (or incremental as you prefer) backup. This works quite well, and incrementals go very quickly. Bru is available only as shareware from Fred Fish, for $30 (last I heard). His address is: Fred Fish 1346 W. 10th Place Tempe, Arizona 85281 -- Carlos Smith uucp:...!harvard!umb!ileaf!carlos Bix: carlosmith
fnf@mcdsun.UUCP (Fred Fish) (12/08/87)
In article <491@io.UUCP> carlos@zapp.UUCP (Carlos Smith) writes: >I use bru, by Fred Fish to back up my hard disk. It is very fast because (for >better or worse) it does not write the floppies in AmigaDos format. So you >must use bru to extract files. On the other hand, I timed it at about two >to three minutes a disk while backing up, so backups finish in about a half an >hour. Since the Amy multitasks, I usually play a game or two of Shanghai >while the backup runs, replacing the disk when I/O stops! Pretty painless >really. Here are some of the tradeoffs of private formats versus DOS formats (Mac/Amiga/Unix etc), as I see it: Private Format Advantages: -------------------------- 1) Can result in much faster I/O, all other things equal, since the format is stream oriented versus filesystem oriented. On the Amiga this is a win because of the relatively high filesystem overhead. 2) Because the format is stream oriented, recovery from corrupted or unreadable archive blocks is much easier. You can deliberately overwrite random parts of a bru archive and bru will still be able to read and recover all the rest of the data, with at most the loss of the file containing the overwritten data (if the file header block is clobbered). There is enough redundancy built into the format that with even more work (not currently implemented) the damage can be limited to no more than the actual data clobbered. 3) The format works just as well with archives written to normal filesystem files, streamer tapes, pipes, or even out a serial line. 4) Archives are machine independent. I can transfer archives back and forth between Amiga and Unix hosts with ease. 5) Large numbers of files and hierarchies can be restored automatically and easily, rather than manually figuring out the necessary native machine commands to restore files and directories from a backup that is readable directly by the host machine. 6) For archive media that requires formatting, the formatting can usually be done at the same time that the archive data is written, thus saving time and hassle (true of the Amiga version for floppies). 7) Files larger than what will fit on a single archive volume are split across multiple volumes automatically, and restoral is just as simple. Private Format Disadvantages: ----------------------------- 1) Requires that a copy of the backup program be available for dearchiving files. This is a hassle if you wish to send a large archive/backup to someone that does not have the necessary dearchiving program. 2) Requires somewhat more work to recover only a single file or small group of files that could be quickly recovered from a archive that was readable directly by the host machine. 3) If the format is unpublished, this can be a hassle for people that wish to do something special with an archive, or diddle with it directly for whatever reason. The bru format will be published in detail when I get the "internals documentation" finished. For those that are feeling perverse and would like to stress the error recovery in bru, here is a cookbook list of things you can do to an archive. To make this a fair test, you should really be using the latest beta 2 version of bru, rather than the freely redistributable alpha 1 version, and have properly installed the s:brutab file: 1) Take a scratch floppy that you don't mind destroying and write an archive on it. 2) Write a special purpose program that reads the floppy track by track and swaps all the bytes in the track. I.E. ABCDEFGH... becomes BADCFEHG... 3) Ditto for number (2) but now swap all the halfwords: I.E. BADCFEHG... becomes DCBAHGFE... (All this simulates typical byte/short endian ordering machine dependencies) 4) Overwrite several sections of the archive, with both large overwrites (>2K) and small overwrites (a few bytes). 5) Write a special purpose program that inserts or deletes several blocks of random data in multiples of 2K. I.E. if the original archive blocks, each 2K long, are numbered sequentially as 0 1 2 3 4 5 6 7 8 ... you end up with: 0 1 2 4 5 6 7 7 8 ... (This simulates buggy hardware, typically tape drives, that return either the same block twice or drop a block; yes, this has happened to me in the real world...) 6) Now, for good measure, take a magnet, strongly magnetize a screwdriver tip, and touch it to several places on the archive media at random. Alternately, if you are not worried about possibly damaging your drive heads, you can punch a few holes in your media or use a razor blade edge to shave off some of the magnetic coating. :-) :-) This simulates an accidentally damaged archive media. 7) Now try to read your archive. Data loss can be minimized by giving the smallest possible blocking factor (2K) and explicitly giving the media size with the -s option. You should get back all your data, except what you deliberately deleted or overwrote or scrambled magnetically. >I have found it to be reliable. It does NOT make use of the archive bit in the >current version, but I find it useful by doing an incremental backup >specifying all files since the date of the last full (or incremental as you >prefer) backup. This works quite well, and incrementals go very quickly. The Amiga specific enhancements, such as use of the archive bit, will be completed over the next month or so. This is being done as part of the work in integrating bru into a system that includes a filesystem manager and archive manager. >Bru is available only as shareware from Fred Fish, for $30 (last I heard). His >address is: Actually, the $30 is a registration fee to be a beta tester and is used to cover the costs of distributing up to 6 updates automatically. Any balance remaining at the end of the beta test period will be applied towards the cost of a commercial release or refunded. -Fred -- # Fred Fish hao!noao!mcdsun!fnf (602) 438-3614 # Motorola Computer Division, 2900 S. Diablo Way, Tempe, Az 85282 USA