From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Jim Nasby <jnasby(at)pervasive(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XLogArchivingActive |
Date: | 2006-05-25 22:15:34 |
Message-ID: | 44762C86.6050106@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-05-25 22:16:14 | Re: XLogArchivingActive |
Previous Message | Josh Berkus | 2006-05-25 21:54:38 | Re: Gborg and pgfoundry |