Improve discussion of consistent-snapshot backup technique. Haphazard

editing of this text had left nearly contradictory statements in
adjacent paragraphs ...

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index e6ac6d27846224b3416e829b0f331c7a7ded395e..864fb37f982b89cafc7101271820297fa1320afc 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
 
 
  Backup and Restore
@@ -331,9 +331,7 @@ tar -cf backup.tar /usr/local/pgsql/data
       The database server must be shut down in order to
       get a usable backup. Half-way measures such as disallowing all
       connections will not work as there is always some buffering
-      going on. For this reason it is also not advisable to trust file
-      systems that claim to support consistent
-      snapshots. Information about stopping the server can be
+      going on. Information about stopping the server can be
       found in .  Needless to say
       that you also need to shut down the server before restoring the
       data.
@@ -342,8 +340,8 @@ tar -cf backup.tar /usr/local/pgsql/data
 
     
      
-      If you have dug into the details of the file system layout of the data you
-      may be tempted to try to back up or restore only certain
+      If you have dug into the details of the file system layout of the
+      database, you may be tempted to try to back up or restore only certain
       individual tables or databases from their respective files or
       directories. This will not work because the
       information contained in these files contains only half the
@@ -362,16 +360,30 @@ tar -cf backup.tar /usr/local/pgsql/data
   
    An alternative file-system backup approach is to make a
    consistent snapshot of the data directory, if the
-   file system supports that functionality.  Such a snapshot will save
+   file system supports that functionality (and you are willing to
+   trust that it is implemented correctly).  The typical procedure is
+   to make a frozen snapshot of the volume containing the
+   database, then copy the whole data directory (not just parts, see
+   above) from the snapshot to a backup device, then release the frozen
+   snapshot.  This will work even while the database server is running.
+   However, a backup created in this way saves
    the database files in a state where the database server was not
    properly shut down; therefore, when you start the database server
-   on this backed up directory, it will think the server had crashed
+   on the backed-up data, it will think the server had crashed
    and replay the WAL log.  This is not a problem, just be aware of
    it.
   
 
   
-   Note that the file system backup will not necessarily be
+   If your database is spread across multiple volumes (for example,
+   data files and WAL log on different disks) there may not be any way
+   to obtain exactly-simultaneous frozen snapshots of all the volumes.
+   Read your filesystem documentation very carefully before trusting
+   to the consistent-snapshot technique in such situations.
+  
+
+  
+   Note that a file system backup will not necessarily be
    smaller than an SQL dump. On the contrary, it will most likely be
    larger. (pg_dump does not need to dump
    the contents of indexes for example, just the commands to recreate