Re: bad block problem

On Thu, 08 Dec 2011 09:02:15 +0800, Craig Ringer wrote:

> On 12/08/2011 08:20 AM, Walter Hurry wrote:
>> On Wed, 07 Dec 2011 22:20:30 +0000, jkells wrote:
>>
>>> I am relying on identifying and correcting a bad block.
>>
>> Well, good luck with that. Most of the time you can't. Just check your
>> disk, replace it if necessary, restore from your backup and roll
>> forward.
>>
>> Oh, you can't do that, since you didn't bother to back up. Never mind.
>
> Unless you're using synchronous replication to clone *every* transaction
> on commit to a spare machine, you'll still lose transactions on a
> failure no matter how good your backups are.
>
> Even if the OP was doing nightly dumps, they'd be entirely justified in
> wanting to try to get a more recent dump on failure.
>
> If they're not backing up at all, yes, that was dumb, but they know that
> now. Asking for help isn't unreasonable, and this isn't a stupid "just
> google it" question. They've made an effort, posted useful info and log
> output, etc. Please don't be too hard on them.
>
> --
> Craig Ringer

For those that replied with suggestions I appreciate your time and
effort. For the others, reasons why backups where not done can be many,
from just didn't do it, faulty backup process, don't have the space, PIT
windows,not allowed to backup data, and the list can go on and on. Under
a no backup or insufficient backup policy, we are all aware of the
implications and understand the risk. I have no problem working under
this policy and other fully functional operational standard policies. As
long as your management is aware then issues like this become a trade off
and you have done your do diligence. I simply wanted to understand the
methods of zeroing out a block on a database file since I was not sure
how to interpret the results from following some procedures and write-
ups. If successful great, if not then we move the next step of recovery.