Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!albanycs!crdgw1!uunet!mcvax!ukc!strath-cs!jim
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.sys.hp
Subject: Re: Backup over net (Was Re: NFS Super users?)
Message-ID: <249@baird.cs.strath.ac.uk>
Date: 25 Jul 89 15:57:11 GMT
References: <2924@helios.ee.lbl.gov> <240042@grlab.UUCP> <1649@zen.co.uk>
Sender: news@cs.strath.ac.uk
Reply-To: jim@cs.strath.ac.uk
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 32

In article <1649@zen.co.uk> vic@zen.co.uk (Victor Gavin) writes:
>Rdump -- and correct me if I'm wrong -- doesn't allow you to store file
>systems for different (remote) machines onto the same tape

You are correct. Rdump is meant to dump a local filesystem to a remote
backup device. This is the sensible way to do things. [In any case,
rdump/dump read the raw disk to backup files, so that's the *only* way
it *can* work.] Doing it the other way round (backing up remote files to
a local device) is silly - there's no way to read a raw filesystem when
it lives on another machine's disk. Using alternatives like tar or cpio
that read files in the usual manner via the block buffer cache cause other
problems, outlined below.

>If you have ``access'' to the remote files that you want to back up then you
>can use something like 
>
>  "find <nominiated file systems> -depth -print | cpio -oacxBC > /dev/rmt/0h"

This is not a clever idea. Recursive traverses of a remote file system
with something like find or ls -R will stress the fileserver to a high
degree. (Try it and watch the load average on the client and server go
through the roof while the perfomance of both gets so bad that they're
both unusable.)

It is much better to do this sort of thing on the machine where the
files physically live. This saves network bandwidth and servicing
gazillions of remote file system protocol requests and acknowledgements
that are typically done at interrupt time on both the client and server.

As for using cpio for backups, the less said the better...

		Jim