Re: Hot Backup

On Tue, 2002-10-08 at 08:58, Shridhar Daithankar wrote:
> On 8 Oct 2002 at 14:17, Erwan DUROSELLE wrote:
> > MvO> http://www.postgresql.org/idocs/index.php?wal.html
> > - The URL you refer to is the ch11 I was refering to. It seems that this chapter is not as easily understandable as it should...
> > It says that with WAL, "pg is able to garantee consistency in the case of a crash".
> > OK, but I think is about /consistency/.
> > For what I understand, it just says that in the case of a core dump of a server process (improbable) or a power cut (probable) or an unwanted kill -9 (may happen), Pg will not have any corrupted table or index.
> >
> > Cool, but not enough.
> >
> > As Timur pointed out, I was refering to a disk crash or total loss of a server.
> > In this case, you loose up to 1 day of data.

Is it me or do doomsdays scenarios sometimes seem a little silly? I'd
like to ask just where are you storing your "incremental backups" with
Oracle/m$ sql ?? If it's on the same drive, then when you drive craps
out you've lost the incremental backups as well. Are you putting them
on a different drive (you can do that with the WAL) you'd still have the
problem that if the building went up in smoke you'd lose that
incremental backup. Unless you are doing "incremental backups" to a
computer in another physical location, you still fail all of your
scenarios.

> > > There is a need in "incremental" backup, which backs up only those
> > > transactions which has been fulfilled after last "full dump" or last
> > > "incremental dump". These backups should be done quite painlessly -
> > > just copy some part of WAL, and should be small enough (compared to
> > > full dump), so they can be done each hour or even more frequently..
> > >
> > > I hope sometime PostgreSQL will support that. :-)
>
> Well, there are replication solutions which rsyncs WAL files after they are
> rotated so two database instances are upto sync with each other at a difference
> of one WAL file. If you are interested I can post the pdf.
>
> I guess that takes care of scenario you plan to avoid..
>

This type of scenario sounds as good as the above mentioned methods for
oracle/m$ server. Could you post your pdf? Seems like it might be worth
adding to the techdocs site.

Robert Treat