From: Steinar.Haug@delab.sintef.no (Steinar Haug)
Subject: Using BSD 4.3 dump/restore for better speed & security
Organization: SINTEF DELAB, Trondheim, Norway.
Date: 12 Nov 92 15:45:39

As some of you may be aware of, I have repeatedly argued that dump/restore
is (in many cases) a better alternative than fbackup or cpio for full and
incremental backups.

HP supplies dump and restore as a standard part of 8.0, but unfortunately
it's a rather old version. A newer version of BSD 4.3 dump/restore, with
various patches from the net, is available from hpserv0.cs.uit.no, directory
pub/util, as 4.3rdump_for_hpux.tar.Z. Note that this version has been ported
to HP-UX by HP Labs, but HP has never made it officially available. This
version, unfortunately, does not compile 'out of the box' on 400 and 700
systems running 8.0.

Since we have been using dump/restore here at DELAB for several years now,
with great success, I thought I would help others wanting to use it also. So
I have taken the 4.3 BSD port mentioned above, made small fixes to enable
compilation under 8.0, and added one new feature: Remote backup can be done
to 'user@host:tapedev' instead of just 'host:tapedev'. This is a modification
which has been available 'on the net', and which has been incorporated into
for instance the SunOS dump/restore.  This gives increased security, since
you no longer need to have all remote hosts in the .rhosts file for root on
the tape host.

The advantages of using this version, compared to HP's official versions,
are:
	- Speed. This version runs at about double the speed, because it
	uses several slave processes to read the disk, and also sets larger
	send/receive buffers for the TCP connection.

	- Being able to specify the remote backup as 'user@host:tapedev', as
	mentioned above.

The advantages of using dump/restore in general, compared to other tools, are:

	- Works below the file system level, therefore does not modify *any*
	of the atime, ctime, mtime field of each inode.

	- Generally faster than other tools - because it reads the raw disk.

	- Can be used in a heterogeneous environment - which is *extremely*
	important to us! We use dump/restore for Suns, HPs and also one MAC
	running A/UX.

Some disadvantages:

	- Not the tool that HP recommends.

	- Will not handle ACLs (but will handle CDFs just fine).

Since I haven't used other tools much, I cannot really quantify the speed
advantages. Suffice to say that a 700 series system, dumping to a remote
Exabyte-8200 connected to a Sun, will dump around 10 to 12 MBytes/minute on
a level 0 dump. The 400 series generally get around 8 MBytes/minute.

If you are interested in getting this software, here are the details:

- Original port (made by HP Labs), available with anonymous FTP from
hpserv0.cs.uit.no (129.242.16.105), file

	pub/util/4.3rdump_for_hpux.tar.Z.

- Original port and my modifications, available with anonymous FTP from
ugle.unit.no (129.241.1.97), files

	pub/unix/hp-ux/4.3rdump_for_hpux.tar.Z
	pub/unix/hp-ux/4.3rdump_for_hpux.diffs.tar.Z

To generate: Unpack the original, remove old executables (these are for 300
series running 7.0 or earlier), unpack diffs, apply diffs with patch program,
then 'make rdump' in the rdump directory, and 'make rrestore' in the rrestore
directory.

They have been tested on 400 and 700 series systems, running HP-UX 8.0 and 8.07
respectively. Not tested for 300 or 800, but I think they should work. Also
note that CDFs are handled just fine.

Enjoy!

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: Steinar.Haug@delab.sintef.no, 
	sthaug@idt.unit.no, steinar@tosca.er.sintef.no

PS:

HP's official version of dump will tell you when dumping if you have any files
with ACLs. These are *not* dumped to tape, but at least you get to know about
them. "My" version does not do this. If anybody would like to contribute the
necessary code to check if any files have ACLs, I would be happy to integrate
this into the version I have made available.
Newsgroups: comp.sys.hp