Peter Childs wrote:
> Hot backup? Postgres 7.3 can't really do hot-backup! The only way
> to backup the database is to dump the entire thing. Two minites later this
> backup is only news and not exactly hot. Having to shut your database down
> to back it up would be down right nasty! But Since we don't yet have an
> update log. Even a dump will not get you back to the good point before
> your disk died.
Isn't the definition of "hot-backup" the ability to perform a backup
while the database is still on-line engaging in transactions? I think
you're substituting "hot-backup" for point-in-time recovery...
> Mind you the truth is the downdate log should work for most cases.
> So take regualar backups... and use raid. I mean how often does an entire
> raid array fail at once?
True...and assuming you're not running just RAID 0. But, as you say,
PITR could recover from such nasty things as an unqualified DELETE or
UPDATE. Disaster recovery from PITR logs being archived over a WAN or
a replicated slave would also be nice, in the event hurricane "Foo"
wipes out the data center. I haven't played around with the
replication options yet, so that might be less of a problem. But
without PITR, there's a window of risk in which a programming error or
a keying error could set you back to the last backup, whenever that was...
> I would love to see an Update Log on postgres. That and true
> replications (dual master) are the two biggest missing features in
> Postgres. If we had them we could run circles round mysql and oracle as
> well.
Amen.
Mike Mascari
mascarm@mascari.com
