Re: Recover from corrupted database due to failing disk
От | Gionatan Danti |
---|---|
Тема | Re: Recover from corrupted database due to failing disk |
Дата | |
Msg-id | b1db5f51c0a2ba01eab4768cf71c6f8f@assyoma.it обсуждение исходный текст |
Ответ на | Re: Recover from corrupted database due to failing disk (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: Recover from corrupted database due to failing disk
|
Список | pgsql-general |
Il 03-11-2016 00:21 Jim Nasby ha scritto: > On 11/2/16 2:02 PM, Gionatan Danti wrote: > > That means at least some of the Postgres files have been damaged > (possibly due to the failing disk). Postgres will complain when it > sees internal data structures that don't make sense, but it has no way > to know if any of the user data has been screwed up. I understand that (unfortunately) user data *will* be corrupted/lost. However, having no backup, I think the customer *must* accept that... > > I wouldn't trust the existing cluster that far. Since it sounds like > you have no better options, you could use zero_damaged_pages to allow > a pg_dumpall to complete, but you're going to end up with missing > data. So what I'd suggest would be: > > stop Postgres > make a copy of the cluster > start with zero_damaged_pages > pg_dumpall > stop and remove the cluster (make sure you've got that backup) > create a new cluster and load the dump The whole dump/restore approach surely is the most sensible one. However, I am concerned that if the dump have some undetected problems leading to a failed restore, I had to recover from the raw files (which I would like to avoid). Moreover, the expected remaining lifetime of such a database is 2/3 months only, as a new production system should be installed shortly. This is why I would prefer to use vacuum/reindex and avoid a full dump/restore. Thank you very much Jim. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8
В списке pgsql-general по дате отправления: