Tom Lane wrote:
> "J. R. Nield" <jrnield@usol.com> writes:
> >> Uh, why? Why not just force a checkpoint and remember the exact
> >> location of the checkpoint within the current log file?
>
> > If I do a backup with PITR and save it to tape, I need to be able to
> > restore it even if my machine is destroyed in a fire, and all the logs
> > since the end of a backup are destroyed.
>
> And for your next trick, restore it even if the backup tape itself is
> destroyed. C'mon, be a little reasonable here. The backups and the
> log archive tapes are *both* critical data in any realistic view of
> the world.
Tom, just because he doesn't agree with you doesn't mean he is
unreasonable.
I think it is an admirable goal to allow the PITR backup to restore a
consistent copy of the database _without_ needing the logs. In fact, I
consider something that _needs_ the logs to restore to a consistent
state to be broken.
If you are doing offsite backup, which people should be doing, requiring
the log tape for restore means you have to recycle the log tape _after_
the PITR backup, and to restore to a point in the future, you need two
log tapes, one that was done during the backup, and another current.
If you can restore the PITR backup without a log tape, you can take just
the PITR backup tape off site _and_ you can recyle the log tape _before_
the PITR backup, meaning you only need one tape for a restore to a point
in the future. I think there are good reasons to have the PITR backp be
restorable on its own, if possible.
-- 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