Re: bad block problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 

-- 
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux