On 11/02/2016 11:18 PM, Gionatan Danti wrote:
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.
The above does not make sense. You are having to recover because there
was no backup and now you want to go forward without doing a backup?
Thank you very much Jim.
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
