Re: SUG: Automatic RPM database verification and repair

[Jeff Johnson <n3npq jbj gmail com>]

On Nov 28, 2006, at 11:33 PM, Tony Nelson wrote:

> I haven't seen this come through.
>
> At 3:19 PM +0800 11/27/06, Nerazzurri wrote:
> > > None of the above should be considered criticism, just history.
> > >
> > > There are two needs if one wants to protect against rpmdb data loss.
> > >
> > > The most important is saving a copy of /var/lib/rpm/Packages  
> > > routinely.
> > > All other information in an rpmdb can be regenerated from a  
> > > reasonably
> > > recent copy of Packages. And in most cases a depsolver like
> > > yum/smart/apt/poldek
> > > will reinstall the packages that have changed since the last copy of
> > > Packages
> > > was saved.
> >
> > but how can i know which version of "/var/lib/rpm/Packages" is  
> > correct
> > and work well, if i backup a corrupted "Packages", the backup work  
> > will
> > be senseless, isnt it?  :-)
>
> The "right" way would be to make a copy of the Packages file, check  
> it, and
> only save it if the check passes.  According to Jeff, the proper  
> check is
> to do a "rpm --rebuilddb" with that Packages file and see if it  
> works, but
> I haven't tried that method.

Sorry for not replying.

Doing --rebuildib is not the "proper" check, nor is --rebuilddb the  
only check.

What I tried to say is

    1) Doing --verifydb does not verify the data in an rpmdb, but  
only verifies
    the Berkeley DB structural elements.

    2) All the essential data is in Packages, the indices can be  
rebuilt by --rebuilddb
    whenever needed.

    3) The integrity of headers contained in Packages is verfied  
when the header
    is read from an rpmdb.

There are very few cases of damaged headers in Packages that have  
been reported
to me in the last 2 years, none that were not easily detectable and  
fixed.

73 de Jeff