Does this provide true "point of failure" recovery? This sounds like no
more than a cold backup,
which does not provide "point of failure" recovery. I think the original
question is very valid. Postgres
does not, to my knowledge, support transaction logging, which is necessary
for this style of recovery.
In Oracle, you restore the data files from a previous backup and then
re-apply the transaction (archive)
logs, a process called "rolling forward", then you can open the database
for use, and it is in the state
just prior to the failure. I've seen some creative dialogue on this list
about writing to multiple database
instances to have a live backup, and some regarding logging each SQL
statement, but the introduction
of a transaction archiver into the engine itself would make this process
much easier and make Postgres
more attractive to sites currently using the major commercial database
packages, IMHO.
Let me know if any of this is blatantly incorrect.
Tim White
Ragnar Kjørstad wrote:
> On Wed, Jan 10, 2001 at 05:57:21AM -0600, D Johnson wrote:
> > Will the postgres community ever consider creating a decent backup
> > capability. Currently the way to create backups is through a Cron job.
> > For Postgres to ever be considered a true production systen then some
> > sort of transactional tracing has to be done. Otherwise you risk the
> > potential of losing quite a bit of data.
>
> You can take a snapshot of the database-device (while the database is
> down), and backup from the snapshot to avoid this problem.
>
> You need a volum-manager that support snapshot, but AFAIK most do.
>
> --
> Ragnar Kjørstad
> BigStorage
