Skip site navigation (1) Skip section navigation (2)

Re: PITR recovery

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Ben K(dot)" <bkim(at)coe(dot)tamu(dot)edu>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PITR recovery
Date: 2007-01-08 16:28:45
Message-ID: 1168273726.3951.202.camel@silverbirch.site (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-admin
On Mon, 2007-01-08 at 09:41 -0600, Ben K. wrote:
> > On Fri, 2007-01-05 at 12:59 -0600, Ben K. wrote:
> >> 2. sql dump and PITR
> >> Is it possible to use the PITR method with SQL dump? (pg_start_backup ->
> >> sql dump -> pg_stop_backup) I guess not, but just want to make sure.
> >
> > No, because there is no reason or benefit.
> 
> Thanks. I guess the PITR plays on a different ground. This is just a 
> superficial question, but would it be possible to separate sql and disk 
> operations? Eventually, it would be nice if we can have something like 
> these as example. (I don't have any experience with this product.)
> 
> http://www.red-gate.com/products/SQL_Log_Rescue/
> 
> We sometimes have relatively minor but still painful problems (someone or 
> some scripts causes undesirable changes) and if we can go from the sql 
> dump (backup) and stop at a certain point, it would be really nice. It'd 
> also give us more granuality in controlling backup or test servers.

There is a log analysis tool on pgfoundry that does something similar.

You can already stop recovery at a certain point. So there's nothing to
stop you doing a recovery on a development machine up to a certain
point, then dumping the deleted data using pg_dump and re-loading it
into the live server. Then erasing the dev recovered database.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

Responses

pgsql-admin by date

Next:From: Chris HooverDate: 2007-01-08 16:41:30
Subject: 8.1.3 Crash/Corruption Problem
Previous:From: Ben K.Date: 2007-01-08 15:41:18
Subject: Re: PITR recovery

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group