Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!gatech!purdue!haven.umd.edu!decuac!hussar.dco.dec.com!mjr
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Newsgroups: comp.unix.admin
Subject: Re: Backups
Message-ID: <1991Jun24.033641.15213@decuac.dec.com>
Date: 24 Jun 91 03:36:41 GMT
References: <JC.91Jun23223058@condor.bu.edu>
Distribution: comp
Organization: <dataholics anonymous>
Lines: 51

jc@raven.bu.edu (James Cameron) writes:

>My question is what would be automate the backups?  At this
>point, I am running shell scripts which dump until end of
>tape at which point I end up switching tapes [...]

	I have a system that I put together which does a couple of things
at once. A process (which talks the same protocol as rdump/rrestore) can
be started up by the inetd from a client (no need for root on the tapserver!)
and enforces permissions as to who can talk to it. If the client is valid,
it then reads the client's data and writes it to disk someplace (or to a
device, if you don't want to queue stuff). When the write is done, the
client's data is moved into a queue where anotther process deals with
writing it to tape, and prompting a tape change, etc, if needed. The
tape writer process keeps a bunch of logs about what came from where and
so forth. This is essentially a two-step process, but the advantage is
that multiple clients can all be "dumping" (they can use rdump) at
once if they like, even though there is only one real tape drive. The
system can easily support more than one real tape drives (several
queues) but has no support for switching queues. Since more than one
client can be writing arbitrarily large images to the queueing file
system, another process (optionally) can be configured that just keeps
an eye on the high-water for that filesystem, and tells the input
readers to pause, if the filesystem overflows past a certain point,
until the tape queuer catches up.

	I plan to put this code out on the net once it's a little
more hammered on and documented - right now the only documentation
is in the code comments. :) I also *plan* to write some trivial
client that will talk to the remote tape writer and give a gauge
of how full it is, etc. It's all fairly simple code, very configurable,
and a lot of the "site policy" (like how to notify that the tape drive
is full) is done by making callouts to shell scripts to permit ease
of modification. The rmtaped can be used as a replacement for /etc/rmt
and can be used to provide a simple permissions/redirection for rdump
requests. There's a trivial client "rmtwrite" which just dumps arbitrary
stuff to the tape server, so that a user could back up stuff with a
tar image or whatever whenever they wanted. Having a bunch of workstations
all pumping images to a single workstation over the net will load it
down pretty heavily, but it gets the pain over a lot faster than doing
each client in sequence. The assumption is that you have a fair sized
chunk of disk you can dedicate (600M?) depending on how many clients
you have - there's absolutely no support for "backup policy" as far
as what types of dumps get done, when.

	Would there be enough interest in this code to warrant writing
some documentation? If anyone wants it "as is" to peer at, let me know.
I'll document it some day, after I get the 200 other things I should be
documenting documented. :)

mjr.