\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
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}.
projects / bacula / docs / commitdiff