Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!uunet!mitel!sce!cognos!dgbt!phil From: phil@dgbt.uucp (Phil Blanchfield DGBT/DIP) Newsgroups: comp.unix.ultrix Subject: Re: Problems with exabyte Keywords: dump restore backup exabyte 8mm Message-ID: <1289@dgbt.uucp> Date: 24 Nov 89 17:40:19 GMT References: <1553@bnlux0.bnl.gov> <9337@batcomputer.tn.cornell.edu> Reply-To: phil@dgbt.crc.dnd.ca (Phil Blanchfield DGBT/DIP) Organization: The Communications Research Centre, Ottawa, CANADA Lines: 53 In article <9337@batcomputer.tn.cornell.edu> hurf@tcgould.tn.cornell.edu (Hurf Sheldon) writes: > >/etc/dump "$LEVEL"usdf 4800 6666 /dev/nrmt1h /usr/users > > the '4800' is big enough for us to get the /usr/users partition in - at > 6666 the dump program figures about 75mb per 1200ft so you can calculate > accordingly (that it does this is new with 3.0 and designed to avoid > the tk-50 having a file spread over a tape boundary because it > can't restore one that is) I suppose you could use -d 10000 (the tk-70) > but most exabyte implementations mimic a tk50. I am not sure but > I believe the density might be moot as it doesn't seem to make > a difference in speed or tape length. - Just used to calculate when > to call for a new tape. Does anyone know why the TK50 can't restore a file which is spread across two tapes? Has this been fixed in V3.1 or is this a hardware problem? We have an Exabyte here connected to a TD Systems UDT controller and I just tell dump that there is 30000 feet of tape with the "s" (size) option. Dump assumes that my density is 6670 bpi and that the drive is a TU81, therefore since you can get 140Megs onto a 2400ft reel and 2Gigs onto a 8mm I used (2000/140 * 2400) for the ball park figure of 30000. I back up 2 RA81's and an RA82 (6 partitions) all onto the same tape by using the "non rewinding" special files for all but the last dump. The drives are 75-80% full and the entire backup takes 2.5 hours. Soon we will be getting another RA82 and then I will have to use more than one tape. I also back up a SUN onto the same drive using rdump. Rdump on the SUN assumes a 1600 BPI tape so I use 120000 for the size. As I understand it the "real" density is controlled by the special device that you use. /dev/rmt0h = HIGH (6250) /dev/rmt0m = MEDIUM (if your tape has medium) /dev/rmt0l = LOW (1600) More on this in mtio(4). A suggestion: My backup script creates a "date file" on the root partition prior to dumping it using: DATE_FILE=`date +%d-%h-%y` cat $DATE_FILE >/