Message-ID: <467BD44A.80803@commandprompt.com>
Date: Fri, 22 Jun 2007 06:53:14 -0700
From: "Joshua D. Drake" <jd@commandprompt.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: Toru SHIMOGAKI <shimogaki.toru@oss.ntt.co.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Dan Gorman <dgorman@hi5.com>,
	pgsql-performance@postgresql.org
Subject: Re: PITR Backups
References: <7E0807EE-B970-4869-A248-B838E42AD9EE@hi5.com>
	<9761.1182472005@sss.pgh.pa.us> <467B3459.9030808@oss.ntt.co.jp>
	<467B3DA6.4010005@commandprompt.com>
	<467B7D24.3040802@oss.ntt.co.jp>
In-Reply-To: <467B7D24.3040802@oss.ntt.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Toru SHIMOGAKI wrote:
> Joshua D. Drake wrote:
> 
>>> - If we don't use hardware level snapshot operation, it takes long time to take
>>>   a large backup data, and a lot of full-page-written WAL files are made.
>> Does it? I have done it with fairly large databases without issue.
> 
> You mean hardware snapshot?

Oh goodness no. :)

> I know taking a backup using rsync(or tar, cp?) as a
> n online backup method is not so a big problem as documented. But it just take a

I use rsync with pg_start/stop_backup and it works very well. Even on
databases that are TB in size.

> long time if we handle a terabyte database. We have to VACUUM and other batch
> processes  to the large database as well, so we don't want to take a long time
> to take a backup...

Ahh o.k. that makes sense. The difference here is probably how often we
take the snapshot. We take them very often to insure we don't have a ton
of logs we have to pull over.

Joshua D. Drake

> 
> Regards,
> 


-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/