| From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | pgsql-admin(at)postgresql(dot)org, jkells <jtkells(at)verizon(dot)net> |
| Subject: | Re: bad block problem |
| Date: | 2011-12-08 01:05:53 |
| Message-ID: | 4EE00D71.6090705@ringerc.id.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On 12/08/2011 07:41 AM, Kevin Grittner wrote:
> That sounds like your storage system is failing, quite independently
> from PostgreSQL. Copy the entire data directory tree to some other
> medium immediately, and preserve this copy. If you hit bad blocks,
> retry if possible.
If you find files you can't copy in their entirety, try using dd_rescue
to copy it with a hole for the bad block. dd_rescue is an _incredibly_
useful tool for this, as it'll do bad-block-tolerant copies quickly and
efficiently.
Once you have a complete copy of your datadir, stop working on the
faulty machine. Make your first copy read-only. Duplicate the copy and
work on the duplicate when trying to restore. I'd start with enabling
zero_damaged_pages to see if you can get a dump that way.
Do **NOT** enable zero_damaged_pages on the original. Do it on the
duplicate of the copied data.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | lst_hoe02 | 2011-12-08 12:04:30 | Re: Number of connections still limited on Windows 64-bit? |
| Previous Message | Craig Ringer | 2011-12-08 01:02:15 | Re: bad block problem |