From: Tom Lane <tgl@sss.pgh.pa.us>
To: Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Toru SHIMOGAKI <shimogaki.toru@oss.ntt.co.jp>
Cc: Dan Gorman <dgorman@hi5.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: PITR Backups
Date: Mon, 25 Jun 2007 10:31:49 -0400
Message-ID: <28289.1182781909@sss.pgh.pa.us> (raw)
In-Reply-To: <467F938F.1030708@oss.ntt.co.jp>
References: <7E0807EE-B970-4869-A248-B838E42AD9EE@hi5.com>
<9761.1182472005@sss.pgh.pa.us>
<467B3459.9030808@oss.ntt.co.jp>
<1182509748.9276.178.camel@silverbirch.site>
<467F938F.1030708@oss.ntt.co.jp>
Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp> writes:
> Year, I agree we should carefully follow how Done really did a backup.
> My point is PostgreSQL may have to extend the file during the hot backup
> to write to the new block. It is slightly different from Oracle's case.
> Oracle allocates all the database space in advance so that there could
> be no risk to modify the metadata on the fly. In our case, because SAN
> based storage snapshot is device level, not file system level, even a
> file system does not know that the snapshot is being taken and we might
> encounter the case where metadata and/or user data are not consistent.
> Such snapshot (whole filesystem) might be corrupted and cause file
> system level error.
Surely a hot-backup technique that cannot even produce a consistent
state of filesystem metadata is too broken to be considered a backup
technique at all.
AFAIK, actually workable methods of this type depend on filesystem
cooperation, and are able to produce coherent snapshots of the logical
(not necessarily physical) filesystem content at a specific instant.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, suzuki.koichi@oss.ntt.co.jp, simon@2ndquadrant.com, shimogaki.toru@oss.ntt.co.jp, dgorman@hi5.com
Subject: Re: PITR Backups
In-Reply-To: <28289.1182781909@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox