X-Original-To: pgsql-docs-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by postgresql.org (Postfix) with ESMTP id 50EEE9DC9C8;
	Fri,  3 Mar 2006 18:02:07 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 62432-09; Fri,  3 Mar 2006 18:02:08 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from candle.pha.pa.us (candle.pha.pa.us [70.90.9.53])
	by postgresql.org (Postfix) with ESMTP id 6C1479DC83F;
	Fri,  3 Mar 2006 18:02:04 -0400 (AST)
Received: (from pgman@localhost)
	by candle.pha.pa.us (8.11.6/8.11.6) id k23M20u11997;
	Fri, 3 Mar 2006 17:02:00 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200603032202.k23M20u11997@candle.pha.pa.us>
Subject: Re: [PATCHES] [HACKERS] Online backup vs Continuous backup
In-Reply-To: <200603021916.k22JGNB17498@candle.pha.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Fri, 3 Mar 2006 17:02:00 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, pgsql-docs@postgresql.org,
	Rick Gigger <rick@alpinenetworking.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL-patches <pgsql-patches@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL121 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, score=0.431 required=5 tests=[AWL=-0.069, RAZOR2_CHECK=0.5]
X-Spam-Score: 0.431
X-Spam-Level: 
X-Archive-Number: 200603/6
X-Sequence-Number: 3463


Applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > I used your suggestion and renamed "online backup" to "incremental
> > > backup", and added a mention that many database vendors call it
> > > "online backup".
> > 
> > Consistency would then demand that the other two be renamed to "full 
> > backup".  I think we had better suggestions earlier.
> 
> I am also now thinking the word "incremental" is wrong because it
> implies something that happens in parts, like "backup everything that
> changed from last night until now" which not how this feature works.
> 
> I am thinking "Continuous Archiving" is the proper wording, and it
> avoids the "backup" word.
> 
> Updated patch attached.
> 
> -- 
>   Bruce Momjian   http://candle.pha.pa.us
>   SRA OSS, Inc.   http://www.sraoss.com
> 
>   + If your life is a hard drive, Christ can be your backup. +

> Index: doc/src/sgml/backup.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v
> retrieving revision 2.76
> diff -c -c -r2.76 backup.sgml
> *** doc/src/sgml/backup.sgml	7 Nov 2005 17:36:44 -0000	2.76
> --- doc/src/sgml/backup.sgml	14 Feb 2006 04:00:50 -0000
> ***************
> *** 19,25 ****
>     <itemizedlist>
>      <listitem><para><acronym>SQL</> dump</para></listitem>
>      <listitem><para>File system level backup</para></listitem>
> !    <listitem><para>On-line backup</para></listitem>
>     </itemizedlist>
>     Each has its own strengths and weaknesses.
>    </para>
> --- 19,25 ----
>     <itemizedlist>
>      <listitem><para><acronym>SQL</> dump</para></listitem>
>      <listitem><para>File system level backup</para></listitem>
> !    <listitem><para>Continuous Archiving</para></listitem>
>     </itemizedlist>
>     Each has its own strengths and weaknesses.
>    </para>
> ***************
> *** 372,382 ****
>     </para>
>    </sect1>
>   
> !  <sect1 id="backup-online">
> !   <title>On-line backup and point-in-time recovery (PITR)</title>
>   
>     <indexterm zone="backup">
> !    <primary>on-line backup</primary>
>     </indexterm>
>   
>     <indexterm zone="backup">
> --- 372,382 ----
>     </para>
>    </sect1>
>   
> !  <sect1 id="continuous-archiving">
> !   <title>Continuous Archiving and Point-In-Time Recovery (PITR)</title>
>   
>     <indexterm zone="backup">
> !    <primary>continuous archiving</primary>
>     </indexterm>
>   
>     <indexterm zone="backup">
> ***************
> *** 452,458 ****
>     </para>
>   
>     <para>
> !    To recover successfully using an on-line backup, you need a continuous
>      sequence of archived WAL files that extends back at least as far as the
>      start time of your backup.  So to get started, you should set up and test
>      your procedure for archiving WAL files <emphasis>before</> you take your
> --- 452,459 ----
>     </para>
>   
>     <para>
> !    To recover successfully using continuous archiving (also called "online
> !    backup" by many database vendors), you need a continuous
>      sequence of archived WAL files that extends back at least as far as the
>      start time of your backup.  So to get started, you should set up and test
>      your procedure for archiving WAL files <emphasis>before</> you take your
> ***************
> *** 782,793 ****
>       <function>pg_start_backup</> or <function>pg_stop_backup</>, and
>       you will therefore be left to your own devices to keep track of which
>       backup dump is which and how far back the associated WAL files go.
> !     It is generally better to follow the on-line backup procedure above.
>      </para>
>     </sect2>
>   
>     <sect2 id="backup-pitr-recovery">
> !    <title>Recovering with an On-line Backup</title>
>   
>      <para>
>       Okay, the worst has happened and you need to recover from your backup.
> --- 783,794 ----
>       <function>pg_start_backup</> or <function>pg_stop_backup</>, and
>       you will therefore be left to your own devices to keep track of which
>       backup dump is which and how far back the associated WAL files go.
> !     It is generally better to follow the continuous archiving procedure above.
>      </para>
>     </sect2>
>   
>     <sect2 id="backup-pitr-recovery">
> !    <title>Recovering using a Continuous Archive Backup</title>
>   
>      <para>
>       Okay, the worst has happened and you need to recover from your backup.
> ***************
> *** 1119,1129 ****
>      </para>
>     </sect2>
>   
> !   <sect2 id="backup-online-caveats">
>      <title>Caveats</title>
>   
>      <para>
> !     At this writing, there are several limitations of the on-line backup
>       technique.  These will probably be fixed in future releases:
>   
>     <itemizedlist>
> --- 1120,1130 ----
>      </para>
>     </sect2>
>   
> !   <sect2 id="continuous-archiving-caveats">
>      <title>Caveats</title>
>   
>      <para>
> !     At this writing, there are several limitations of the continuous archiving
>       technique.  These will probably be fixed in future releases:
>   
>     <itemizedlist>
> Index: doc/src/sgml/config.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v
> retrieving revision 1.47
> diff -c -c -r1.47 config.sgml
> *** doc/src/sgml/config.sgml	5 Feb 2006 18:19:14 -0000	1.47
> --- doc/src/sgml/config.sgml	14 Feb 2006 04:00:53 -0000
> ***************
> *** 1387,1393 ****
>          <para>
>           Turning off this parameter does not affect use of
>           WAL archiving for point-in-time recovery (PITR)
> !         (see <xref linkend="backup-online">).
>          </para>
>   
>          <para>
> --- 1387,1393 ----
>          <para>
>           Turning off this parameter does not affect use of
>           WAL archiving for point-in-time recovery (PITR)
> !         (see <xref linkend="continuous-archiving">).
>          </para>
>   
>          <para>
> Index: doc/src/sgml/func.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/func.sgml,v
> retrieving revision 1.306
> diff -c -c -r1.306 func.sgml
> *** doc/src/sgml/func.sgml	12 Feb 2006 04:44:15 -0000	1.306
> --- doc/src/sgml/func.sgml	14 Feb 2006 04:00:59 -0000
> ***************
> *** 9784,9790 ****
>   
>      <para>
>       For details about proper usage of these functions, see
> !     <xref linkend="backup-online">.
>      </para>
>   
>      <para>
> --- 9784,9790 ----
>   
>      <para>
>       For details about proper usage of these functions, see
> !     <xref linkend="continuous-archiving">.
>      </para>
>   
>      <para>
> Index: doc/src/sgml/wal.sgml
> ===================================================================
> RCS file: /cvsroot/pgsql/doc/src/sgml/wal.sgml,v
> retrieving revision 1.38
> diff -c -c -r1.38 wal.sgml
> *** doc/src/sgml/wal.sgml	4 Nov 2005 23:14:02 -0000	1.38
> --- doc/src/sgml/wal.sgml	14 Feb 2006 04:01:00 -0000
> ***************
> *** 136,142 ****
>      <para>
>       <acronym>WAL</acronym> also makes it possible to support on-line
>       backup and point-in-time recovery, as described in <xref
> !     linkend="backup-online">.  By archiving the WAL data we can support
>       reverting to any time instant covered by the available WAL data:
>       we simply install a prior physical backup of the database, and
>       replay the WAL log just as far as the desired time.  What's more,
> --- 136,142 ----
>      <para>
>       <acronym>WAL</acronym> also makes it possible to support on-line
>       backup and point-in-time recovery, as described in <xref
> !     linkend="continuous-archiving">.  By archiving the WAL data we can support
>       reverting to any time instant covered by the available WAL data:
>       we simply install a prior physical backup of the database, and
>       replay the WAL log just as far as the desired time.  What's more,

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
> 
>                http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +