Re: Recovering database from crashed HD (bad sectors)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amitabh Kant <amitabhkant(at)gmail(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Recovering database from crashed HD (bad sectors)
Date: 2015-07-18 17:30:43
Message-ID: 12522.1437240643@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Amitabh Kant <amitabhkant(at)gmail(dot)com> writes:
> As for running the sql command as suggested by Tom, here is the result:
> template1=# select * from pg_class where pg_relation_filenode(oid) = 11678;

> pg_class | 11 | 83 | 0 | 10 | 0 |
> 0 | 0 | 8 | 281 | 0 | 0
> | t | f | p | r | 26 |
> 0 | t | f | f | f | f
> | 662 | {=r/pgsql} |

That's about the worst possible answer :-(. Without pg_class, you have
little hope of telling which is which among the other files; and there
would be no real commonality with the contents of pg_class from other
databases in the installation, so no way to jury-rig something. Moreover,
because pg_class is consulted *very* early in backend startup, it seems
entirely likely that the failure you're seeing is only the tip of the
iceberg; there very possibly are other files that are also missing or
badly damaged.

It's possible that a professional data recovery team could extract
something from the wreckage, but it would take a lot of time and money.
Personally I'd say it's time to go to your backups.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2015-07-18 22:40:15 Re: Recovering database from crashed HD (bad sectors)
Previous Message Amitabh Kant 2015-07-18 17:13:27 Re: Recovering database from crashed HD (bad sectors)