Jim Nasby wrote:
On May 25, 2006, at 11:24 AM, Andreas Pflug wrote:
BTW, I don't actually understand why you want this at all. If you're
not going to keep a continuing series of WAL files, you don't have any
PITR capability. What you're proposing seems like a bulky, unportable,
hard-to-use equivalent of pg_dump. Why not use pg_dump?
Because pg_dump will take too long and create bloated dump files. All
I need is a physical backup for disaster recovery purposes without
bringing down the server.
In my case, I'd expect a DB that uses 114GB on disk to consume 1.4TB
when pg_dumped, too much for the available backup capacity (esp.
compared to net content, about 290GB). See other post "inefficient
bytea escaping" for details.
Another consideration is that you can use rsync to update a
filesystem-level backup, but there's no pg_dump equivalent. On a large
database that can make a sizable difference in the amount of time
required for a backup.
That's fine to cut the backup execution time, but to guarantee
consistency while the cluster is running pg_start_backup/pg_stop_backup
and WAL archiving will still be necessary.
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
