Jeff Davis wrote:
> 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.
You are right. The problem we really had was that the documentation
didn't mention the restrictions, and it said you could remove the old
archived WAL files once you did pg_stop_backup(). That has been
corrected and the new documentation will be in 8.0.3. I will mention
the PITR documentation clarification in the release notes for 8.0.3.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
