Re: Seeking datacenter PITR backup procedures [RESENDING]

From: Decibel! <decibel(at)decibel(dot)org>
To: Bill Moran <wmoran(at)potentialtech(dot)com>
Cc: "Joey K(dot)" <pguser(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Seeking datacenter PITR backup procedures [RESENDING]
Date: 2007-08-23 19:07:15
Message-ID: 647C68AD-0179-44DC-88EC-4954A9599F9D@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Aug 19, 2007, at 7:23 AM, Bill Moran wrote:
>> Assumptions:
>> a. After pg_stop_backup(), Pg immediately recycles log files and
>> hence wal
>> logs can be copied to backup. This is a clean start.
>
> I don't believe so. ARAIK, all pg_stop_backup() does is remove the
> marker that pg_start_backup() put in place to tell the recovery
> process
> when the filesystem backup started.

I'm pretty certain that's not the case. For a PITR to ensure that
data is back to a consistent state after a recovery, it has to replay
all the transactions that took place between pg_start_backup and
pg_stop_backup; so it needs to know when pg_stop_backup() was
actually run.

> By not backing up pg_xlog, you are
> going to be behind by however many transactions are in the most recent
> transaction log that has not yet been archived. Depending on how
> often
> your databases are updated, this is likely acceptable. If you need
> anything more timely than that, you'll probably want to implement
> Slony or some other replication system.

Just keep in mind that Slony is *not* a backup solution (though you
could possibly argue that it's log shipping is).
--
Decibel!, aka Jim Nasby decibel(at)decibel(dot)org
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Decibel! 2007-08-23 19:11:48 Re: Searching for Duplicates and Hosed the System
Previous Message Max Zorloff 2007-08-23 19:02:54 Re: Apache + PHP + Postgres Interaction