Re: PITR Backups - Mailing list pgsql-performance

From Simon Riggs
Subject Re: PITR Backups
Date
Msg-id 1182534358.9276.326.camel@silverbirch.site
Whole thread Raw
In response to Re: PITR Backups  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PITR Backups  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote:
> Dan Gorman <dgorman@hi5.com> writes:
> > This snapshot is done at the LUN (filer) level, postgres is un-aware
> > we're creating a backup, so I'm not sure how pg_start_backup() plays
> > into this ...
>
> That method works too, as long as you snapshot both the data files and
> WAL files --- when you start PG from the backup, it will think it
> crashed and recover by replaying WAL.  So, assuming that the snapshot
> technology really works, it should be exactly as reliable as crash
> recovery is.

> If you saw a problem I'd be inclined to question whether
> there is some upstream component (OS or disk controller) that's
> reordering writes.

Given thats exactly what they do, constantly, I don't think its safe to
say that it works since we cannot verify whether that has happened or
not.

At the very least, you should issue a CHECKPOINT prior to taking the
snapshot, to ensure that the write barriers have gone through.

But that being said, I'm not quite sure why following the Continuous
Archiving procedures is a problem, since they don't add any significant
overhead, over and above the checkpoint command.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: PITR Backups
Next
From: Tom Lane
Date:
Subject: Re: PITR Backups