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 jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461