Update file system snapshot docs.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 01d023aae0df5cc4c346c754aca9f06f47eadc61..789e4a11e30bf9830e2e3dcd27a4160751d010d0 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
 
 
  Backup and Restore
@@ -364,9 +364,11 @@ tar -cf backup.tar /usr/local/pgsql/data
   
 
   
-   If your database is spread across multiple volumes (for example,
-   if you are using tablespaces) there may not be any way
-   to obtain exactly-simultaneous frozen snapshots of all the volumes.
+   If your database is spread across multiple file systems there may not 
+   be any way to obtain exactly-simultaneous frozen snapshots of all 
+   the volumes.  For example, if your data files and WAL log on different 
+   file disks, or if tablespaces are on different file systems, it might
+   not be possible to use snapshots because the snapshots must be simultaneous.
    Read your file system documentation very carefully before trusting
    to the consistent-snapshot technique in such situations.  The safest
    approach is to shut down the database server for long enough to
@@ -375,11 +377,12 @@ tar -cf backup.tar /usr/local/pgsql/data
 
   
    Another option is to use rsync to perform a file
-   system backup.  First, while the database server is running, 
-   run rsync, then shut down the database
-   server and perform a second rsync, then
-   restart the database server.  This allows a file system backup to be
-   performed with minimal downtime.
+   system backup.  This is done by first running rsync
+   while the database server is running, then shutting down the database
+   server just long enough to do a second rsync.  The
+   second rsync will be much quicker than the first,
+   but will be consistent because the server was down.  This method
+   allows a file system backup to be performed with minimal downtime.