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. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
