Problems with exabyte

Phil Blanchfield DGBT/DIP phil at dgbt.uucp
Sat Nov 25 04:40:19 AEST 1989


In article <9337 at batcomputer.tn.cornell.edu> hurf at 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 at dgbt.crc.dnd.ca  | The Communications Research Centre
UUCP: ...utzoo!bnr-vpa!bnr-rsc!dgbt!phil  | 3701 Carling Avenue, Ottawa CANADA



More information about the Comp.unix.ultrix mailing list