Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] [HACKERS] Online backup vs Continuous backup

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-docs(at)postgresql(dot)org, Rick Gigger <rick(at)alpinenetworking(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [PATCHES] [HACKERS] Online backup vs Continuous backup
Date: 2006-03-03 22:02:00
Message-ID: 200603032202.k23M20u11997@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackerspgsql-patches
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. +

In response to

pgsql-docs by date

Next:From: Mario GonzalezDate: 2006-03-04 21:43:31
Subject: Format Documents
Previous:From: Bruce MomjianDate: 2006-03-02 21:42:07
Subject: Re: vacuum and routine maintenance docs

pgsql-hackers by date

Next:From: Jim C. NasbyDate: 2006-03-03 22:16:39
Subject: Re: Vertical Partitioning with TOAST
Previous:From: Andreas SeltenreichDate: 2006-03-03 21:53:07
Subject: Re: PG Extensions: Must be statically linked?

pgsql-patches by date

Next:From: Bruce MomjianDate: 2006-03-03 23:11:55
Subject: Re: Native-win32 patch
Previous:From: Bruce MomjianDate: 2006-03-03 21:52:48
Subject: Re: [HACKERS] ipcclean in 8.1 broken?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group