Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 40E2C2E162B for ; Thu, 31 Jan 2008 11:00:29 -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 09519-03 for ; Thu, 31 Jan 2008 11:00:14 -0400 (AST) Received: from smtp162.iad.emailsrvr.com (smtp162.iad.emailsrvr.com [207.97.245.162]) by postgresql.org (Postfix) with ESMTP id 5FA8C2E0366 for ; Thu, 31 Jan 2008 11:00:23 -0400 (AST) Received: from relay6.relay.iad.emailsrvr.com (localhost [127.0.0.1]) by relay6.relay.iad.emailsrvr.com (SMTP Server) with ESMTP id 086EB6FE82B; Thu, 31 Jan 2008 10:00:22 -0500 (EST) Received: by relay6.relay.iad.emailsrvr.com (Authenticated sender: chander-AT-otg-nc.com) with ESMTP id 896A6702074; Thu, 31 Jan 2008 10:00:21 -0500 (EST) Message-ID: <47A1E28C.8030708@otg-nc.com> Date: Thu, 31 Jan 2008 10:00:28 -0500 From: Chander Ganesan User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Simon Riggs CC: Phillip Smith , 'Dominic Carlucci' , pgsql-general@postgresql.org, pgsql-admin@postgresql.org, carlucci@cae.ca Subject: Re: [GENERAL] Backup References: <00a201c85ee9$fbd1ca00$9b0014ac@wbaus090> <1201252875.4257.387.camel@ebony.site> <47A1BD51.3030902@otg-nc.com> <1201786128.4453.287.camel@ebony.site> In-Reply-To: <1201786128.4453.287.camel@ebony.site> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200801/294 X-Sequence-Number: 28068 Simon Riggs wrote: > On Thu, 2008-01-31 at 07:21 -0500, Chander Ganesan wrote: > >> If you don't mind if you lose some transactions >> > > 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. > > As far as I am concerned, if any Postgres user loses data then we're all > responsible. > I understand your point, but indicating that you can't trust a point-in-time snapshot of the database is, IMHO, the same as saying you can't trust PostgreSQL's automatic crash recovery, since the two are essentially the same thing... -- Chander Ganesan Open Technology Group, Inc. One Copley Parkway, Suite 210 Morrisville, NC 27560 919-463-0999/877-258-8987 http://www.otg-nc.com