Remove docs for "Incrementally Updated Backups" because it was of

questionable reliability;  information moved to a wiki:

	http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups

Backpatch to 9.0.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6d45f661a5b187c95a76cada9dda244f88fa09ab..3674dd319f09f7fe6e10b205a06ae3303c75d74d 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -1890,95 +1890,4 @@ LOG:  database system is ready to accept read only connections
 
  
 
-  
-   Incrementally Updated Backups
-
-  
-   incrementally updated backups
-  
-
-  
-   change accumulation
-  
-
-   
-    In a standby configuration, it is possible to offload the expense of
-    taking periodic base backups from the primary server; instead base backups
-    can be made by backing
-    up a standby server's files.  This concept is generally known as
-    incrementally updated backups, log change accumulation, or more simply,
-    change accumulation.
-   
-
-   
-    If we take a file system backup of the standby server's data
-    directory while it is processing
-    logs shipped from the primary, we will be able to reload that backup and
-    restart the standby's recovery process from the last restart point.
-    We no longer need to keep WAL files from before the standby's restart point.
-    If recovery is needed, it will be faster to recover from the incrementally
-    updated backup than from the original base backup.
-   
-
-   
-    The procedure for taking a file system backup of the standby server's
-    data directory while it's processing logs shipped from the primary is:
-   
-    
-     
-      Perform the backup, without using pg_start_backup and
-      pg_stop_backup. Note that the pg_control
-      file must be backed up first, as in:
-
-cp /var/lib/pgsql/data/global/pg_control /tmp
-cp -r /var/lib/pgsql/data /path/to/backup
-mv /tmp/pg_control /path/to/backup/data/global
-
-      pg_control contains the location where WAL replay will
-      begin after restoring from the backup; backing it up first ensures
-      that it points to the last restartpoint when the backup started, not
-      some later restartpoint that happened while files were copied to the
-      backup.
-     
-    
-    
-     
-      Make note of the backup ending WAL location by calling the 
-      pg_last_xlog_replay_location function at the end of the backup,
-      and keep it with the backup.
-
-psql -c "select pg_last_xlog_replay_location();" > /path/to/backup/end_location
-
-      When recovering from the incrementally updated backup, the server
-      can begin accepting connections and complete the recovery successfully
-      before the database has become consistent. To avoid that, you must
-      ensure the database is consistent before users try to connect to the
-      server and when the recovery ends. You can do that by comparing the
-      progress of the recovery with the stored backup ending WAL location:
-      the server is not consistent until recovery has reached the backup end
-      location. The progress of the recovery can also be observed with the
-      pg_last_xlog_replay_location function, though that requires
-      connecting to the server while it might not be consistent yet, so
-      care should be taken with that method.
-     
-     
-     
-    
-   
-   
-
-   
-    Since the standby server is not live, it is not possible to
-    use pg_start_backup() and pg_stop_backup()
-    to manage the backup process; it will be up to you to determine how
-    far back you need to keep WAL segment files to have a recoverable
-    backup. That is determined by the last restartpoint when the backup
-    was taken, any WAL older than that can be deleted from the archive
-    once the backup is complete. You can determine the last restartpoint
-    by running pg_controldata on the standby server before
-    taking the backup, or by using the log_checkpoints option
-    to print values to the standby's server log.
-   
-  
-