Andy Hilker wrote: >>Simon's point is a good one. One needs to be careful though about >>replicating full-circle a hopelessly corrupted or dropped InnoDB. (A recent >>tarball is good to have) > > Replication is not a full backup. If you trash the database and > replicate the trash without a time shift, you have double trash and > no backup. On the other hand you can use database replication for > some kind of load balancing and real time failover. > >>To achieve the backup on a replicating slave what I do at a number of >>locations is: > > [...] > > Ok, this combines both solutions ;-) > But if you only want a backup and don't have two database servers, > snapshots with ufs2 are a dream solution :)
There is a better way for Postgres 8 user: use a dump (pg_dumpall) and online backups with the PITR feature. The online backup feature simply keeps the WAL files so it's for free (counting cpu cycles/RAM). That way you get frequent backups (for <100 user I get a new WAL file every ~45 minutes) without the risk of replication. If you drop tables by accident only replay the WALs that were archived before the accident. Advantages: on hardware failure I loose on average only ~23 minutes, the huge snapshots (discs or pg_dumpall) can be done less frequent Thomas
