madd@adt.UUCP (jim frost) (04/13/89)
> One of my personal favorites to >save tape and speed the backup is to compress the data [...] >Compression is slow, but Exabyte tape drives are slower, so there you are ... The biggest problem with this technique is the bad spot on the tape. You loose everything if the tape is at all bad, or if the tape degrades. This is also why I don't like tar et al as backup utilities; they provide little or no redundancy. jim frost madd@bu-it.bu.edu
shoshana@pdi.UUCP (Shoshana Abrass) (06/06/91)
In <1991Jun4.201502.28249@odin.corp.sgi.com>, Dave Olson writes: > If you don't like this behavior, about all you can do is pretest > your media, or abort the backup and restart. Well, maybe I'm just paranoid, but it seems that a tape with one bad block is likely to develop more later, and I definitely do not want to the person saying "Gee I *thought* that was backed up" when a file is needed. Pre-testing the media is a tedious, though workable, idea. As for restarting: a 5-cartridge-tape backup, done across the network, takes most of the day and must be 'attended'. If I have to restart it I either stay at work till the wee hours changing tapes, or do the backup a day late which, IMHO, is bad policy. That's what really makes this issue into a problem - the behavior of bru has a material impact on my ability to do the backup in a reasonable way, > None of the shipped backup programs at SGI keep track of where > the volume started (except on the first i/o), so there is > no way to restart the volume. There may be commercial packages > that do what you want, but I don't know of any. It's been a long time since I've used Sun's dump program, but I know it used to do this - at least on 9-track tapes, which is what I used back then. It seems like a useful ability for any multi-volume backup program. Unfortunately, though I know dump has been ported to the SGI, it's not an option for us right now. -shoshana shoshana@pdi.com --