From: Eric Bollengier Date: Mon, 4 Feb 2013 08:10:33 +0000 (+0100) Subject: Add virtualfull documentation X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=3ca526805e8edbc7b604c76bde021bd73ddc2785;p=bacula%2Fdocs 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 db35de29..530b86a8 100644 --- 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 b3056415..71f60e60 100644 --- 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.