[EMAIL PROTECTED] wrote:
Checkpoinitng is definitely coolest. If your file system doesn't do that, rsync is a good poor man's replacement:first rsync (takes long) (or work from an older backup) pg_start_backup(...) rsync (should be much faster) rsync WAL pg_stop_backup() I regularly rsync moderately active 500GB filesystems on fairly feeble hardware in about 5-10 minutes (for daily backups).
That will *not* get you a consistent, safe backup. If a PostgreSQL checkpoint happens while you're rsyncing the WAL, the data files won't (necessarily) contain updates that were made between the rsync of the data finished and the checkpoint.
To do that, you'd need to set up continuous archiving, and do a PITR restore.
What I was complaining/suggesting is that we should make what you did to actually work, because it's a lot simpler. And as Jonah pointed out, we'd need to inhibit checkpoints between pg_start_backup() and pg_stop_backup() to make it work.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
