Re: Problem with PITR recovery

On Tue, 2005-04-19 at 15:23 +0400, Oleg Bartunov wrote:

> This is not an argument ! It's shame we still don't understand do we really
> have reliable online backup or just hype with a lot of restriction and
> caution. I'm not experienced Oracle DBA but I don't want to be a blind user.
> I read seminal papers about recovery and I thought I understand how
> it should works in our system. I want to be 110% sure to claim we're
> ready to recommend it to our clients. I'm sure there are many experienced
> DBA's who also don't understand what we have right now, especially after
> this thread.
>

Unless I misunderstand something, I think you're overreacting a bit. The
failure case is that the machine on which the database resides vaporizes
after you've done "pg_stop_backup()" but before the archiver archives
the WAL segments used during the backup procedure.

In practice, there are many reasons why that is not a major problem. For
example, PITR base backups are often going to be taken when the archiver
is already archiving WAL segments, and you already have a previous,
working bask backup. You'd still be able to use that old base backup and
the newly archived WAL segments.

In general, it's just not realistic that you take a machine from having
no backups of any kind to running mission-critical transactions and
depending solely on the PITR backup, and then watch the server vaporize,
all in less time than it takes to archive a few WAL segments.

In almost all cases, the loss in data would be comparable to the loss
experienced by not having the last few WAL segments shipped, and PITR
never made a promise of keeping the transactions that never got
archived.

PITR works, and the developers are:
(1) Improving the current docs to make it absolutely clear how to make
100% assured backups.
(2) Making PITR easier to administer, probably for 8.1.
(3) Adding features to PITR, probably for 8.1.

If what I said above is incorrect, please correct me, because that means
that I'm one of the lost DBAs that Oleg is talking about.

Regards,
Jeff Davis