Restoring from backup, preserving uids

[Matt McCutchen]

On Sat, 2008-08-02 at 15:50 -0500, Neil Gunton wrote:
> The point of my original message wasn't so much to get a 
> workaround, as to suggest a new option for rsync that would make this 
> kind of task easier.

Well, it looks like you really know what you want here.  You're welcome
to create and use a modified version of rsync with the option, but
inclusion of the option in the main rsync is doubtful (Wayne, please
feel free to correct any of this).  Everyone who uses rsync extensively,
myself included, could probably name a bunch of options that would make
their life easier.  Even if many of the options are relatively simple,
including all of them in the main rsync would make it even harder to
maintain than it is.  Our focus in adding options is not to make
individual use cases easy but to make large groups of use cases easier.
Users with complex or uncommon needs are expected to meet rsync halfway,
and I am always happy to help them do so via this list.

> That above perl solution sounds very complex.

Not really.  You just have to build rsync with the usermap.diff patch:

http://rsync.samba.org/ftp/rsync/patches/usermap.diff

put the scripts in Wayne's email on your $PATH, and use the rsync
command he wrote.  You're expected to meet rsync halfway here.  It
provides a generic mechanism to specify a uid/gid mapping, and you wire
up your data to that mechanism.

> The whole point of rsync in the first place was to simplify 
> backing up - I mean, you could have done what rsync does using a bunch 
> of perl code, but someone decided to try to make it simpler.

I don't think that's a fair comparison: it would be ridiculous for
everyone who wants to make a backup to write his/her own rsync, but it's
not hard to use either the usermap patch or the chroot-over-ssh approach
from my other email.

> I think the 
> old/new uid issue is very common, given the scenario of backing up your 
> system to something like a a local USB hard drive and then trying to 
> restore your config to a newly installed system.

I don't think restoring to a system where the user/group names
correspond to different ids is as common as you believe.  If I restored
configuration files owned by system users to a newly installed system, I
might let the overwritten config files keep the same attributes (in case
they changed in the new install) instead of trying to preserve
attributes.  Plus, Fedora seems to be trying to standardize the
uids/gids of system users across installs:

https://fedoraproject.org/wiki/PackageUserCreation

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/6952afd2/attachment.bin