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. +
