Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!cbmvax!grr
From: grr@cbmvax.UUCP (George Robbins)
Newsgroups: comp.unix.ultrix
Subject: Re: dump on old 1.2 Ultrix...
Summary: actually lots on dump(1)/restore(1)
Message-ID: <7480@cbmvax.UUCP>
Date: 30 Jul 89 05:41:10 GMT
References: <412@wuee1.wustl.edu>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 80

In article <412@wuee1.wustl.edu> tjs@wuee1.wustl.edu.UUCP (tom sullivan) writes:
> we're still running old Ultrix 1.2 on our uVAX-II/GPX. the windowing
> system (X11/Decwindows) with 3.0 just messed us up more than anything
> else. my biggest complaint with 1.2 is the speed (or lack there of) of
> dumps. is there an optimal setting (density, lenght, blocking factor, etc.)
> to do dumps onto a TK50 drive. as it is, it takes over 6 hours to perform
> a level 0 dump of an 80 Meg partition.

Ultrix dump(1) supports an undocumented -b switch that lets you specify
the blocking factor for the dump.  Setting this so that it generates the
largest blocksize that the controller/drivers supports should minimize
wasted tape and time.  You need to verify *most* carefully that the
blocksize you use isn't too big and is silently generating bogus tapes!!!

There is a problem with this - the Ultrix restore(1) utility doesn't support
a corresponding -b option, so you need to use dd(1) to deblock the tape on
input, which *won't* work if it's a multi-volume dump!!!  The alternative
is to use the 4.3 BSD restore utility which supports the -b switch.

Another alternative, if you have access to a 4.3 system, is to snarf the
4.3 BSD dump/restore binaries and use them.  They work good, are somewhat
faster and -b is documented for both dump and restore.

If you have enough disk space, you might find it quicker to do the various
dumps to a temporary output file and dd the output file to the TK50.  Dump
and streaming tape drives are poorly matched, since dump may have to go
jerking all over the disk drive to collect a file, while the tape drive is
merrily spinning away or playing '1 step forward, 2 steps back'.  Doing the
dd from a sequential file to tape should be as close to optimum as you're
going to get.

A final note is to represent that you don't really have to do level 0
dumps very often at all, with the only real need being when the incremental
dumps start taking painfully long or won't fit on one reel/cartridge or
you muck with the filesystems.

The dump(1) documentation is baroque and confusing, but the bottom line is
that the simple mode is to do level 0 dumps occasionally and only one flavor
of level x incremental dumps daily.  Since each incremental represents all
the changes since the last level 0, there is no particular requirement to
keep all the incrementals back to the last level 0.  As insurance, you
should do (and keep) an incremental immediately before each level 0, so
that if the level 0 turns out to be defective, the previous level 0 and the
"extra" incremental give you the equivalent file state as a life-saver.

If your activity level is high enough to warrant intermediate level
incremental backup, the same concept of completing the set of "extra"
incrementals gives you the needed redundancy, though your life becomes
more complex.  Theoretically, in either case,  barring multiple bad tapes,
you can lose at most the changes from the prior incremental to the time
of the disaster, even it you get hit with one bad tape.

You *are* doing those dumps in single user mode and/or with the file
system dismounted aren't you?  If not, the "completeness" of the dump
becomes a statistical issues and there's a chance you'll have to do
massive fiddling if a (level 0 especially) dump is inconsistent due
to things changing while the dump is running.  I generally do the
level 0 dumps in single user mode or by dismounting filesystems when
I can and do the incrementals in multi-user mode.  This isn't "right",
but the risk seems acceptable in comparison to the pain of shutting
down every day.

BIG DISCLAIMER:

The above represents my understanding of the "way dump(1) really works" and
it is possible I am either (1) seriously confused or (2) f**ked in the head.
Consult you local man pages and gurus before implementing backup schemes 
different than the (hopefully) correct, but (perhaps) suboptimal scheme you
may  presently be using.  Questions and corrections appreciated.

PS:  Gnu-tar can also do incremental backups, and the tapes created from
     a gnu-tar dump of an active file system are inherently more restoreable
     than those from a dump(1) of an active file system.  This doesn't
     necessarily mean that they have better data integrity under this
     circumstance, just that the restore will be less prone to blow off.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)