Restoring from backup, preserving uids

[Matt McCutchen]

On Sat, 2008-08-02 at 09:41 -0500, Neil Gunton wrote:
> Thanks for the tip. I just took at look at the man page for rsyncd.conf 
> and it seems to warn you away from combining chroot:
> 
> "... disadvantages of ... complicating the preservation of users and 
> groups by name (see below)."

The "disadvantages" are that (1) rsync uses the /etc/passwd inside the
chroot instead of the global one and (2) there are security issues when
exposing a writable daemon to untrusted users.  But (1) is precisely
what you want and (2) doesn't apply, so you can ignore the warning.

> I'm suggesting that it might be a nice addition to rsync if we could add 
> an option to use a passwd file for the mapping of the src uids to the 
> current (dest) uid/username system. This would then mean you don't have 
> to set up a special chrooted rsync daemon simply in order to do restore 
> from your local backup drive. Instead you could just do something like:
> 
> rsync -av --src-passwd-file=/backup/etc/passwd /backup/etc /

I understand your proposal.  My point is that such an option would be
awkward to implement because rsync accesses /etc/passwd via the C
library, and it has no way to make the C library use a different file
(except by chrooting), so rsync would have to reimplement the
passwd-file parsing itself, which would be ugly.

And I think I can simplify the chrooting approach a bit.  Instead of
setting up a daemon, you can use ssh to localhost with an --rsync-path
that does the chroot:

rsync -av --rsync-path='chroot /backup && rsync' localhost:/etc /

Note that this does use the copy of rsync inside the chroot as the
sender, just as if you pulled from the running machine over the network.
FYI, to test this successfully on Fedora 9, I needed to have at least
the following inside the chroot: rsync, its shared libraries (those
shown by ldd plus /lib/libnss_files.so.2), the targets of the shared
library symlinks, /etc/passwd, and /etc/group.

The command could be simplified further if rsync gained a --chroot=PATH
option that applies separately to each end of a local run (unlike the
current implementation of --fake-super, which I think should be changed
to this saner behavior):

rsync -av --chroot=/backup /etc /

(Maybe --no-numeric-ids would be necessary?  I have no way to test.)
Since a local run is treated as a push, the --chroot option would apply
only to the sender.  To apply it only to the receiver, one would use
--remote-option=--chroot=/backup .

Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/rsync/attachments/20080802/96b34e51/attachment.bin