1 \chapter{New Features in Bacula Enterprise}
2 This chapter presents the new features that have been added to the
3 current Enterprise version of Bacula.
4 These features are available only with a Bacula Systems subscription.
6 In addition to the features in this chapter, the Enterprise version
7 will include the Community features described in the Community new Features
10 % \section{Bacula Enterprise 6.x.x}
11 % \subsection{VirtualFull Backup Consolidation Enhancements}
13 % By default Bacula is selecting jobs automatically, however, you may want to
14 % choose any point in time to create the Virtual backup.
16 % For example, if you have the following Jobs in your catalog:
18 % +-------+---------+-------+----------+----------+-----------+
19 % | JobId | Name | Level | JobFiles | JobBytes | JobStatus |
20 % +-------+---------+-------+----------+----------+-----------+
21 % | 1 | Vbackup | F | 1754 | 50118554 | T |
22 % | 2 | Vbackup | I | 1 | 4 | T |
23 % | 3 | Vbackup | I | 1 | 4 | T |
24 % | 4 | Vbackup | D | 2 | 8 | T |
25 % | 5 | Vbackup | I | 1 | 6 | T |
26 % | 6 | Vbackup | I | 10 | 60 | T |
27 % | 7 | Vbackup | I | 11 | 65 | T |
28 % | 8 | Save | F | 1758 | 50118564 | T |
29 % +-------+---------+-------+----------+----------+-----------+
32 % If you want to consolidate only the first 3 jobs and create a virtual backup
33 % equivalent to Job 1 + Job 2 + Job 3, you will use \texttt{jobid=3} in the
34 % \texttt{run} command, then Bacula will select the previous Full backup, the
35 % previous Differential (if any) and all subsequent Incremental jobs.
38 % run job=Vbackup jobid=3 level=VirtualFull
41 % If you want to consolidate a specific job list, you must specify the exact
42 % list of jobs to merge in the run command line. For example, to consolidate
43 % the last Differential and all subsequent Incremental, you will use
44 % \texttt{jobid=4,5,6,7} or \texttt{jobid=4-7} in the run command line. As one
45 % of the Job in the list is a Differential backup, Bacula will set the new job
46 % level to Differential. If the list is composed only with Incremental jobs,
47 % the new job will have a level set to Incremental.
50 % run job=Vbackup jobid=4-7 level=VirtualFull
53 % When using this feature, Bacula will automatically discard jobs that are not
54 % related to the current Job. For example, specifying \texttt{jobid=7,8},
55 % Bacula will discard the jobid 8.
57 % If you know what you are doing and still want to consolidate jobs that have
58 % different names (so probably different clients, filesets, etc...), you must
59 % use \texttt{alljobid=} keyword instead of \texttt{jobid=}.
62 % run job=Vbackup alljobid=1-3,6-8 level=VirtualFull
65 \section{Bacula Enterprise 6.2.3}
67 \subsection{New Job Edit Code \%P}
69 In various places such as RunScript, you have now access to \%P to get the
72 \section{Bacula Enterprise 6.2.0}
74 \subsection{BWeb Bacula Configuration GUI}
76 In Bacula Enterprise version 6.2, the BWeb Management Suite integrates a
77 Bacula configuration GUI module which is designed to help you create and
78 modify the Bacula configuration files such as bacula-dir.conf,
79 bacula-sd.conf, bacula-fd.conf and bconsole.conf.
81 The BWeb Management Suite offers a number of Wizards which support the
82 Administrator in his daily work. The wizards provide a step by step set of
83 required actions that graphically guide the Administrator to perform quick
84 and easy creation and modification of configuration files.
86 BWeb also provides diagnostic tools that enable the Administrator to check
87 that the Catalog Database is well configured, and that BWeb is installed
90 The new Online help mode displays automatic help text suggestions when the
91 user searches data types.
93 \bsysimageH{bweb_config_screen}{Configuration with BWeb Management Suite}{fig:BwebBconfigScreen}
96 This project was funded by Bacula Systems and is available with the Bacula
99 \subsection{Performance Improvements}
100 Bacula Enterprise 6.2 has a number of new performance improvements:
103 \item An improved way of storing Bacula Resources (as defined in
104 the .conf files). This new handling permits much faster loading or
105 reloading of the conf files, and permits larger numbers of resources.
107 \item Improved performance when inserting large numbers of files in
108 the DB catalog by breaking the insertion into smaller chunks, thus
109 allowing better sharing when running multiple simultaneous jobs.
111 \item Performance enhancements in BVFS concerning eliminating
112 duplicate path records.
114 \item Performance improvement when getting Pool records.
116 \item Pruning performance enhancements.
119 \subsection{Enhanced Status and Error Messages}
120 We have enhanced the Storage daemon status output to be more
121 readable. This is important when there are a large number of
122 devices. In addition to formatting changes, it also includes more
123 details on which devices are reading and writing.
125 A number of error messages have been enhanced to have more specific
126 data on what went wrong.
128 If a file changes size while being backed up the old and new size
131 \subsection{Miscellaneous New Features}
133 \item Allow unlimited line lengths in .conf files (previously limited
136 \item Allow /dev/null in ChangerCommand to indicated a Virtual Autochanger.
138 \item Add a --fileprune option to the manual\_prune.pl script.
140 \item Add a -m option to make\_catalog\_backup.pl to do maintenance
143 \item Safer code that cleans up the working directory when starting
144 the daemons. It limits what files can be deleted, hence enhances
147 \item Added a new .ls command in bconsole to permit browsing a client's
150 \item Fixed a number of bugs, includes some obscure seg faults, and a
151 race condition that occurred infrequently when running Copy, Migration,
152 or Virtual Full backups.
154 \item Included a new vSphere library version, which will hopefully
155 fix some of the more obscure bugs.
157 \item Upgraded to a newer version of Qt4 for bat. All indications
158 are that this will improve bat's stability on Windows machines.
160 \item The Windows installers now detect and refuse to install on
161 an OS that does not match the 32/64 bit value of the installer.
165 \section{Bacula Enterprise 6.0.6}
167 \subsection{Incremental Accelerator Plugin for NetApp}
169 The Incremental Accelerator for NetApp Plugin is designed to simplify the
170 backup and restore procedure of your NetApp NAS hosting a huge number of files.
172 \smallskip{} When using the NetApp HFC Plugin, Bacula Enterprise will query the
173 NetApp device to get the list of all files modified since the last backup
174 instead of having to walk through the entire filesystem. Once Bacula have the
175 list of all files to back's up, it will use a standard network share (such as
176 NFS or CIFS) to access files.
179 This project was funded by Bacula Systems and is available with the Bacula
182 \subsection{PostgreSQL Plugin}
184 The PostgreSQL plugin is designed to simplify the backup and restore procedure
185 of your PostgreSQL cluster, the backup administrator doesn't need to learn about
186 internals of Postgres backup techniques or write complex scripts. The plugin
187 will automatically take care for you to backup essential information such as
188 configuration, users definition or tablespaces. The PostgreSQL plugin supports
189 both dump and Point In Time Recovery (PITR) backup techniques.
192 This project was funded by Bacula Systems and is available with the Bacula
195 \subsection{Maximum Reload Requests}
197 The new Director directive \texttt{Maximum Reload Requests} permits to
198 configure the number of reload requests that can be done while jobs are
204 Maximum Reload Requests = 64
210 \subsection{FD Storage Address}
212 When the Director is behind a NAT, in a WAN area, to connect to
214 the StorageDaemon, the Director uses an ``external'' ip address,
215 and the FileDaemon should use an ``internal'' IP address to contact the
218 The normal way to handle this situation is to use a canonical name such as
219 ``storage-server'' that will be resolved on the Director side as the WAN address
220 and on the Client side as the LAN address. This is now possible to configure
221 this parameter using the new \texttt{FDStorageAddress} Storage
225 \bsysimageH{BackupOverWan1}{Backup Over WAN}{figbs6:fdstorageaddress}
226 % \label{fig:fdstorageaddress}
232 FD Storage Address = 10.0.0.1
238 % # or in the Client resouce
243 % FD Storage Address = 10.0.0.1
249 % Note that using the Client \texttt{FDStorageAddress} directive will not allow
250 % to use multiple Storage Daemon, all Backup or Restore requests will be sent to
251 % the specified \texttt{FDStorageAddress}.
253 \subsection{Maximum Concurrent Read Jobs}
254 This is a new directive that can be used in the {\bf bacula-dir.conf} file
255 in the Storage resource. The main purpose is to limit the number
256 of concurrent Copy, Migration, and VirtualFull jobs so that
257 they don't monopolize all the Storage drives causing a deadlock situation
258 where all the drives are allocated for reading but none remain for
259 writing. This deadlock situation can occur when running multiple
260 simultaneous Copy, Migration, and VirtualFull jobs.
263 The default value is set to 0 (zero), which means there is no
264 limit on the number of read jobs. Note, limiting the read jobs
265 does not apply to Restore jobs, which are normally started by
266 hand. A reasonable value for this directive is one half the number
267 of drives that the Storage resource has rounded down. Doing so,
268 will leave the same number of drives for writing and will generally
269 avoid over committing drives and a deadlock.
272 \section{Bacula Enterprise 6.0.4}
274 \subsection{VMWare vSphere VADP Plugin}
276 The Bacula Enterprise vSphere plugin provides virtual
277 machine bare metal recovery, while the backup at the guest level simplify data
278 protection of critical applications.
280 The plugin integrates the VMware's Changed Block Tracking (CBT) technology to
281 ensure only blocks that have changed since the initial Full, and/or the last
282 Incremental or Differential Backup are sent to the current Incremental or
283 Differential backup stream to give you more efficient backups and reduced
286 \subsection{Oracle RMAN Plugin}
288 The Bacula Enterprise Oracle Plugin is designed to simplify the backup and
289 restore procedure of your Oracle Database instance, the backup administrator
290 don't need to learn about internals of Oracle backup techniques or write
291 complex scripts. The Bacula Enterprise Oracle plugin supports both dump and
292 Point In Time Recovery (PITR) with RMAN backup techniques.
295 \section{Bacula Enterprise 6.0.2}
297 To make Bacula function properly with multiple Autochanger definitions, in
298 the Director's configuration, you must adapt your {\bf bacula-dir.conf}
299 {\bf Storage} directives.
302 Each autochanger that you have defined in an {\bf Autochanger}
303 resource in the Storage daemon's {\bf bacula-sd.conf} file,
304 must have a corresponding {\bf Autochanger} resource defined
305 in the Director's {\bf bacula-dir.conf} file. Normally you will
306 already have a {\bf Storage} resource that points to the
307 Storage daemon's {\bf Autochanger} resource. Thus you need
308 only to change the name of the {\bf Storage} resource to
309 {\bf Autochanger}. In addition the {\bf Autochanger = yes}
310 directive is not needed in the Director's {\bf Autochanger}
311 resource, since the resource name is {\bf Autochanger}, the
312 Director already knows that it represents an autochanger.
315 In addition to the above change ({\bf Storage} to {\bf Autochanger}),
316 you must modify any additional {\bf Storage} resources that correspond
317 to devices that are part of the {\bf Autochanger} device.
318 Instead of the previous {\bf Autochanger = yes} directive they
319 should be modified to be {\bf Autochanger = xxx} where you
320 replace the {\bf xxx} with the name of the Autochanger.
323 For example, in the bacula-dir.conf file:
326 Autochanger { # New resource
328 Address = cibou.company.com
330 Password = "xxxxxxxxxx"
331 Device = LTO-Changer-1
333 Maximum Concurrent Jobs = 50
337 Name = Changer-1-Drive0
338 Address = cibou.company.com
340 Password = "xxxxxxxxxx"
341 Device = LTO4_1_Drive0
343 Maximum Concurrent Jobs = 5
344 Autochanger = Changer-1 # New directive
348 Name = Changer-1-Drive1
349 Address = cibou.company.com
351 Password = "xxxxxxxxxx"
352 Device = LTO4_1_Drive1
354 Maximum Concurrent Jobs = 5
355 Autochanger = Changer-1 # New directive
361 Note that Storage resources {\bf Changer-1-Drive0} and
362 {\bf Changer-1-Drive1} are not required since they make
363 up part of an autochanger, and normally, Jobs refer only
364 to the Autochanger resource.
365 However, by referring to those
366 Storage definitions in a Job, you will use only
367 the indicated drive. This is not normally what
368 you want to do, but it is very useful and often used
369 for reserving a drive for restores. See the Storage daemon
370 example .conf below and the use of {\bf AutoSelect = no}.
372 So, in summary, the changes are:
374 \item Change {\bf Storage} to {\bf Autochanger} in the LTO4 resource.
375 \item Remove the {\bf Autochanger = yes} from the {\bf Autochanger}
377 \item Change the {\bf Autochanger = yes} in each of the {\bf Storage}
378 device that belong to the {\bf Autochanger} to point to the
379 {\bf Autochanger} resource with for the example above the
380 directive {\bf Autochanger = LTO4}.
383 \section{Bacula Enterprise 6.0.0}
385 \subsection{Incomplete Jobs}
386 During a backup, if the Storage daemon experiences disconnection
387 with the File daemon during backup (normally a comm line problem
388 or possibly an FD failure), under conditions that the SD determines
389 to be safe it will make the failed job as Incomplete rather than
390 failed. This is done only if there is sufficient valid backup
391 data that was written to the Volume. The advantage of an Incomplete
392 job is that it can be restarted by the new bconsole {\bf restart}
393 command from the point where it left off rather than from the
394 beginning of the jobs as is the case with a cancel.
396 \subsection{The Stop Command}
397 Bacula has been enhanced to provide a {\bf stop} command,
398 very similar to the {\bf cancel} command with the main difference
399 that the Job that is stopped is marked as Incomplete so that
400 it can be restarted later by the {\bf restart} command where
401 it left off (see below). The {\bf stop} command with no
402 arguments, will like the cancel command, prompt you with the
403 list of running jobs allowing you to select one, which might
404 look like the following:
409 1: JobId=3 Job=Incremental.2012-03-26_12.04.26_07
410 2: JobId=4 Job=Incremental.2012-03-26_12.04.30_08
411 3: JobId=5 Job=Incremental.2012-03-26_12.04.36_09
412 Choose Job to stop (1-3): 2
413 2001 Job "Incremental.2012-03-26_12.04.30_08" marked to be stopped.
414 3000 JobId=4 Job="Incremental.2012-03-26_12.04.30_08" marked to be stopped.
417 \subsection{The Restart Command}
418 The new {\bf Restart command} allows console users to restart
419 a canceled, failed, or incomplete Job. For canceled and failed
420 Jobs, the Job will restart from the beginning. For incomplete
421 Jobs the Job will restart at the point that it was stopped either
422 by a stop command or by some recoverable failure.
425 If you enter the {\bf restart} command in bconsole, you will get the
430 You have the following choices:
435 Select termination code: (1-4):
438 If you select the {\bf All} option, you may see something like:
441 Select termination code: (1-4): 4
442 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
443 | jobid | name | starttime | type | level | jobfiles |
444 jobbytes | jobstatus |
445 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
446 | 1 | Incremental | 2012-03-26 12:15:21 | B | F | 0 |
448 | 2 | Incremental | 2012-03-26 12:18:14 | B | F | 350 |
450 | 3 | Incremental | 2012-03-26 12:18:30 | B | F | 0 |
452 | 4 | Incremental | 2012-03-26 12:18:38 | B | F | 331 |
454 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
455 Enter the JobId list to select:
458 Then you may enter one or more JobIds to be restarted, which may
459 take the form of a list of JobIds separated by commas, and/or JobId
460 ranges such as {\bf 1-4}, which indicates you want to restart JobIds
461 1 through 4, inclusive.
463 \subsection{Support for Exchange Incremental Backups}
464 The Bacula Enterprise version 6.0 VSS plugin now supports
465 Full and Incremental backups for Exchange. We strongly
466 recommend that you do not attempt to run Differential jobs with
467 Exchange as it is likely to produce a situation where restores
468 will no longer select the correct jobs, and thus the
469 Windows Exchange VSS writer will fail when applying log files.
470 There is a Bacula Systems Enterprise white paper that provides
471 the details of backup and restore of Exchange 2010 with the
475 Restores can be done while Exchange is running, but you
476 must first unmount (dismount in Microsoft terms) any database
477 you wish to restore and explicitly mark them to permit a
478 restore operation (see the white paper for details).
481 This project was funded by Bacula Systems and is available with the Bacula
484 \subsection{Support for MSSQL Block Level Backups}
485 With the addition of block level backup support to the
486 Bacula Enterprise VSS MSSQL component, you can now do
487 Differential backups in addition to Full backups.
488 Differential backups use Microsoft's partial block backup
489 (a block differencing or deduplication that we call Delta).
490 This partial block backup permits backing up only those
491 blocks that have changed. Database restores can be made while
492 the MSSQL server is running, but any databases selected for
493 restore will be automatically taken offline by the MSSQL
494 server during the restore process.
496 Incremental backups for MSSQL are not support by
497 Microsoft. We strongly recommend that you not perform Incremental
498 backups with MSSQL as they will probably produce a situation
499 where restore will no longer work correctly.
502 We are currently working on producing a white paper that will give more
503 details of backup and restore with MSSQL. One point to note is that during
504 a restore, you will normally not want to restore the {\bf master} database.
505 You must exclude it from the backup selections that you have made or the
509 It is possible to restore the {\bf master} database, but you must
510 first shutdown the MSSQL server, then you must perform special
511 recovery commands. Please see Microsoft documentation on how
512 to restore the master database.
515 This project was funded by Bacula Systems and is available with the Bacula
519 \subsection{Job Bandwidth Limitation}
521 The new {\bf Job Bandwidth Limitation} directive may be added to the File
522 daemon's and/or Director's configuration to limit the bandwidth used by a Job
523 on a Client. It can be set in the File daemon's conf file for all Jobs run in
524 that File daemon, or it can be set for each Job in the Director's conf file.
530 Working Directory = /some/path
531 Pid Directory = /some/path
533 Maximum Bandwidth Per Job = 5Mb/s
537 The above example would cause any jobs running with the FileDaemon to not
538 exceed 5Mb/s of throughput when sending data to the Storage Daemon.
540 You can specify the speed parameter in k/s, Kb/s, m/s, Mb/s.
546 FileSet = FS_localhost
549 Maximum Bandwidth = 5Mb/s
554 The above example would cause Job \texttt{localhost-data} to not exceed 5MB/s
555 of throughput when sending data from the File daemon to the Storage daemon.
557 A new console command \texttt{setbandwidth} permits to set dynamically the
558 maximum throughput of a running Job or for future jobs of a Client.
561 * setbandwidth limit=1000000 jobid=10
564 The \texttt{limit} parameter is in Kb/s.
567 This project was funded by Bacula Systems and is available in
568 the Enterprise Edition.
570 \subsection{Incremental/Differential Block Level Difference Backup}
572 The new \texttt{delta} Plugin is able to compute and apply signature-based file
573 differences. It can be used to backup only changes in a big binary file like
574 Outlook PST, VirtualBox/VMware images or database files.
576 It supports both Incremental and Differential backups and stores signatures
577 database in the File Daemon working directory. This plugin is available on all
578 platform including Windows 32 and 64bit.
580 Accurate option should be turned on in the Job resource.
593 Plugin = "delta:/home/eric/.VirtualBox/HardDisks/lenny-i386.vdi"
598 Name = DeltaFS-Include
606 # Use the Options{} filtering and options
607 File = /home/user/.VirtualBox
613 Please contact Bacula Systems support to get Delta Plugin specific
617 This project was funded by Bacula Systems and is available with the Bacula
620 \subsection{SAN Shared Tape Storage Plugin}
622 The problem with backing up multiple servers at the same time to the
623 same tape library (or autoloader) is that if both servers access the
624 same tape drive same time, you will very likely get data corruption.
625 This is where the Bacula Systems shared tape storage plugin comes into play. The
626 plugin ensures that only one server at a time can connect to each device
627 (tape drive) by using the SPC-3 SCSI reservation protocol. Please contact
628 Bacula Systems support to get SAN Shared Storage Plugin specific
632 This project was funded by Bacula Systems and is available with Bacula
635 \subsection{Advanced Autochanger Usage}
637 The new \texttt{Shared Storage} Director's directive is a Bacula Enterprise
638 feature that allows you to share volumes between different Storage
639 resources. This directive should be used \textbf{only} if all \texttt{Media
640 Type} are correctly set across all Devices.
642 The \texttt{Shared Storage} directive should be used when using the SAN
643 Shared Storage plugin or when accessing from the Director Storage resources
644 directly to Devices of an Autochanger.
646 When sharing volumes between different Storage resources, you will
647 need also to use the \texttt{reset-storageid} script before using the
648 \texttt{update slots} command. This script can be scheduled once a day in
652 $ /opt/bacula/scripts/reset-storageid MediaType StorageName
654 * update slots storage=StorageName drive=0
657 Please contact Bacula Systems support to get help on this advanced
661 This project was funded by Bacula Systems and is available with Bacula
664 \subsection{Enhancement of the NDMP Plugin}
666 The previous NDMP Plugin 4.0 was fully supporting only the NetApp hardware, the
667 new NDMP Plugin should now be able to support all NAS vendors with the
668 \texttt{volume\_format} plugin command option.
670 On some NDMP devices such as Celera or Blueray, the administrator can use arbitrary
671 volume structure name, ex:
675 /rootvolume/volume_tmp
679 The NDMP plugin should be aware of the structure organization in order to
680 detect if the administrator wants to restore in a new volume
681 (\texttt{where=/dev/vol\_tmp}) or inside a subdirectory of the targeted volume
682 (\texttt{where=/tmp}).
689 Plugin = "ndmp:host=nasbox user=root pass=root file=/dev/vol1 volume_format=/dev/"
694 Please contact Bacula Systems support to get NDMP Plugin specific
698 This project was funded by Bacula Systems and is available with the Bacula
701 \subsection{Always Backup a File}
703 When the Accurate mode is turned on, you can decide to always backup a file
704 by using then new {\bf A} Accurate option in your FileSet. For example:
727 This project was funded by Bacula Systems based on an idea of James Harper and
728 is available with the Bacula Enterprise Edition.
730 \subsection{Setting Accurate Mode During at Runtime}
732 You are now able to specify the Accurate mode on the \texttt{run} command and
733 in the Schedule resource.
736 * run accurate=yes job=Test
742 Run = Full 1st sun at 23:05
743 Run = Differential accurate=yes 2nd-5th sun at 23:05
744 Run = Incremental accurate=no mon-sat at 23:05
748 It can allow you to save memory and and CPU resources on the catalog server in
752 These advanced tuning options are available with the Bacula Enterprise Edition.
754 % Common with community
755 \subsection{Additions to RunScript variables}
756 You can have access to JobBytes, JobFiles and Director name using \%b, \%F and \%D
757 in your runscript command. The Client address is now available through \%h.
760 RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h Dir=%D"
763 \subsection{LZO Compression}
765 LZO compression was added in the Unix File Daemon. From the user point of view,
766 it works like the GZIP compression (just replace {\bf compression=GZIP} with
767 {\bf compression=LZO}).
772 Options { compression=LZO }
778 LZO provides much faster compression and decompression speed but lower
779 compression ratio than GZIP. It is a good option when you backup to disk. For
780 tape, the built-in compression may be a better option.
782 LZO is a good alternative for GZIP1 when you don't want to slow down your
783 backup. On a modern CPU it should be able to run almost as fast as:
786 \item your client can read data from disk. Unless you have very fast disks like
787 SSD or large/fast RAID array.
788 \item the data transfers between the file daemon and the storage daemon even on
792 Note that bacula only use one compression level LZO1X-1.
795 The code for this feature was contributed by Laurent Papier.
797 \subsection{New Tray Monitor}
799 Since the old integrated Windows tray monitor doesn't work with
800 recent Windows versions, we have written a new Qt Tray Monitor that is available
801 for both Linux and Windows. In addition to all the previous features,
802 this new version allows you to run Backups from
803 the tray monitor menu.
805 \bsysimageH{tray-monitor}{New tray monitor}{figbs6:traymonitor}
807 \bsysimageH{tray-monitor1}{Run a Job through the new tray monitor}{figbs6:traymonitor1}
811 To be able to run a job from the tray monitor, you need to
812 allow specific commands in the Director monitor console:
817 CommandACL = status, .clients, .jobs, .pools, .storage, .filesets, .messages, run
818 ClientACL = *all* # you can restrict to a specific host
830 This project was funded by Bacula Systems and is available with Bacula
831 the Enterprise Edition and the Community Edition.
833 \subsection{Purge Migration Job}
835 The new {\bf Purge Migration Job} directive may be added to the Migration
836 Job definition in the Director's configuration file. When it is enabled
837 the Job that was migrated during a migration will be purged at
838 the end of the migration job.
846 Client = localhost-fd
849 Storage = DiskChanger
852 Selection Pattern = ".*Save"
854 Purge Migration Job = yes
860 This project was submitted by Dunlap Blake; testing and documentation was funded
863 \subsection{Changes in the Pruning Algorithm}
865 We rewrote the job pruning algorithm in this version. Previously, in some users
866 reported that the pruning process at the end of jobs was very long. It should
867 not be longer the case. Now, Bacula won't prune automatically a Job if this
868 particular Job is needed to restore data. Example:
872 JobId: 2 Level: Incremental
873 JobId: 3 Level: Incremental
874 JobId: 4 Level: Differential
875 .. Other incrementals up to now
878 In this example, if the Job Retention defined in the Pool or in the Client
879 resource causes that Jobs with Jobid in 1,2,3,4 can be pruned, Bacula will
880 detect that JobId 1 and 4 are essential to restore data at the current state
881 and will prune only JobId 2 and 3.
883 \texttt{Important}, this change affect only the automatic pruning step after a
884 Job and the \texttt{prune jobs} Bconsole command. If a volume expires after the
885 \texttt{VolumeRetention} period, important jobs can be pruned.
887 \subsection{Ability to Verify any specified Job}
888 You now have the ability to tell Bacula which Job should verify instead of
889 automatically verify just the last one.
891 This feature can be used with VolumeToCatalog, DiskToCatalog and Catalog level.
893 To verify a given job, just specify the Job jobid in argument when starting the
896 *run job=VerifyVolume jobid=1 level=VolumeToCatalog
898 JobName: VerifyVolume
899 Level: VolumeToCatalog
902 Pool: Default (From Job resource)
903 Storage: File (From Job resource)
904 Verify Job: VerifyVol.2010-09-08_14.17.17_03
905 Verify List: /tmp/regress/working/VerifyVol.bsr
906 When: 2010-09-08 14:17:31
908 OK to run? (yes/mod/no):
912 This project was funded by Bacula Systems and is available with Bacula
913 Enterprise Edition and Community Edition.