Re: Errors after cloning OS to new disk under Hyper-V - Mailing list pgsql-general

From Tom Lane
Subject Re: Errors after cloning OS to new disk under Hyper-V
Date
Msg-id 3918730.1595048250@sss.pgh.pa.us
Whole thread Raw
In response to RE: Errors after cloning OS to new disk under Hyper-V  (<ertan.kucukoglu@1nar.com.tr>)
List pgsql-general
<ertan.kucukoglu@1nar.com.tr> writes:
> From: Rob Sargent <robjsargent@gmail.com>
>> Have you tried to REINDEX as suggested?

> I cannot get access to psql. If there is a way to reindex without having to login first, I do not know how to do
that.

The disaster recovery process that Rob is suggesting goes like this:

* Shut down server, if it's running

* Start a standalone backend with the -P (disable system indexes) switch:

    postgres --single -P database_name

* REINDEX everything in sight, or at least REINDEX SYSTEM

* Quit standalone backend (control-D on Unix, less sure about Windows)

* Repeat for each database you care about

* Restart server

TBH, though, I have no expectation that this will help you.  It can
work for fixing a situation with limited damage to system catalog
indexes; but it cannot fix damage to the catalog tables themselves.
Given that the damage seems to have been done by a faulty filesystem-level
copying tool, there's little reason to hope that only the indexes and
not the tables were damaged.  No non-Postgres-specific tool would be
likely to know the difference, because they're all just files.

But, having said that, the error messages you quoted seem to be
complaining only about indexes.  Maybe it's worth trying this.

Failing that, you could call in a professional data recovery
consultant, if the data is valuable enough for that to make sense.
But this sort of situation is not likely to be recoverable
without detailed expert help, and maybe not then.  (A word of
advice: if calling in outside help is even faintly possible,
don't do *anything* without first making a filesystem-level
backup that you can trust.  Otherwise your own attempts might
just break things beyond the last chance of repair.)

            regards, tom lane



pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Errors after cloning OS to new disk under Hyper-V
Next
From: Radoslav Nedyalkov
Date:
Subject: Could not open file pg_xact/0E97