X-Git-Url: https://git.sur5r.net/?p=bacula%2Fdocs;a=blobdiff_plain;f=docs%2Fmanuals%2Fen%2Fconcepts%2Fnewfeatures.tex;h=27f009aebf0f90efba560dd799f9cd124329434a;hp=36f67ba39eaea9d618c08ca7e9edc3630c62e13e;hb=9ab75157d9a8240cba1306da0e8fea4965c059d4;hpb=64b1875cb5b017790a96b2e7801f7cef1c0c8809

diff --git a/docs/manuals/en/concepts/newfeatures.tex b/docs/manuals/en/concepts/newfeatures.tex
index 36f67ba3..27f009ae 100644
--- a/docs/manuals/en/concepts/newfeatures.tex
+++ b/docs/manuals/en/concepts/newfeatures.tex
@@ -404,11 +404,13 @@ also add --disable-libtool.  Example
 \index[general]{Vbackup}
 
 Bacula's virtual backup feature is often called Synthetic Backup or
-Consolidation in other backup products.  It permits you to consolidate
-the previous Full backup plus the most recent Differential backup and any
-subsequent Incremental backups into a new Full backup. This is accomplished
-without contacting the client by reading the previous backup data and 
-writing it to a volume in a different pool.  
+Consolidation in other backup products.  It permits you to consolidate the
+previous Full backup plus the most recent Differential backup and any
+subsequent Incremental backups into a new Full backup.  This new Full
+backup will then be considered as the most recent Full for any future
+Incremental or Differential backups.  The VirtualFull backup is
+accomplished without contacting the client by reading the previous backup
+data and writing it to a volume in a different pool.
 
 In some respects the Vbackup feature works similar to a Migration job, in
 that Bacula normally reads the data from the pool specified in the 
@@ -421,10 +423,11 @@ daemon. If you then want to do subsequent backups, you may need to
 move the Virtual Full Volume back to your normal backup pool.
 Alternatively, you can set your {\bf Next Pool} to point to the current
 pool.  This will cause Bacula to read and write to Volumes in the
-current pool. In general, this will work, but doing the Virtual Full
-requires reading more than one Volume, this procedure may cause a 
-deadlock where Bacula is writing on a Volume that is later needed 
-for reading.
+current pool. In general, this will work, because Bacula will
+not allow reading and writing on the same Volume. In any case, once
+a VirtualFull has been created, and a restore is done involving the
+most current Full, it will read the Volume or Volumes by the VirtualFull 
+regardless of in which Pool the Volume is found.
 
 The Vbackup is enabled on a Job by Job in the Job resource by specifying
 a level of {\bf VirtualFull}.