shoshana@pdi.UUCP (Shoshana Abrass) (06/04/91)
Once or month or so, we do an 'archive' backup to cartridge tapes (as opposed to exabyte). The backup takes about 5 cartridges. If one of the cartridges has a bad spot, it does what I think is the wrong thing. For example, tape 1 and 2 have been successfully written. Files are being written to tape 3. Suddenly the driver encounters a write error and asks for a new tape. If I put in a new tape, it starts writing files where it left off from tape 3. What I want it to do is rewrite all of tape 3 on the new tape. I have no interest in having a tape with bad media in one of my archive sets, plus it screws up offsite storage if I can't predict how many tapes my backup will end up being. Does this bother anyone besides me? or maybe I'm not doing the right things with bru? I use the -s size option, which doesn't seem to help. Using dump is not a possibility. Our tapes are data quality tapes from inmac. -shoshana shoshana@pdi.com --
arritt@kuhub.cc.ukans.edu (06/04/91)
In article <9106032216.AA22384@koko.pdi.com>, shoshana@pdi.UUCP (Shoshana Abrass) writes: > > If one of the cartridges has a bad spot, it does what I think is > the wrong thing. For example, tape 1 and 2 have been successfully > written. Files are being written to tape 3. Suddenly the driver > encounters a write error and asks for a new tape.... I have found that this is almost always a symptom of a dirty tape drive. The QIC drive apparently is very sensitive in this regard. I'm willing to bet that if you clean the drive this problem will go away. Also I've found the QIC drive to be somewhat sensitive to the brand of tape used. In my experience 3M cartridges are quite good, Verbatim is ok. One time our vendor switched brands on us and sent us some called "Data Mag" which were utterly atrocious. Since the difference in price is only a dollar or two it pays to specify a reliable brand. Also explicitly state to your vendor that you are specifying a brand -- often they reserve the right to substitute "equivalent" products. ________________________________________________________________________ Raymond W. Arritt | Assistant Professor | Dept. of Physics and Astronomy | "People never travel to look University of Kansas | at flat landscapes." Lawrence, KS 66045 | - from _Stop Making Sense_ , arritt@kuhub.cc.ukans.edu | by the Talking Heads arritt@walrus.phsx.ukans.edu | arritt@ukanvax.bitnet |
olson@anchor.esd.sgi.com (Dave Olson) (06/05/91)
In <9106032216.AA22384@koko.pdi.com> shoshana@pdi.UUCP (Shoshana Abrass) writes: | Once or month or so, we do an 'archive' backup to cartridge tapes | (as opposed to exabyte). The backup takes about 5 cartridges. | If one of the cartridges has a bad spot, it does what I think is | the wrong thing. For example, tape 1 and 2 have been successfully | written. Files are being written to tape 3. Suddenly the driver | encounters a write error and asks for a new tape. If I put in a new | tape, it starts writing files where it left off from tape 3. What I | want it to do is rewrite all of tape 3 on the new tape. I have no | interest in having a tape with bad media in one of my archive sets, | plus it screws up offsite storage if I can't predict how many tapes | my backup will end up being. | | Does this bother anyone besides me? or maybe I'm not doing the right | things with bru? I use the -s size option, which doesn't seem to | help. Using dump is not a possibility. Our tapes are data quality | tapes from inmac. Well, presumably if the media was good up to that point, then it is still good. The backup (and restore!) should work correctly. If you don't like this behavior, about all you can do is pretest your media, or abort the backup and restart. 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. Think of the problems of keeping all the state around about where in the tree (and potentially in a file) you were at the start of the volume. Since most of the backup programs use the stack to keep track of where they are in the tree (in order to deal with symlinks) this isn't a trivial project, although certainly not impossible. -- Dave Olson Life would be so much easier if we could just look at the source code.