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)...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert AT linux-m68k
DOT org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|