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
|
