Add virtualfull documentation

Was only in newfeature section

diff --git a/docs/manuals/en/main/dirdconf.tex b/docs/manuals/en/main/dirdconf.tex
index db35de29357385639c8123086e072de67d0f132c..530b86a884b582a71093775326da24d37e5555e3 100644 (file)
--- a/docs/manuals/en/main/dirdconf.tex
+++ b/docs/manuals/en/main/dirdconf.tex
@@ -696,6 +696,20 @@ For a {\bf Backup} Job, the Level may be one of the  following:
    all the volumes on which the preceding Incremental and Differential
    backups since the last Full are done.
 
+\item [VirtualFull]
+   \index[dir]{VirtualFull}
+
+   When the Level is set to VirtualFull, 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.
+
+   Bacula's virtual backup feature is often called Synthetic Backup or
+   Consolidation in other backup products.
+
 \end{description}
 
 For a {\bf Restore} Job, no level needs to be specified.

diff --git a/docs/manuals/en/main/migration.tex b/docs/manuals/en/main/migration.tex
index b30564155f55d7984837475de15511031a65f245..71f60e608e40591cb95a97e9dbfa9016a29dd280 100644 (file)
--- a/docs/manuals/en/main/migration.tex
+++ b/docs/manuals/en/main/migration.tex
@@ -489,3 +489,120 @@ Job {
 
 All jobs ending with the name Save will be migrated from the File Default to
 the Tape Pool, or from File storage to Tape storage.
+
+\section{Virtual Backup Consolidation}
+\label{VirtualBackupChapter}
+
+When the Job Level is set to VirtualFull, 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.
+
+Bacula's virtual backup feature is often called Synthetic Backup or
+Consolidation in other backup products.
+
+In some respects the Virtual Backup feature works similar to a Migration job,
+in that Bacula normally reads the data from the pool specified in the Job
+resource, and writes it to the {\bf Next Pool} specified in the Job
+resource. Note, this means that usually the output from the Virtual Backup is
+written into a different pool from where your prior backups are saved. Doing it
+this way guarantees that you will not get a deadlock situation attempting to
+read and write to the same volume in the Storage 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, 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.
+
+A typical Job resource definition might look like the following:
+
+\begin{lstlisting}
+Job {
+  Name = "MyBackup"
+  Type = Backup
+  Client=localhost-fd
+  FileSet = "Full Set"
+  Storage = File
+  Messages = Standard
+  Pool = Default
+  SpoolData = yes
+}
+
+# Default pool definition
+Pool {
+  Name = Default
+  Pool Type = Backup
+  Volume Retention = 365d  # one year
+  NextPool = Full
+  Storage = File
+}
+
+Pool {
+  Name = Full
+  Pool Type = Backup
+  Volume Retention = 365d  # one year
+  Storage = DiskChanger
+}
+
+# Definition of file storage device
+Storage {
+  Name = File
+  Address = localhost
+  Password = "xxx"
+  Device = FileStorage
+  Media Type = File
+  Maximum Concurrent Jobs = 5
+}
+
+# Definition of DDS Virtual tape disk storage device
+Storage {
+  Name = DiskChanger
+  Address = localhost  # N.B. Use a fully qualified name here
+  Password = "yyy"
+  Device = DiskChanger
+  Media Type = DiskChangerMedia
+  Maximum Concurrent Jobs = 4
+  Autochanger = yes
+}
+\end{lstlisting}
+
+Then in bconsole or via a Run schedule, you would run the job as:
+
+\begin{lstlisting}
+run job=MyBackup level=Full
+run job=MyBackup level=Incremental
+run job=MyBackup level=Differential
+run job=MyBackup level=Incremental
+run job=MyBackup level=Incremental
+\end{lstlisting}
+
+So providing there were changes between each of those jobs, you would end up
+with a Full backup, a Differential, which includes the first Incremental
+backup, then two Incremental backups.  All the above jobs would be written to
+the {\bf Default} pool.
+
+To consolidate those backups into a new Full backup, you would run the
+following:
+
+\begin{lstlisting}
+run job=MyBackup level=VirtualFull
+\end{lstlisting}
+
+And it would produce a new Full backup without using the client, and the output
+would be written to the {\bf Full} Pool which uses the Diskchanger Storage.
+
+If the Virtual Full is run, and there are no prior Jobs, the Virtual Full will
+fail with an error.
+
+Note, the Start and End time of the Virtual Full backup is set to the
+values for the last job included in the Virtual Full (in the above example,
+it is an Increment). This is so that if another incremental is done, which
+will be based on the Virtual Full, it will backup all files from the
+last Job included in the Virtual Full rather than from the time the Virtual
+Full was actually run.