Sv: Re: Sv: Re: Sv: Re: Sv: Re: Sv: Re: data-checksums

På onsdag 10. januar 2018 kl. 22:36:42, skrev Jeff Janes <jeff(dot)janes(at)gmail(dot)com
<mailto:jeff(dot)janes(at)gmail(dot)com>>:
On Wed, Jan 10, 2018 at 12:23 PM, Thomas Poty <thomas(dot)poty(at)gmail(dot)com
<mailto:thomas(dot)poty(at)gmail(dot)com>> wrote: Hello, A question seems to be, according
to me, important :
How a corruption, detected thanks to data-checksums, is fixed?

 
Take two full cold backups of the current mess you have, including the
executables, and lock one of them away where you can't accidentally do
something to make it worse.
 
Replace the hardware (or fix the software bug) which lead to this, so it
doesn't eat more of your data than it already has.
 
If you have a wal archive, then restore from the most recent backup and
recover it forward with the WAL, hoping your hardware problem hasn't polluted
that as well.  Make sure it rolls forward as far as you think it should.  If
you think it rolled forward all the way, then you are probably done.  I'd take
a full cold backup as well as as full pg_dump(all) at this point and lock it
away for future forensics, just in case, and also to see if any more errors are
found by the pg_dump.
 
I'd also extract the damaged block and inspect it.  If the value says "MQs.
Johnson" but the obvious (due to context) correction to "Mrs. Johnson" matches
what the post-recovery block also says, then I'd say you are pretty good.  If
the damage was to a floating point number or a header in which you don't have
any useful context to guide you, you might want to engage a professional at
this kind of thing if the data is very important to you.

 
Btrfs actually fixes (some) corruption once it detects it, so Thomas' question
is not all that far-fetched.
 
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas(at)visena(dot)com <mailto:andreas(at)visena(dot)com>
www.visena.com <https://www.visena.com>
<https://www.visena.com>