Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!pdi.UUCP!shoshana
From: shoshana@pdi.UUCP (Shoshana Abrass)
Newsgroups: comp.sys.sgi
Subject: Re: Backups
Message-ID: <9106051806.AA26003@koko.pdi.com>
Date: 5 Jun 91 18:06:49 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The Internet
Lines: 36


  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

--