For full system backup, rsync obviously needs to run as root on the machine being backed up
For preservation of user/group/permissions info, rsync also typically needs to be run as root on the machine storing the backup - although there appear to be various ways to avoid this (e.g. using fakeroot -s, or running rsync inside a Xen VM which only stores the backup of one host) Can anyone comment on some of the following: - is it more secure to run rsync as a command within ssh (probably using command=some_wrapper in authorized_keys) or to run an rsync daemon (with VPN and/or restricted port forwarding, e.g. permitopen="localhost:873" in authorized_keys) ? - are there any ideal examples of wrapper scripts that set up a fakeroot environment (either on each invocation or wrapping the rsync daemon)? - is there any facility for command line filtering (or any example of such a wrapper script) when running in ssh mode? E.g. to stop people using `some nasty rm command` or detect attempts to steal ../../../secret_file ? - as an alternative to fakeroot, is there any type of filesystem that can be run on the backup server that would allow non-root processes to manipulate file ownership and permissions? I couldn't find examples of this in the common Linux filesystems. - is there any possibility for the rsync process on the backup server to keep the destination files within a tar file (or some virtual filesystem that is backed by a tar file) and then the owner/permission data can be stored in the tar file (without needing to run as root)? I've seen a few examples online that answer parts of these questions, but nobody has shared a complete recipe, and some of the issues are not addressed anywhere -- 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