A way to ensure rpm database robustness?

[Stuart D Gathman]

On 01/03/2013 02:02 PM, Stuart D Gathman expounded in part:
> On Jan 3, Reshetova, Elena transmitted in part:
>
>> I have a simple question and sorry if it was asked before and I just 
>> didn’t
>> find it in archives.
>>
>> Suppose we run rpm operation (installation, update or anything) on an
>> embedded device and power suddenly goes off. This can happen if user 
>> removes
>> the battery for example.
>>
>> In such cases, rpm database can get corrupted since the operation was
>> stopped in the middle. Rpm database can be rebuild after, but this is 
>> quite
>> annoying to do. Is there any ways to ensure that database stays sane 
>> even in
>> such cases? Of course some wrapper can be used for rpm to do the checks,
>> backup database and etc., but does rpm itself have anything for it?
>
> An interesting, and feasible idea. Maybe 'yum' and other higher level
> wrappers are the place to fully implement it. Yum does have a way
> to reapply the last transaction (although it has never worked for me -
> I'm probably doing it wrong). But that depends on the rpm database
> at least being in a consistent state - which a backup of said
> database would accomplish.
Actually, removing the battery, and other hard power failures, tends to 
cause serious filesystem damage due to writeback caching, so that 
sectors actually written to the media are not in the same order as the 
filesystem writes them. This is no problem with a kernel crash, because 
the disk finishes up any cached writes. When the disk loses power with 
writes still cached, it is a real problem.