Jon LaBadie wrote: > On Tue, Jan 31, 2006 at 04:48:31PM +0100, Geert Uytterhoeven wrote: >> On Tue, 31 Jan 2006, Jon LaBadie wrote: >>> On Tue, Jan 31, 2006 at 10:56:13AM +0100, Geert Uytterhoeven wrote: >>>> I saw a similar thing when the disk of my backup server died last month. >>>> The machine ran Debian testing, and I used an Ubuntu Live CD (the Knoppix >>>> I had >>>> lying around didn't support SATA) to do the restore. >>>> >>>> After the restore, some services didn't work because some configuration >>>> files >>>> were owned by the wrong user. >>>> >>>> I ended up comparing the uids and gids in /etc/passwd and /etc/group on the >>>> restored image and on the Ubuntu Live CD, and for all differences, manually >>>> verifying all uids and gids of all restored files and directories. >>>> Fortunately >>>> this took much less time than expected :-) >>>> >>>> I noticed one very strange thing though: uids and gids were not changed in >>>> a >>>> consistent way: some files had the incorrect uid or gid from Ubuntu, while >>>> other related files that should have the same uid/gid had the one from the >>>> original system. So sometimes uids/gids were remapped during restore, but >>>> not >>>> always... >>> My understanding, subject to correction, is that by default guntar >>> restores by trying to match text names (user and group) between the >>> archive and the recovery system. If a match is found, then the >>> restore is to the numeric uid/gid of the recovery system, thus >>> matching the names, but not the necessarily the numeric ids in the >>> archive. If matching text names are not found, then the archive's >>> numeric ids are used. >> Exactly my understanding as well. >> >>> So you could easily get a real hodge-podge of names and numeric ids >>> by recovering to a different system. >>> >>> Archived System Recovery System Result of Recovery >>> name id # name id # name id # >>> >>> AAA 111 AAA 111 AAA 111 >>> BBB 222 BBB 234 BBB 234 >>> CCC 333 (no CCC) (no 333) (none) 333 >>> DDD 444 (no DDD) (EEE is 444) EEE 444 >>> >>> Note, 3 of the 4 cases result in a recovery that doesn't match the >>> originally archived system. May or may not be what was wanted. >> But as soon as /etc/passwd and /etc/group have been restored from backup as >> well and you boot from the restored medium, CCC and DDD become correct again, >> right? >> >> But this is not what I saw. Some files that should be owned by user BBB had >> uid 222, while others had 234. It was not consistent. >> >>> If the --numeric-owner option was used, only the second case would >>> change, the recovered result using an id of "222" rather than "234" >>> with a text name of either "none" or whatever name matchs id "222". >> Which is what you want (assumed you backup OS files, instead of doing a clean >> reinstall of the OS)... >> > > In such a case, a temporary workaround during restore could be to wrap gnutar: > > # mv /bin/tar /bin/tar.real > # echo 'exec /bin/tar --numeric-owner "$@"' > /bin/tar > # chmod +x /bin/tar > Since you renamed the real /bin/tar, perhaps you meant: echo 'exec /bin/tar.real --numeric-owner "$@"' > /bin/tar
Also, a reminder to restore the original after you're done might be worth noting (as someone whose done tricks like that in the past and forgot to undo them). Frank
