Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 1B7132E016C;
	Thu, 31 Jan 2008 10:43:19 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 04120-02; Thu, 31 Jan 2008 10:43:07 -0400 (AST)
Received: from svr2.hagander.net (svr2.hagander.net [88.198.128.226])
	by postgresql.org (Postfix) with ESMTP id 475E02E02CA;
	Thu, 31 Jan 2008 10:43:15 -0400 (AST)
Received: by svr2.hagander.net (Postfix, from userid 1000)
	id 07961DCC676; Thu, 31 Jan 2008 15:43:14 +0100 (CET)
Date: Thu, 31 Jan 2008 15:43:14 +0100
From: Magnus Hagander <magnus@hagander.net>
To: Simon Riggs <simon@2ndquadrant.com>, Chander Ganesan <chander@otg-nc.com>,
	Phillip Smith <phillip.smith@weatherbeeta.com.au>,
	'Dominic Carlucci' <carlucci@cae.com>, pgsql-general@postgresql.org,
	pgsql-admin@postgresql.org, carlucci@cae.ca
Subject: Re: [GENERAL] Backup
Message-ID: <20080131144314.GH11977@svr2.hagander.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080131143405.GC21660@svana.org>
User-Agent: Mutt/1.5.11
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200801/293
X-Sequence-Number: 28067

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)

//Magnus