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
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) |