Re: PITR recovery

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
delete/update

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.

Thanks.

Ben K.
Developer
http://benix.tamu.edu