Message-ID: <467B7A89.3080300@oss.ntt.co.jp>
Date: Fri, 22 Jun 2007 16:30:17 +0900
From: Toru SHIMOGAKI <shimogaki.toru@oss.ntt.co.jp>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Steve Atkins <steve@blighty.com>
CC: PostgreSQL Performance <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>
	<B4AE85C4-8E1C-4EF6-B8A4-7B66C26238EA@blighty.com>
In-Reply-To: <B4AE85C4-8E1C-4EF6-B8A4-7B66C26238EA@blighty.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Steve Atkins wrote:

>> - When we take a PITR base backup with hardware level snapshot operation
>>   (not filesystem level) which a lot of storage vender provide, the 
>> backup data
>>   can be corrupted as Dan said. During recovery we can't even read it,
>>   especially if meta-data was corrupted.
> 
> I can't see any explanation for how this could happen, other
> than your hardware vendor is lying about snapshot ability.

All of the hardware vendors I asked always said:

  "The hardware level snapshot has nothing to do with filesystem condition and 
of course with what data has been written from operating system chache to the 
hard disk platter. It just copies byte data on storage to the other volume.

So, if any data is written during taking snapshot, we can't assurance data 
correctness *strictly* .

In Oracle, no table data is written between BEGIN BACKUP and END BACKUP, and it 
is not a problem REDO is written..."

I'd like to know the correct information if the explanation has any mistakes, or 
a good way to avoid the probrem.

I think there are users who want to migrate Oracle to PostgreSQL but can't 
because of the problem as above.


Best regards,

-- 
Toru SHIMOGAKI<shimogaki.toru@oss.ntt.co.jp>
NTT Open Source Software Center