Message-ID: <4EE00D71.6090705@ringerc.id.au>
Date: Thu, 08 Dec 2011 09:05:53 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: pgsql-admin@postgresql.org, jkells <jtkells@verizon.net>
Subject: Re: bad block problem
References: <1OQDq.131420$034.90105@en-nntp-06.dc1.easynews.com>
	<4EDFA52F0200002500043A8A@gw.wicourts.gov>
In-Reply-To: <4EDFA52F0200002500043A8A@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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