From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Leif Biberg Kristensen <leif(at)solumslekt(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: I/O error on data file, can't run backup |
Date: | 2011-10-06 05:07:11 |
Message-ID: | 4E8D377F.3070206@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/06/2011 03:06 AM, Leif Biberg Kristensen wrote:
> I seemingly fixed the problem by stopping postgres and doing:
>
> balapapa 612249 # mv 11658 11658.old
> balapapa 612249 # mv 11658.old 11658
>
> And the backup magically works.
Woooooo! That's ... "interesting".
I'd be inclined to suspect filesystem corruption, a file system bug /
kernel bug (not very likely if you're on ext3), flakey RAM, etc rather
than a failing disk ... though a failing disk _could_ still be the culprit.
Use smartmontools to do a self-test; if 'smartctl -d ata -t long
/dev/sdx' (where 'x' is the drive node) is reported by 'smartctl -d ata
-a /dev/sdx' as having passed, there are no pending or uncorrectable
sectors, and the disk status is reported as 'HEALTHY' your disk is quite
likely OK. Note that a 'PASSED' or 'HEALTHY' report by its self doesn't
mean much, disk firmwares often return HEALTHY even when the disk can't
even read sector 0.
I strongly recommend making a full backup, both a pg_dump *and* a
file-system level copy of the datadir. Personally I'd then do a test
restore of the pg_dump backup on a separate Pg instance and if it looked
OK I'd re-initdb then reload from the dump.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Buckley | 2011-10-06 05:47:29 | user-interface to upload csv files |
Previous Message | khizer | 2011-10-06 04:41:39 | Fwd: Postgresql-8.2 Replication |