> >> Q2: New situation: Why is it not a good idea to backup the database
> >> files of a cluster incl. all c_log and x_log (log files last) to get a
> >> "physicaly hot backup".
> >> In principle it is the same situation like a server which is crashing
> >> (not a once but during some time). After restoring, it should do a redo
> >> and rollback automatically like after a crash. This methode (physical
> >> hot backup) would increas backup and restore times dramatically.
>
> The answer from Robert Treat was:
>
> > Essentially I think you're right, it should behave much like a crashing
> > server. The main reason why people don't recommend it is that (depending on
> > your os setup) there is the potential to lose data that has been commited but
> > not actually written to disk. Note that you shouldn't get corrupted data
> > from this, but in many cases losing data is just as bad so we don't recomend
> > it. If you really want to do this, you should really either shut down the
> > database or get LVM going.
The key issue here is to have a pg_control file to start from with a
finished checkpoint from before you start to backup. Then you need to
ensure that you have all logfiles from checkpoint until backup finishes.
The last thing to backup must be the last active x_log.
It would prbbly be a good idea to not have a vacuum running concurrently :-)
And then you need to do a lot of tests, since nobody else does it yet.
I think this is an issue, since it is such high risk, nobody will
step up easily and say that it is safe.
Andreas