Hi, I use rsync to back up my Linux system to hard drive. I use the -av option, and it preserves uids. However if I reinstall Linux, and try to restore from the backup hard drive, the owner permissions get all mixed up, I assume since the numeric uids don't match up with the equivalent usernames any more. For example, user nobody might have had uid 123 in my old system, but now in the new one it gets 456. So when I restore, for example, /etc/mail for my sendmail setup, which has very specific ownerships on all the files, they all get owned by whatever users happen to have those uids. It's a bit of a mess, and makes restoring from a hard drive backup much more tricky. So, first question: Am I missing something here? Am I backing up or restoring in the wrong way? Second question: If I am doing it "right" (using -av) then may I suggest a possible solution? I think rsync could match up the "old" uids from the backup with the "current" uids in the system if it had access to the old /etc/passwd file, which maps the uids to usernames. So would it be a good option to add to rsync to give it a path to the "old" passwd file, in order to match up the uids in the source dir to the ones in the destination? Destination would be assumed to use the current passwd, of course. This would help map the old uids to the new ones. Does that make any sense? Thanks! Neil
On Sat, 2008-08-02 at 08:26 -0500, Neil Gunton wrote:> I think rsync could match up the "old" uids from > the backup with the "current" uids in the system if it had access to the > old /etc/passwd file, which maps the uids to usernames. So would it be a > good option to add to rsync to give it a path to the "old" passwd file, > in order to match up the uids in the source dir to the ones in the > destination? Destination would be assumed to use the current passwd, of > course. This would help map the old uids to the new ones.That's the right idea, but rsync relies on the getpw* functions of the C library rather than reading /etc/passwd directly, so the fix wouldn't be as simple as adding an option to use a different path to /etc/passwd. What you can do that works right now is pull from an rsync daemon configured to chroot into the backup so that the daemon's calls to getpw* access the /etc/passwd file inside the chroot. 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/661544d1/attachment.bin
On Sat 02 Aug 2008, Neil Gunton wrote:> Hi, I use rsync to back up my Linux system to hard drive. I use the -av > option, and it preserves uids. However if I reinstall Linux, and try toJust a note: I'd recommend also using -H to preserve hard links. Traditionally a unix / linux system will have many files hard-linked (although a quick check shows less than I expected). Paul Slootman
On Sat, Aug 02, 2008 at 08:26:47AM -0500, Neil Gunton wrote:> However if I reinstall Linux, and try to restore from the backup hard > drive, the owner permissions get all mixed up, I assume since the > numeric uids don't match up with the equivalent usernames any more.One option is to try usermap.diff in the patches dir. This provides a simple user+group mapping facility that could be used to handle a reasonably-sized set of users and groups (it is not written to handle huge numbers of mapping rules, though). For instance, the latest version of the patch will come with these two helper scripts (that differ only in the order they output the user and ID values): ==> support/mapfrom <=#!/usr/bin/perl while (<>) { push @_, "$2:$1" if /^(\w+):[^:]+:(\d+)/; } print join(',', @_), "\n"; ==> support/mapto <=#!/usr/bin/perl while (<>) { push @_, "$1:$2" if /^(\w+):[^:]+:(\d+)/; } print join(',', @_), "\n"; You could do a copy from a backup by doing this: rsync -av --usermap=`mapfrom /backup/etc/passwd` \ --groupmap=`mapfrom /backup/etc/group` \ /backup/dir /dest/ I briefly looked at potentially making these options handle a filename, but I didn't want to over-complicate them. Having an alternate means of doing uid/gid lookups would probably be a better match for something that would support files, and there's a daemon version of an alternate name mapper available in the patches/nameconverter.diff file (but I haven't decided how much I like that idea yet, and it only supports a daemon). ..wayne..