På onsdag 10. januar 2018 kl. 22:36:42, skrev Jeff Janes <jeff.ja...@gmail.com <mailto:jeff.ja...@gmail.com>>: On Wed, Jan 10, 2018 at 12:23 PM, Thomas Poty <thomas.p...@gmail.com <mailto:thomas.p...@gmail.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 andr...@visena.com <mailto:andr...@visena.com> www.visena.com <https://www.visena.com> <https://www.visena.com>
