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

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)