Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!decwrl!pyramid!pesnta!hplabs!ucbvax!info-vax
From: kaiser@FURILO.DEC (Pete Kaiser, 225-5441, HLO2-1/N10)
Newsgroups: mod.computers.vax
Subject: Re: Raxco, etc (really BACKUP)
Message-ID: <8601191839.AA21717@decwrl.DEC.COM>
Date: Sun, 19-Jan-86 13:40:15 EST
Article-I.D.: decwrl.8601191839.AA21717
Posted: Sun Jan 19 13:40:15 1986
Date-Received: Mon, 20-Jan-86 22:45:26 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 26
Approved: info-vax@sri-kl.arpa

One way to make backups run faster is simply to blast the source files onto the
target medium with lots of buffering and no error-checking.  This is true in
general, of course.  VMS BACKUP, using its default settings, calculates lots of
error-recovery, and does lots of error-checking; there's a story (apocryphal)
that BACKUP's ability to recover from errors was demonstrated by clipping a
2-inch section from the middle of a taped saveset, splicing the tape, then re-
storing the saveset.  BACKUP noted the anomaly and restored the saveset
properly.

I don't know how Raxco's product achieves its performance.  But I do know that
you can improve VMS BACKUP's timing by

	-- using lots of buffers (/BUFFER=5)
	-- using large physical blocksizes for taped savesets
	-- turning off error-recovery

If you do that last, as far as I can tell you're throwing away a major reason
for making backups at all.  That's up to you.  My point is that questions of
"performance" can sensibly be asked only in the context of other important
requirements of the application.

---Pete

Kaiser%BELKER.DEC@decwrl.arpa
{allegra|decvax|ihnp4|ucbvax}!decwrl!dec-rhea!dec-belker!kaiser
DEC, 77 Reed Road (HLO2-1/N10), Hudson MA 01749  617-568-5441