From: Hannes Dorbath <light@theendofthetunnel.de>
To: pgsql-admin@postgresql.org
Cc: Chander Ganesan <chander@otg-nc.com>
Subject: Re: [GENERAL] Backup
Date: Wed, 06 Feb 2008 14:49:42 +0100
Message-ID: <47A9BAF6.9050809@theendofthetunnel.de> (raw)
In-Reply-To: <47A9B62C.8060508@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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: light@theendofthetunnel.de, pgsql-admin@postgresql.org, chander@otg-nc.com
Subject: Re: [GENERAL] Backup
In-Reply-To: <47A9BAF6.9050809@theendofthetunnel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox