This has been a great discussion, folks.  Lots of food for thought.

Rather than respond to other comments, I'm going to summarize what I
think the requirements are, and then discuss some specific design
considerations. 

Requirements:

    minimal requirement for a host to be backed up: an archive program
    that can write to stdout, an rshd that works, and a C compiler to
    compile a wrapper that somehow deals with the exit status of the
    remote command.

Implementation:

There are really 2 separate proxy schemes: one allows one host to "run"
the backup for another through rsh.  This would probably be used in
special cases where the host to be backed up doesn't have Perl or NFS or
the db library or whatever.  Call this a "backup proxy".  The other
proxy is a general mechanism for dealing with the output of the archive
programs.  Call this a "tape proxy".

backup proxy

    I don't think this needs to be complicated.  Until we have a tape
    proxy running, the proxy host just needs to rsh a backup command to
    the host being backed up, ala "rsh foo dump 0f allosaur:/dev/nrst0".
    The only hard part is dealing with the rsh status info (see below).

tape proxy

    I've described this before, so   I won't go into it here, except to
    say that its the program that would handle all archive output,
    redirect it to disk or tape, handle eot (tape rollover, interact
    with a jukebox, request that the oper mount a tape, whatever).  I
    was thinking of having it make database lookups/updates directly,
    but that may not be feasible, in which case it will have to have
    some sort of contact with the master db process (needs to update the
    tflist in each backup entry as it moves to new tapes, needs to be
    able to inquire about the next tape/drive to roll to, lock tape
    devices and so on).

    I was planning on writing it so that each piece wouldn't need to
    retain a window of buffered data - it would just write things
    through to the tape proxy that was actually handling the tape
    device.  If that proxy needs to move things to a new host, it would
    contact the original proxy and write the unwritten data back to it
    and die.  The original could then create a new proxy on the correct
    host and send that data to it.

rsh status info

    This is a tough problem, and I need to solve it in a general way, so
    that I get correct status info when I do "rsh dd" to write a tape
    label, and other things.

    We need a wrapper of some sort that records the exit status of the
    command being run.  I'm not sure how best to report that status,
    however.  I'll have to think about that.