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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html