Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: uaisun4!mrl@uunet.uu.net (Mark R. Ludwig)
Newsgroups: comp.sys.sun
Subject: Re: Incremental Backups
Keywords: Miscellaneous
Message-ID: <2673@brchh104.bnr.ca>
Date: 28 Apr 91 19:20:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 42
Approved: Sun-Spots@rice.edu
X-Original-Date: Fri, 26 Apr 91 09:45:57 PDT
X-Refs:  Original: v10n84
X-Sun-Spots-Digest: Volume 10, Issue 91, message 13
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <2573@brchh104.bnr.ca>, frazier@cs (Greg Frazier) writes:
>At UCLA we are currently using a progrm called "backup" to do incremental
>backups to a hard disk.  Unfortunately, the from and to disks have to both
>be on the same machine.  Does anybody have an incremental backup program
>that will work across NFS-mounted disks?  Yes, I am aware that one can
>hack up a script using rdump and rrestore, which is what I will do if I
>cannot find a good program.

We have no budget to buy *any* software, so I have had to build my own
wheel.  We have a multi-vendor network and all the nodes are backed up to
an 8mm drive on a Sun-4.  While we do only full backups (instead of
incremental), I believe my experiences are relevant enough to recommend
you do *not* try to do backup across NFS.  There are several reasons, but
the most important are that the file protections across NFS do not
guarantee that you can access all files as "root" on a client node (yes, I
know, *some* implementations of NFS allow this, and *many* do not), the
network traffic to access a full file partition via NFS is tremendous, and
rdump/rrestore have a horribly inefficient ACK/NACK tape manipulation
protocol which the use to the tape drive.

Instead, I suggest you run your favorite backup program on the NFS server,
send the output to stdout, and pipe the result into a remote shell on the
node with the tape drive, using ``dd'' to appropriately block the output
to the tape drive for both efficient space utilization and good tape
streaming performance.  (My experience with the 8mm drive using a block
size of 100b (51200 bytes) suggests that the ``dd'' writing to the tape
drive will consume a fair amount of CPU to do its bidding.)  This approach
results in less network traffic and better throughput for the backup
operation, because the ``rsh'' is basically uni-directional compared with
all the back-and-forth packets required for the equivalent NFS access to
the filesystem.

For those experts reading: Yes, I have the scripts Do the Right Thing by
unmounting all the filesystems, pruning them (with ``fsck''), and only
dumping them if the pruner is happy; no, I don't do ``root'' or ``usr''
this way, because, to the best of my knowledge, it is impossible to
automate hands-off backup for those.

INET: mrl@uai.com       UUCP: uunet!uaisun4!mrl       PSTN: +1 213 822 4422
USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA  90293
WANT: Succinct, insightful statement to occupy this space.  Inquire within.