Summary of Exabyte and Dump (long)

From: Andy Dwelly (andy@eba)
Date: Thu Jan 23 1992 - 10:32:16 CST


Sorry for my tardiness with this summary, things have been real busy here
installing various new programs, not to mention the actual use of the machines.
Many thanks to all those of you who took the time to reply to my questions.

As you may recall I asked about the use of Sun's standard dump commands, and
the use of the exabyte tape drive :

>We recently bought our first Sun, and I am a novice system administrator
>(amongst other things). We also recently took delivery of a Dynatek HSB5000
>which is based on the Exabyte 850 tape drive capable of recoding 5Gb on those
>tiny 8mm data tapes. I'm trying to get a regular back up schedule started.
>
>Q1. Does anyone know what options I should be using with /usr/etc/dump to
> get the most data packed onto a tape. I'm thinking of the 'd' option
> which specifies the bpi in particular here. The default seems to store
> a mere 50Mb which is much less than the system should be capable of.
>
>Q2. We have only a small number of tapes at the moment (Sony 112Ms) because
> our local supplier is out of stock. Although our system is divided into
> several distinct file systems, it is actually only around 800Mb in total
> and so should fit onto a single tape.
>
> Is it possible to fit several distinct file systems onto one tape with
> dump ? it looks to me as if the tape is being rewound at the end of each
> distinct file system.

-----------------------------------------------------------------------------
>From alberta!physics.ubc.ca!unruh Fri Jan 3 14:51:49 1992

I use den=54000 sixe=6000 on my 8200 exabyte, but I do not know how
optimal those are.

use /dev/nrst ratehr than /dev/rst as the device (with the correct
number of the tape drive at the end of course) nrst does not rewind,
even though dump says it is rewinding. You can check by using mt -f
/dev/nrst0 fsf <number> and then restore -i.

From: baumann@proton.llumc.edu (Michael Baumann)

for our 8200 systems (2.3 gig on tape) you lie to dump, as the density
means nothing for an exebyte. we use a size/density of 6000 and 54000,
so for the 8500 (5 gig) try 12000 and 54000. These is for the MP120 tapes
Adjust accordingly.

It may (or may not :-) If you specify the non-rewind device, then each
dump will append, without rewinding. We dump 9 machines this way.
try /dev/nrst? as your dump device.
note that dump will tell you it is rewinding the tape, but it lies.

From: feit@ERA.COM (Mark Feit)

Sounds to me like dump thinks you're using QIC-24 cartridges. You
need to set the s and d options per the instructions in the dump(1)
manual page, otherwise dump will stop after what it thinks is the
appropriate length of tape and ask for a blank.

Conventional Sony 8mm videocassettes from K-Mart work just fine. Get
the 120s, though, because one of Sony's 90-minute models will gum up
your Exabyte, and I can't remember which one it is.

If you're not using the w option, dump should maintain whatever's
necessary in /etc/dumpdates so you don't have to do a full dump daily.
If you want to do level-zero dumps daily, you're going to have to say
so on the command line since level nine is the default. If you want
multiple volumes, write multiple files to the tape. A very skeletal
example:

        #!/bin/sh
        DEVICES=/dev/disk1a /dev/disk1b /dev/disk1c etc...
        TAPE=/dev/tape-device

        mt r # Rewind the tape
        for DEVICE in $DEVICES
        do
                dump {args} $DEVICE # Do the dump
                mt eof # Write a tapemark
        done
        mt eof # Two tapemarks in a row means EOT
        mt rewoffl # Rewind & spit it out

This dumps each of your file systems to the tape and writes a tapemark
between each so you can use ``mt fsf n'' to find the nth tapemark on a
tape before doing a restore.

If you're using the v option, dump will rewind the tape and verify the
dump, but it should leave the tape at the end of the dump when it's
finished.

From: <msc@air16.larc.nasa.gov>

Hi, I saw your posting to comp.sys.sun.admin (Jan 3). I have a C shell script
that we use to backup our suns. It takes the dump level as a parameter. It
looks in /etc/fstab to find out which partitions to dump.

The wierd thing about the Exabyte (the one that we have, anyway) is that you
have to tell the dump command that there are more feet of tape than are
actually in the cassette. This is because it does compress at the drive.

Here is the script. I hope that it helps. I was learning while I writing it
so I might have done some things the hard way.

#!/bin/csh

#-----------------------#
# dump script for SunOS #
# AIRLAB (LaRC) #
# Michael S. Cokus #
# 02/05/91 #
#-----------------------#

#---------------------------------------------------------------------------#
# LaRC - Cokus - 6/9/91 - now checks frequency field in fstab instead of #
# using ad hoc method to determine which partitions #
# to dump #
#---------------------------------------------------------------------------#

set path = (/bin /usr/bin /etc /usr/etc /usr/local/bin)

set DUMPHOST = "air16" # machine to recieve and store the dump
set DUMPDEV = "rst4" # device to use on the above machine
set TDEN = 72000 # tape density in bits per inch
set SIZE = 6000 # tape length in feet
set BLOC = 126 # block size in terms of 512 byte hunks

set LEVEL = $1
set HOST = `hostname`
set MESG1 = $HOST" now dumping /dev/r"
set MESG2 = " to "$DUMPHOST":/dev/n"$DUMPDEV" (level "$LEVEL")"

#---------------------------------------------------------------------------#
# dump all partitions in /etc/fstab that do not have a dump frequency entry #
# of "0" (zero) #
#---------------------------------------------------------------------------#

set PARTS = (`awk '$5 !~ /0/ {printf("%s ",substr($1,6,4))}' /etc/fstab`)

echo "** " $HOST "(level "$LEVEL") **"
echo " "
df
echo " "
mount -a

foreach PART ($PARTS)
        echo "*"
        echo $MESG1$PART$MESG2
        echo "*"
        echo dump ${LEVEL}ubsdf $BLOC $SIZE $TDEN ${DUMPHOST}:/dev/n$DUMPDEV /dev/r$PART
        dump ${LEVEL}ubsdf $BLOC $SIZE $TDEN ${DUMPHOST}:/dev/n$DUMPDEV /dev/r$PART
end

From: "Granville Boman Goza, IV" <gbg@SEI.CMU.EDU>

   If I remember correctly, that option for dump (along with the length of the
tape) does not actually do anything but help calculate how much will data will
fit on a tape. It does not actually put the data on the tape in a denser format.

   You can increase the amount of data you put on the tapes by (typically) 2
by using compress. (dump | compress | dd) Although this is a bit of a cpu
intensive, it can usually double the amount of data put on a tape.

   You can put several dumps of different partitions on the same tape. To do
this you will have to use the non-rewinding device name. ie. if the device
name is /dev/rst1 (rewinding device name) you should use /dev/nrst1 (notice
the n). To do restores you will have to position the tape at the correct
dump. To do this you will have to use the mt command (use man mt to get more
info), mt -f <non-rewinding device name> fsf #. #=number of dump files to
skip.

From: todd@wutc.wustl.edu (Todd M. Carrico)
dump 0cdsfu 54000 6000 ...

for three years now. This gives us as close to 2.1 Gig as
possible on our 8200. The big problem is that dump assumes
you are using a cartridge tape at X feet and Y density, and
assumes it cannot write beyond that - even if it has no control
over the physical device.

Todd Carrico
todd@wucs1.wustl.edu

p.s. - I am sure your know - but the above says to calculate
the amount of data possible for a 54000 ft tape at 6000 denisty

TOdd

From: Brain in Neutral <bin@primate.wisc.edu>

This is what I use for multiple file system dumps on our Exabyte.
I'm sure the length and density arguments are incorrect, because this
script was modified from one used on a QIC cartridge drive, but it still
works. You might want to hack that part. The important thing is to
use the non-rewinding device and rewind manually afterward.
Also hack your default list of file systems.

Yours,
Paul DuBois
dubois@primate.wisc.edu

#!/bin/csh

# dumpgroup - dump a group of file systems onto a single tape
# All file systems are dumped with same dump level.

# syntax: dumpgroup level filesys1 filesys2 ...
# if no file systems named, use default set,
# currently "/ /usr /home /var /usr1 /usr2"

# 22 May 87 Paul DuBois
# 23 Feb 91 Modified for saimiri using 8mm tape drive

# /dev/nrst0 is non-rewinding tape device
# density 54000 BPI, length is 6000 ft., use 95% (5700) to be safe

set TAPE = /dev/nrst0

if (${#argv} == 0) then
        echo "Usage: dumpgroup level [filesys] ..."
        exit (1)
endif
set dumplevel = $argv[1]; shift # get dump level
echo "Dump level is" $dumplevel
if (${#argv} == 0) then # use defaults
        set argv = ( / /usr /home /var /usr1 /usr2 )
endif
foreach a ($*)
        echo Dumping $a
        dump ${dumplevel}dsfu 54000 5700 ${TAPE} $a
end
echo "Rewind tape"
mt -f ${TAPE} rewind
echo "Eject tape"
mt -f ${TAPE} offline

From: Gordon Atwood <gordon@cs.ualberta.ca>

  On a two-hour tape (no I haven't got the length off-hand, sony p6-120mp)
we use a bds setting of 24 516000 4394 which yields roughly 2Gb storage which
is what we expect. We also use variable block size, not fixed.

As for the rewinding, the sun dump rewinds each time and as far as I know
there's now way to turn it off, although maybe they've updated it a bit.
Unless you can fix that you'll just have to fsf. It is also (or was) slow and
has a protocol which badly needs to be subverted.

Our version of dump has quite a few enhancements; perhaps Lynn will let me sell
them to you :-)

G.H.A.

From: chess@vitsemi.com (Rob Eccles)

Andy:

Yes, and the way to do it is simple: You need to use the no-rewind option
in the device name, in other words, instead of dumping to /dev/rst0
(tape drive) you dump to /dev/nrst0.
                              ^

The DUMP output will still SAY that the tape is being rewound after each
dump; do not worry, it is not really happening if you used an "n" .

You DO want the tape to rewind after the last dump. You can either
omit the "n" from the last dump command (i.e. /dev/rst0 ) or you can issue
this command right after the last dump:

        mt -f /dev/rst0 offline

which will rewind the tape and eject it from the tape drive. The latter
is my preference because it prevents someone else from accidently overwriting
the tape before I retrieve it from the drive and put it away.

Anyway, you end up with a tape containing multiple, consecutive dumps.
At some point you may wish to restore something from it. You need to
read about the "s" option of RESTORE.

Happy New Year!

From: sob@tmc.edu (Stan Barber)

Here is what we use. Enjoy.

#!/bin/sh
#
# Generic 8mm Backup for SUN System
# $Revision: 1.2 $ $Date: 90/03/06 21:56:46 $
# ****************************************************************************
# This work in its current form is Copyright 1989 Stan Barber & Baylor College
# of Medicine.This software may be distributed freely as long as no profit is
# made from such distribution and this notice is reproducted in whole.
# ****************************************************************************
# This software is provided on an "as is" basis with no guarantee of
# usefulness or correctness of operation for any purpose, intended or
# otherwise. The author is in no way liable for this software's performance
# or any damage it may cause to any data of any kind anywhere.
#*****************************************************************************
# CONFIGURATION STARTS HERE
# name of the host on which the 8mm lives
tapehost=tapehost
remote=truman
# name of the 8mm device (regular device, not the no-rewind device)
drive=/dev/rst1

# debuging flag
DEBUG=
# CONFIGURATION STOPS HERE
#
export HOME PATH
# NOTE: 360' 8mm videotape holds 2,000 Mb
# calculating at 6250BPI implies that a 360' tape == 32,000 feet tape!
# we use 28,000 to make sure we don't reach EOT
# takes about 2.5 minutes to rewind
# takes about 2.5 hours to erase (mt -f $drive erase)
dens=6250
tpl=28000
blk=32
ndrive=/dev/n`echo $drive | sed "s%\/dev\/%%"`
# Always a level 0 dump
LEV=0
LABEL=`hostname`
tape_server=$remote:$ndrive
echo ""
echo "8mm File System Backup Procedure starts on $LABEL"
echo ""
#
#
if [ "$LABEL" = "$remote" ]
   then
     tape_server=$ndrive
$DEBUG mt -f $drive rewind
   else
     tape_server=$tapehost@$tape_server
$DEBUG rsh -l $tapehost $remote mt -f $drive rewind
fi
#
#
# get all the 4.2 filesystems
grep 4.2 /etc/fstab > /tmp/flist$$
# get the ones we'll backup (no /tmp, no /export/swap)
exec < /tmp/flist$$
while read i
do
set $i
if [ "$2" = "/tmp" -o "$2" = "/export/swap" ]
then continue
fi
echo Begining level $LEV dump of $2 to 8mm tape
echo `date`
cd $2
$DEBUG /usr/bin/touch $2/`/bin/date +%m-%d-%y`
$DEBUG /etc/dump "$LEV"ubsdf $blk $tpl $dens $tape_server $1
$DEBUG /bin/rm $2/`/bin/date +%m-%d-%y`
echo Done with level $LEV dump of $2
echo `date`
echo ""
done
exec < /dev/tty
rm /tmp/flist$$
if [ "$LABEL" = "$remote" ]
   then
     tape_server=$drive
$DEBUG mt -f $drive offline
   else
$DEBUG rsh -l $tapehost $remote mt -f $drive offline
fi
echo ""
echo "8mm File System Backup Procedure is completed on $LABEL"
echo ""
echo "Please label the tape as follows:"
echo ""
echo "$LABEL"
echo "level $LEV dump"
/bin/date +%m-%d-%y
echo ""
echo -n "Press any key when done"
read JUNK
exit 0

-- 
From: cchtor!larry (Larry Chin)

hi,

I believe the dump parameters that you require are:

blocking factor ( b parameter ) 126 density ( d factor ) 108000 size ( s factor ) 6000

a dump line then would be: dump < dump level > fubcsd < tape device > 126 108000 6000 < file system>

As for dumping multiple file systems to a single tape simply specify the no rewind device for all but the last file system. This is done by appending an "n" to the tape device. The following is the dump script for one of our machines. Notice all but the last file system specify /dev/nrst1, a no rewind tape device. ^

echo "/usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /" /usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 / echo "/usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /usr" /usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /usr echo "/usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /morespace" /usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /morespace echo "/usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /usr3" /usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /usr3 echo "/usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /news/cnews" /usr/etc/dump $1fubcsd /dev/nrst1 126 108000 6000 /news/cnews echo "/usr/etc/dump $1fubcsd /dev/rst1 126 108000 6000 /usr4" /usr/etc/dump $1fubcsd /dev/rst1 126 108000 6000 /usr4

You might want to read the man page for dump and mt.

Hope this helps.

Larry Chin {larry@cch.com} CCH Canadian Ltd. System Administrator 6 Garamond Court Research and Development Don Mills, Ontario. (416) 441-4001 ext. 349 M3C 1Z5

These are my opinions, MINE YOU HEAR, MINE !!!

From: doi@myrias.ab.ca (Derek Iverson)

Hey man, we have some nifty scripts that Stephen Farkas wrote that handle dumps. There is a plethora of scripts that should probably be condensed into a couple perl scripts, but this is left as an exercise to the reader :-) .

You know who to call.... Your friendly neighborhood ex-tech support guy.

From: orchard@eceserv0.ece.wisc.edu (Bruce Orchard)

The man page for dump suggests using 6000 feet and 54000 bpi for dumping to 2.3 GB 8mm tape. I think that all dump uses these numbers for is anticipating the end of the tape so that it can switch volumes at a convenient point. I think it assumes it is starting from the beginning of the volume. If you put several file systems on one tape, these calculations become meaningless. Therefore, I would just make the numbers large enough so that dump does not try to change volumes.

Bruce Orchard (orchard@engr.wisc.edu)

-------------------------------------------------------------------------------

So there you have it. Thanks once again to all those of you who replied.

-- Andrew Dwelly, EBA Engineering Consulants Ltd. Edmonton, Alberta, Canada. andy%eba@cs.ualberta.ca Tel: 403-451-2121



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:34 CDT