Xref: utzoo comp.unix.questions:18632 comp.unix.ultrix:2406 comp.sys.dec:2362
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv
From: emv@math.lsa.umich.edu (Edward Vielmetti)
Newsgroups: comp.unix.questions,comp.unix.ultrix,comp.sys.dec
Subject: Re: multiple dumps on one (exabyte) tape for Dec 3100
Message-ID: <EMV.89Dec28011625@urania.math.lsa.umich.edu>
Date: 28 Dec 89 06:16:25 GMT
References: <EMV.89Dec20183133@urania.math.lsa.umich.edu>
Sender: news@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor MI.
Lines: 47
In-reply-to: emv@math.lsa.umich.edu's message of 20 Dec 89 23:31:33 GMT


Thanks to everyone who sent me mail with information and shell scripts
about how to dump multiple filesystems to one Exabyte tape overnight.
I have in my hand a tape which contains the whole local network, about
a 4.5 hour job, neatly done while I was out.

In regards to the questions I posed, here are the reasonable
answers that came about.

- dumping live filesystems.  If your dump has been trained not
  to dump files that have changed between passes, you're OK;
  this is one of the fixes that Purdue did.  Rich Kulawiec
  <rsk@boulder.colorado.edu>, a partial author of some of the
  Purdue changes, says the supplied Ultrix dump works OK.

- sequencing the dumps in order.  The obvious solution, one
  script running from the dump host and generating commands
  like 'rsh foo -n rdump 0ouf dumphost:/dev/tape /filesystem'
  is what I have now.  I don't like keeping a huge /.rhosts
  file on the tape host, but a script sent in suggested 
  copying in a jumbo /.rhosts file just for the duration of
  the dumps and then moving the real one back.

- convincing dump to put more than one dump on a tape.
  Duh to me on this one: use the non-rewinding entry to
  the device, e.g. /dev/nrmt1h instead of /dev/rmt1h.
  The dumps go one after the other on the tape just
  as you expect.  At least on Ultrix, there's an 's'
  parameter to restore which lets you decide which of
  the files on the tape to restore from (I see it in
  SunOS 4.x too), so that should be no problem to 
  restore from.

Thanks to all who sent mail.  I have a solution which worked at least
once, and it wasn't as hard or necessarily as complicated as I thought
it might be.   As one person said "it is not terrible hard".  In
among the stuff that I haven't tried were the 'rrdump' thing that
I mentioned which removes some of the overhead of 'rsh', and a
nice perl script which parses a 'backup.conf' file and acts
accordingly.

Thanks again,

--Ed