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

Re: PITR recovery

From: "Ben K(dot)" <bkim(at)coe(dot)tamu(dot)edu>
To: pgsql-admin(at)postgresql(dot)org
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: PITR recovery
Date: 2007-01-09 14:37:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
On Mon, 8 Jan 2007, Simon Riggs wrote:

> 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.

What I looked for was something like "undo" to a state which includes some 
changes from the last backup.

What is the best practice in the following case? I'd appreciate to know 
how this kind of situation is handled in general.

- We keep daily backups.
- In the middle of the day we find there are problems in some of the 
recent delete or update operations
- But we want to keep hours of other insert, delete or updates that preceded the problematic 

We can do hourly backup of the production server to minimize the recovery 
efforts, but it seems costly considering this situation is not frequent.

Since the logs contains what's been done, it appears it should be possible 
to go back in time - as PITR does - by relying only on sql dump and the 
statements in the log, with a controlled scope.

I guess it can possibly be done by replacing the basic operations like 
delete so that it inserts the deleted row into another database before 
deleting this row, etc.. Conceptually it seems simple though in 
generalizing it I guess there'll be problems like scalability and speed.


Ben K.

In response to


pgsql-admin by date

Next:From: Negandhi, NishithDate: 2007-01-09 15:22:49
Subject: Database Create Date
Previous:From: Ben K.Date: 2007-01-09 13:48:08
Subject: Re: PITR recovery

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