NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/hp/14786

Text File | 1993-01-12 | 5.9 KB | 138 lines

Newsgroups: comp.sys.hp
Path: sparky!uunet!mcsun!sunic!aun.uninett.no!Steinar.Haug
From: [e-mail] (Steinar Haug)
Subject: Re: Backing up several HP's & GNU Tar
In-Reply-To: [e-mail]'s message of Tue, 12 Jan 1993 15:28:06 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: tosca.er.sintef.no
Organization: SINTEF DELAB, Trondheim, Norway.
References: <[e-mail]>
Distribution: comp.sys.hp
Date: Tue, 12 Jan 1993 21:06:07 GMT
Lines: 123

[e-mail] (Heikki Karhunen) writes:
> Well, I tried some native UNIX tools (find, cpio, dd, remsh, add some
> piping and obfuscate) and managed to get a full backup from each and
> every disk in the system to one tape. The only problem with this was
> that it took some 12 hours to complete...
>
> At the moment I am trying out GNU Tar (version 1.11.11). The problem
> with *that* is its inability to understand HP's cdf-files (Context
> Dependent Files). I am trying to add support for cdfs to it, but so
> far I have met with some resistance (I can make it archive them silly
> buggers, but they won't come out!).
>
> I'd like to know if someone somewhere has met up with this kind of
> problems and solved them. I'd also appreciate it if someone has
> already taught GNU Tar to understand about cdfs and could give me some
> diffs.

Have you considered using dump/restore? Works great for us, and is especially
nice in a heterogeneous environment. Here is an article I posted here some
time ago about dump/restore.

Steinar Haug, system/networks administrator
SINTEF DELAB, University of Trondheim, NORWAY
Email: [e-mail],
    [e-mail], [e-mail]
----------------------------------------------------------------------
From: [e-mail] (Steinar Haug)
Subject: Using BSD 4.3 dump/restore for better speed & security
Message-ID: <[e-mail]>
Sender: [e-mail] (NetNews Administrator)
Organization: SINTEF DELAB, Trondheim, Norway.
Date: 12 Nov 92 15:45:39
Lines: 89

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: [e-mail],
    [e-mail], [e-mail]

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.