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
