Rename Online Backup to Continuous Archiving.
authorBruce Momjian
Fri, 3 Mar 2006 22:02:08 +0000 (22:02 +0000)
committerBruce Momjian
Fri, 3 Mar 2006 22:02:08 +0000 (22:02 +0000)
doc/src/sgml/backup.sgml
doc/src/sgml/config.sgml
doc/src/sgml/func.sgml
doc/src/sgml/wal.sgml

index 9245c6278b6a609e81f49a037e7ade2721730321..6ee26bb9d2b3fad7039fc55be7ce83e6bc21727a 100644 (file)
@@ -1,5 +1,5 @@
 
 
  Backup and Restore
@@ -19,7 +19,7 @@ $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.77 2006/02/24 14:03:01 momjian E
   
    SQL dump
    File system level backup
-   On-line backup
+   Continuous Archiving
   
   Each has its own strengths and weaknesses.
  
@@ -372,11 +372,11 @@ tar -cf backup.tar /usr/local/pgsql/data
   
  
 
backup-online">
-  <span class="marked">On-line backup and point-in-time r</span>ecovery (PITR)
continuous-archiving">
+  <span class="marked">Continuous Archiving and Point-In-Time R</span>ecovery (PITR)
 
   
-   on-line backup
+   continuous archiving
   
 
   
@@ -452,7 +452,8 @@ tar -cf backup.tar /usr/local/pgsql/data
   
 
   
-   To recover successfully using an on-line backup, you need a continuous
+   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 before you take your
@@ -783,12 +784,12 @@ SELECT pg_stop_backup();
     pg_start_backup or 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.
+    It is generally better to follow the continuous archiving procedure above.
    
   
 
   
-   Recovering <span class="marked">with an On-lin</span>e Backup
+   Recovering <span class="marked">using a Continuous Archiv</span>e Backup
 
    
     Okay, the worst has happened and you need to recover from your backup.
@@ -1120,11 +1121,11 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"'  # Windows
    
   
 
-  backup-online-caveats">
+  continuous-archiving-caveats">
    Caveats
 
    
-    At this writing, there are several limitations of the on-line backup
+    At this writing, there are several limitations of the continuous archiving
     technique.  These will probably be fixed in future releases:
 
   
index dd64ffe3db235049d45ba76dc725388cd961d0b7..710f1b93d16d3bf66005182fc140154532857844 100644 (file)
@@ -1,5 +1,5 @@
 
 
   Server Configuration
@@ -1387,7 +1387,7 @@ SET ENABLE_SEQSCAN TO OFF;
        
         Turning off this parameter does not affect use of
         WAL archiving for point-in-time recovery (PITR)
-        (see backup-online">).
+        (see continuous-archiving">).
        
 
        
index 8f0975af703b5d8ee27a87de7dd10d6827d1192f..7d18f9760212a016a098c821ed529528d7b1ea47 100644 (file)
@@ -1,5 +1,5 @@
 
 
@@ -9808,7 +9808,7 @@ SELECT set_config('log_statement_stats', 'off', false);
 
    
     For details about proper usage of these functions, see
-    backup-online">.
+    continuous-archiving">.
    
 
    
index 576b63e0d2faf01d1ea06072a9b48c637adbab75..601a316cdc99439304fa6a59c322adc1a3e8fdfa 100644 (file)
@@ -1,4 +1,4 @@
-
+
 
 
  Reliability and the Write-Ahead Log
    
     WAL also makes it possible to support on-line
     backup and point-in-time recovery, as described in 
-    linkend="backup-online">.  By archiving the WAL data we can support
+    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,