From: Kern Sibbald <kern@sibbald.com>
Date: Tue, 16 Jun 2009 12:42:04 +0000 (+0000)
Subject: Update VirtualFull doc + BSys course dates
X-Git-Tag: Release-3.0.2~163
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=9ab75157d9a8240cba1306da0e8fea4965c059d4;p=bacula%2Fdocs

Update VirtualFull doc + BSys course dates
---

diff --git a/docs/home-page/en/pages/home.php b/docs/home-page/en/pages/home.php
index 1befacef..0443b122 100644
--- a/docs/home-page/en/pages/home.php
+++ b/docs/home-page/en/pages/home.php
@@ -106,6 +106,7 @@
     <tr height="68">
      <td height="68">
       <p>3 May 2009: <strong>Bacula Enterprise Edition 1.0</strong> will be released shortly.</p>
+      <p>10 June 2009: <strong>Foundation Training Course: <a href="http://www.baculasystems.com/eng/About-us/Recent-news/Foundation-Course-Dates-Announced">dates announced</a><p>
       <p>See: <a href="http://www.baculasystems.com/eng/About-us/Recent-news">Bacula Systems News</a>
 <!--
 , 
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}.