Re: Errors after cloning OS to new disk under Hyper-V

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Errors after cloning OS to new disk under Hyper-V
Дата
Msg-id 3918730.1595048250@sss.pgh.pa.us
обсуждение исходный текст
Ответ на RE: Errors after cloning OS to new disk under Hyper-V  (<ertan.kucukoglu@1nar.com.tr>)
Список 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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Errors after cloning OS to new disk under Hyper-V
Следующее
От: Radoslav Nedyalkov
Дата:
Сообщение: Could not open file pg_xact/0E97