From: Hannes Dorbath <light@theendofthetunnel.de>
Subject: Re: [GENERAL] Backup
Date: Wed, 06 Feb 2008 14:49:42 +0100
Organization: Hub.Org Networking Services
Lines: 50
Message-ID: <47A9BAF6.9050809@theendofthetunnel.de>
References: <00a201c85ee9$fbd1ca00$9b0014ac@wbaus090>
	<1201252875.4257.387.camel@ebony.site>
	<47A1BD51.3030902@otg-nc.com>
	<1201786128.4453.287.camel@ebony.site>
	<20080131143405.GC21660@svana.org>
	<20080131144314.GH11977@svr2.hagander.net>
	<47A1E2F6.7060108@otg-nc.com>
	<47A9B62C.8060508@theendofthetunnel.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Chander Ganesan <chander@otg-nc.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
In-Reply-To: <47A9B62C.8060508@theendofthetunnel.de>
To: pgsql-admin@postgresql.org

Hannes Dorbath wrote:
> Chander Ganesan wrote:
>> Magnus Hagander wrote:
>>> On Thu, Jan 31, 2008 at 03:34:05PM +0100, Martijn van Oosterhout wrote:
>>>  
>>>> On Thu, Jan 31, 2008 at 01:28:48PM +0000, Simon Riggs wrote:
>>>>   
>>>>> That sentence has no place in any discussion about "backup" because 
>>>>> the
>>>>> risk is not just a few transactions, it is a corrupt and inconsistent
>>>>> database from which both old and new data would be inaccessible.
>>>>>       
>>>> Hmm? I thought the whole point of a filesystem snapshot was that it's
>>>> the same as if the system crashed. And I was fairly sure we could
>>>> recover from that...
>>>>     
>>>
>>> That was my assumption as well. *Assuming* that the filesystem 
>>> snapshot is
>>> consistent. There are a bunch of solutions that don't do consistent
>>> snapshots between different partitions, so if your WAL or one 
>>> tablespace is
>>> on a different partition, you'll get corruption anyway... (seen this in
>>> Big Commercial Database, so that's not a pg problem)
>>>   
>> Agreed.  That's why I made it a point to mention that all of your 
>> tablespaces should be on the same file system...  In hindsight, I 
>> should have also stated that your WAL logs should be on the same file 
>> system as 
> 
> One more reason to consider using Solaris ZFS -- it does consistent 
> snapshots across all file systems.

In general file system snapshots are quite a pain with Linux LVM.

Even when using separate spindles for the snapshot COW area the impact 
on write performance on the origin LV is still huge. You'll have a hard 
time to write with more than 15MB/sec to the origin LV.

Additionally when you lost your COW device there is this nice bug in 
vgreduce --removemissing that will silently delete your origin LV as 
well: http://readlist.com/lists/redhat.com/linux-lvm/0/2025.html

Not to mention that LVM does not support write barriers and does mess 
with any kind of stripe alignment of your file system.


-- 
Best regards,
Hannes Dorbath