como@max.bnl.gov (Andrew T. Como) (11/18/89)
I am having problems trying to get /etc/dump to work on an 8mm. The problem I am facing is getting the right combination of blocking size and density to work correctly in order to restore what I have dumped. I am using the tmscp drivers on "/dev/rmt1h". Can anyone lend a hand and get me off the ground. If I use the default values it writes the exabyte as a 6250 tape and I loose the purpose of the 8mm. On our Sun4.os I can use the following but doesn't seems to work on Ultrix 3.1 dump 0ubsdf 50 6000 54000 /dev/rst1 / Thanks again como@bnl.gov BITNET: como@bnl.BITNET UUCP: ....philabs!sbcs!bnl!como
hurf@batcomputer.tn.cornell.edu (Hurf Sheldon) (11/22/89)
/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.
hurf
--
Hurf Sheldon Network: hurf@ionvax.tn.cornell.edu
Lab of Plasma Studies Bitnet: hurf@CRNLION
369 Upson Hall, Cornell University, Ithaca, N.Y. 14853 ph:607 255 7267
"And the walls came tumbling down"phil@dgbt.uucp (Phil Blanchfield DGBT/DIP) (11/25/89)
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 >/ </dev/null This file is removed at the end of the "full" backup. The root partition is always the first to be dumped to the tape. This way you can verify the date of a backup by loading the first tape in the set and typing "restore -i" followed by "ls". Any suggestions? Critique? -- Phil Blanchfield phil@dgbt.crc.dnd.ca | The Communications Research Centre UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!phil | 3701 Carling Avenue, Ottawa CANADA
chris@wugate.wustl.edu (Chris Myers) (11/27/89)
In article <1289@dgbt.uucp> phil@dgbt.crc.dnd.ca (Phil Blanchfield DGBT/DIP) writes: >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. From the manual I got with my Exabyte: dump ${level}usdf 6000 54000 /dev/nrmt0h /partition I have used these parameters to dump 560MB partitions to my Exabyte. The density and tape length parameters aren't used by dump for anything other than calculating the amount of data that can be written to a single tape, so all you have to do is pick numbers that won't cause a numeric overflow (which can happen in older 'dump's). >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? There is a bug in the Ultrix 3.x TAR program that prevents a multi-volume tar file from being restored from a SCSI drive. Call your DEC Serviceperson and ask for a copy of the Ultrix 3.1 patch tape -- it has a fixed copy of tar. -- Chris Myers Internet: chris@wugate.wustl.edu Software Engineer UUCP: ...!uunet!wugate!chris Office of the Network Coordinator BITNET: chris@wunet.bitnet Washington University in Saint Louis Phone: +1 314 362 6186