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)
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 |