Support for a (new?) backup concept

[Jens Stimpfle]

I've had an idea for a backup concept that could be new, or at least I
have not been able to find anything similar on the net. It's something
like a "reversed rsync", although this term is already commonly used for
"backup restoration".

The goal is to get the best of both pull and push backup methods. Let
the "client" have some data to be backed up to the "server". The client
is granted key-based ssh login to the server, with a
command="rsyncwrapper" directive (ssh forced command) in an
authorized_keys file. This wrapper on the server essentially launches an
rsync session in "client mode" which expects stdin/stdout to be already
connected to a remote shell (on the client machine, through the very
same ssh connection), and uses it to launch an rsync in server sender
mode (on the client machine) and talk to it.

Here are some characteristics:

 - The "rsync client" on the server can rather safely be run with root
   privileges and thus make very exact backups (pull).
 - Given that the wrapper script on the server is not completely broken,
   it's not possible for malicious code on the client to destroy its own
   backups (pull).
 - Different clients with name or uid clashes in the backup files do not
   interfere as their data can be guaranteed to be stored in different
   directories (pull).
 - The backup session is initiated by the client (which does not prevent
   the server from comfortably posing some restrictions on the frequency
   or time of backups), which makes for a great deal of flexibility.
   This also avoids possible NAT problems for mobile devices (push). The
   setup is generally rather decentralized, which is A Good Thing.
 - No client needs to run an ssh server.
 - This method's safety concerns are the same as with the pull method,
   minus the need for an ssh server on the client (Instead we need one
   on the server, but it is there in most cases anyway). For the client,
   it is painless to deploy a restricted shell that will only run an
   "rsync --server --sender ...", and client safety can further be
   improved by lowering the privileges of the shell receiving this
   commandline. 
 - Configuration of backup behaviour remains comfortable at least to
   some degree (and non-statical, per-session) because the client can
   provide commandline arguments to the forced command which the wrapper
   script then only needs to allow / translate.

I'm currently a running very similar setup, using a wrapper script that
calls rsync with an -e "fake remote shell" option. This fake shell does
only redirect its stdin/out to/from named pipes on the server, and a
second ssh connection from the client connects those fifos to a local
shell.

However, it would be a much more elegant solution to have an option to
rsync that makes it assume being already connected to a remote shell via
fd 0/1.

>From a look at the rsync code, I think the feature could be integrated,
although with some special handling (stdin/out should be dup'ed to other
fds and then closed before any of the debug/error/verbose printing to
stdout occurs. Perhaps what is normally printed to stdout could be
optionally written to a logfile. The "rsync -- server" commandline which
is normally appended to a remote shell commandline must instead be
written to stdout).

I would like to know what you generally think of this concept, and if
you think integration of some support code would be worth a try -- or
would the setup complications and the additional cruft in the code
outweigh the merits for most users? Or has anyone heard of similar
approaches, or ones that achieve the same with less complications?


Please excuse the long input / thanks for reading / hoping to receive
answers!

-Jens Stimpfle