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.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
