Subject: Re: Hot Backup
From: Robert Treat <xzilla@users.sourceforge.net>
To: Andrew Sullivan <andrew@libertyrms.info>
Cc: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
In-Reply-To: <20021024161128.H31360@mail.libertyrms.com>
References: <3DA323B1.3732.155CAB4F@localhost>
 <1034084444.6801.12.camel@camel>
	<20021022103442.C4016@mail.libertyrms.com>
	<1035470520.12582.7.camel@camel>
	<20021024161128.H31360@mail.libertyrms.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 24 Oct 2002 18:40:09 -0400
Message-Id: <1035499209.12582.34.camel@camel>
Mime-Version: 1.0

On Thu, 2002-10-24 at 16:11, Andrew Sullivan wrote:
> On Thu, Oct 24, 2002 at 10:42:00AM -0400, Robert Treat wrote:
> > I think you missed the part of the thread where the nuclear bomb hit the
> > data center.  hmm... maybe it wasn't a nuclear bomb, but it was getting
> > there. :-)
> 
> No, I didn't miss it.  Have a look at the Internet Society bid to run
> .org -- it's available for public consumption on ICANN's site.  One may
> belive that, if people are launching nuclear attacks, suicide
> bombings, and anthrax releases, the disposition of some set of data
> one looks after is unlikely to be of tremendous importance.  But
> lawyers and insurers don't think that way, and if you really want
> PostgreSQL to be taken seriously in the "enterprise market", you have
> to please lawyers and insurers.  
> 
> Having undertaken the exercise, I really can say that it is a little
> strange to think about what would happen to data I am in charge of in
> case a fairly large US centre were completely blown off the map.  But
> with a little careful planning, you actually _can_ think about that,
> and provide strong assurances that things won't get lost.  But it
> doesn't pay to call such questions "silly", because they are
> questions that people will demand answers to before they entrust you
> with their millions of dollars of data.  
> 

If someone tries to argue that PostgreSQL isn't viable as a database
solution because it doesn't have PITR, but their PITR solution is
storing all that data on the same machine, well, that's silly. I'm not
saying PITR isn't a good thing, but I can always come up with some
far-fetched way to show you why your backup schema isn't sufficient, the
point is to determine how much data loss is acceptable and then plan
accordingly. (And yes, I have had to plan the what if the data center
gets blown up scenario before, but that doesn't mean I require my
database can withstand global thermal-nuclear war on every project I do)

Robert Treat