From: | Jim Nasby <jnasby(at)pervasive(dot)com> |
---|---|
To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XLogArchivingActive |
Date: | 2006-05-25 21:53:56 |
Message-ID: | F6309784-C614-4730-B045-B7BD40EC1E56@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2006-05-25 21:54:38 | Re: Gborg and pgfoundry |
Previous Message | Marc G. Fournier | 2006-05-25 20:59:05 | Re: Gborg and pgfoundry |