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 includes all the Community features described in the Community new Features
10 \section{Bacula Enterprise 6.6.0}
11 \subsection{Comm Line Compression}
12 Bacula Enterprise version 6.6.0 and later now includes communication
13 line compression. It is turned on by default, and if the
14 two Bacula components (Dir, FD, SD, bconsole) are both
15 version 6.6.0 or greater, comm line compression
16 will be enabled, by default. If for some reason, you do not want
17 comm line compression, you may disable it with the
24 This directive can appear in the following resources:
26 bacula-dir.conf: Director resource
27 bacula-fd.conf Client (or FileDaemon) resource
28 bacula-sd.conf: Storage resource
29 bconsole.conf: Console resource
30 bat.conf: Console resource
34 In many cases, the volume of data transmitted across the
35 communications line can be reduced by a factor of three when
36 this directive is enabled (default).
38 \subsection{Read Only Storage Devices}
39 This version of Bacula permits tdefining a Storage deamon device
40 to be read-only. That is if the {\bf ReadOnly} directive is specified and
41 enabled, the drive can only be used for read operations.
42 The the {\bf ReadOnly} directive can be defined in any bacula-sd.conf
43 Device resource, and is most useful to reserve one or more
44 drives for restores. An example is:
50 \subsection{Catalog Performance Improvements}
51 There is a new Bacula database format (schema) in this version
52 of Bacula that eliminates the FileName table by placing the
53 Filename into the File record of the File table.
54 This permits some substantial performance improvements
55 particularly for large (1GB or greater) databases.
57 The update\_xxx\_catalog script will automatically update the
58 Bacula database format, but you should realize that for
59 very large databases (greater than 1GB), it may take some
60 time, and there are several different options for doing the
61 update: 1. Shudown the database and update it. 2. Update the
62 database while production jobs are running. See the Bacula Systems
63 White Paper ``Migration-to-6.6'' on this subject.
66 This database format change can provide very significant improvements in
67 the speed of metadata insertion into the database, and in some cases
68 (backup of large email servers) can significantly reduce the size of the
71 \subsection{Plugin Restore Options}
72 This version of Bacula permits user configuration of Plugins at restore
73 time. For example, it is now possible to choose the \texttt{datastore}
74 where your VMware image will be restored, or for example to choose
75 \texttt{pg\_restore} options directly. See specific Plugin whitepaper
76 for more information about new restore options.
78 The restore options, if implemented in a plugin, will be
79 presented to you during initiation of a restore either by
80 command line or if available by a GUI such
81 as BWeb. For examples of the command line interface and
82 the GUI interface, please see below:
87 Bootstrap: /tmp/regress/working/my-dir.restore.1.bsr
88 Where: /tmp/regress/tmp/bacula-restores
90 Plugin Options: *None*
91 OK to run? (yes/mod/no): mod
96 Select parameter to modify (1-13): 13
97 Automatically selected : vsphere: host=squeeze2
98 Plugin Restore Options
102 Use above plugin configuration? (yes/mod/no): mod
103 You have the following choices:
104 1: datastore (Datastore to use for restore)
105 2: restore_host (ESX host to use for restore)
106 3: new_hostname (Restore host to specified name)
107 Select parameter to modify (1-3): 3
108 Please enter a value for new_hostname: test
109 Plugin Restore Options
113 Use above plugin configuration? (yes/mod/no): yes
117 Or via the BWeb restore interface (see Fig \vref{fig:bms-restore})
119 \bsysimageH{vsphere-restore-gui}{Choose datastore, ESXi or hostname at restore time}{fig:bms-restore}
121 \subsection{Alldrives Plugin Improvements}
122 The \texttt{alldrives} plugin permits to simplify the FileSet creation of
123 Windows Clients, the plugin will generate automatically a FileSet including all
128 The \texttt{alldrives} plugin now accepts the \texttt{snapshot} option that
129 permits generating snapshots for all local Windows drives but without
130 explicitly adding them to the FileSet. It can be combined with the
131 \texttt{vss} plugin. For example:
137 Plugin = "alldrives: snapshot"
138 Plugin = "vss:/@MSSQL/"
143 \subsection{New Truncate Command}
144 We have added a new truncate command to bconsole, which
145 will truncate a Volume if the Volume is purged and if
146 the Volume is also marked {\bf Action On Purge = Truncate}.
147 This feature was originally added in Bacula version 5.0.1,
148 but the mechanism for actually doing the truncate required
149 the user to enter a command such as:
152 purge volume action=truncate storage=File pool=Default
155 The above command is now simplified to be:
158 truncate storage=File pool=Default
161 \subsection{New Resume Command}
162 This command does exactly the same thing as a
163 {\bf restart} command but for some users the
164 name may be more logical since in general the
165 {\bf restart} command is used to resume running
166 a Job that was incompleted.
168 \section{Bacula Enterprise 6.4.x}
170 The following features were added during the 6.4.x life cycle.
172 \subsection{SAP Plugin}
174 The Bacula Enterprise SAP Plugin is designed to implement the official SAP
175 Backint interface to simplify the backup and restore procedure through your
176 traditional SAP database tools. See SAP-Backint whitepaper for more
179 \subsection{Oracle SBT Plugin}
181 By default, the Oracle backup Manager, RMAN, sends all backups to an operating
182 system specific directory on disk. You can also configure RMAN to make backups
183 to media such as tape using SBT module. Bacula will act as Media Manager, and
184 the data will be transfered directly from RMAN to Bacula. See Oracle Plugin
185 whitepaper for more information.
187 \subsection{MySQL Plugin}
189 The MySQL plugin is designed to simplify the backup and restore of your MySQL
190 server, the backup administrator doesn't need to know about internals of MySQL
191 backup techniques or how to write complex scripts. The plugin will
192 automatically backup essential information such as configuration or user
193 definitions. The MySQL plugin supports both dump (with support for Incremental
194 backup) and binary backup techniques. See MySQL Plugin whitepaper for more
197 \section{Bacula Enterprise 6.4.0}
198 \subsection{Deduplication Optimized Volumes}
199 This version of Bacula includes a new alternative (or additional)
200 Volume format that optimized the placement of files such
201 that an underlying deduplicating filesystem such as ZFS
202 can optimally deduplicate the backup data that is written
203 by Bacula. These are called Deduplication Optimized Volumes
204 or Aligned Volumes for short. The details of how to use this
205 feature and its considerations are in the Bacula Systems
206 Deduplication Optimized Volumes white paper.
208 \subsection{Migration/Copy/VirtualFull Performance Enhancements}
209 The Bacula Storage daemon now permits multiple jobs to simultaneously read
210 the same disk Volume, which gives substantial performance enhancements when
211 running Migration, Copy, or VirtualFull jobs that read disk Volumes. Our
212 testing shows that when running multiple simultaneous jobs, the jobs can
213 finish up to ten times faster with this version of Bacula. This is
214 built-in to the Storage daemon, so it happens automatically and
217 \subsection{VirtualFull Backup Consolidation Enhancements}
218 By default Bacula selects jobs automatically for a VirtualFull,
219 however, you may want to create the Virtual backup based on a
220 particular backup (point in time) that exists.
222 For example, if you have the following backup Jobs in your catalog:
224 +-------+---------+-------+----------+----------+-----------+
225 | JobId | Name | Level | JobFiles | JobBytes | JobStatus |
226 +-------+---------+-------+----------+----------+-----------+
227 | 1 | Vbackup | F | 1754 | 50118554 | T |
228 | 2 | Vbackup | I | 1 | 4 | T |
229 | 3 | Vbackup | I | 1 | 4 | T |
230 | 4 | Vbackup | D | 2 | 8 | T |
231 | 5 | Vbackup | I | 1 | 6 | T |
232 | 6 | Vbackup | I | 10 | 60 | T |
233 | 7 | Vbackup | I | 11 | 65 | T |
234 | 8 | Save | F | 1758 | 50118564 | T |
235 +-------+---------+-------+----------+----------+-----------+
238 and you want to consolidate only the first 3 jobs and create a
239 virtual backup equivalent to Job 1 + Job 2 + Job 3, you will use
240 \texttt{jobid=3} in the \texttt{run} command, then Bacula will select the
241 previous Full backup, the previous Differential (if any) and all subsequent
245 run job=Vbackup jobid=3 level=VirtualFull
248 If you want to consolidate a specific job list, you must specify the exact
249 list of jobs to merge in the run command line. For example, to consolidate
250 the last Differential and all subsequent Incremental, you will use
251 \texttt{jobid=4,5,6,7} or \texttt{jobid=4-7} on the run command line. As one
252 of the Job in the list is a Differential backup, Bacula will set the new job
253 level to Differential. If the list is composed only with Incremental jobs,
254 the new job will have a level set to Incremental.
257 run job=Vbackup jobid=4-7 level=VirtualFull
260 When using this feature, Bacula will automatically discard jobs that are
261 not related to the current Job. For example, specifying
262 \texttt{jobid=7,8}, Bacula will discard JobId 8 because it is not
263 part of the same backup Job.
265 We do not recommend it, but really want to consolidate jobs that have
266 different names (so probably different clients, filesets, etc...), you must
267 use \texttt{alljobid=} keyword instead of \texttt{jobid=}.
270 run job=Vbackup alljobid=1-3,6-8 level=VirtualFull
273 \subsection{New Prune ``Expired'' Volume Command}
274 In Bacula Enterprise 6.4, it is now possible to prune all volumes
275 (from a pool, or globally) that are ``expired''. This option can be
276 scheduled after or before the backup of the Catalog and can be
277 combined with the Truncate On Purge option. The Expired Prune option can
278 be used instead of the \texttt{manual\_prune.pl} script.
281 * prune expired volumes
283 * prune expired volumes pool=FullPool
286 To schedule this option automatically, it can be added to the BackupCatalog job
294 Console = "prune expired volume yes"
300 \section{Bacula Enterprise 6.2.3}
302 \subsection{New Job Edit Codes \%P \%C}
303 In various places such as RunScripts, you have now access to \%P to get the
304 current Bacula process ID (PID) and \%C to know if the current job is a
307 \section{Bacula Enterprise 6.2.0}
309 \subsection{BWeb Bacula Configuration GUI}
310 In Bacula Enterprise version 6.2, the BWeb Management Suite integrates a
311 Bacula configuration GUI module which is designed to help you create and
312 modify the Bacula configuration files such as bacula-dir.conf,
313 bacula-sd.conf, bacula-fd.conf and bconsole.conf.
315 The BWeb Management Suite offers a number of Wizards which support the
316 Administrator in his daily work. The wizards provide a step by step set of
317 required actions that graphically guide the Administrator to perform quick
318 and easy creation and modification of configuration files.
320 BWeb also provides diagnostic tools that enable the Administrator to check
321 that the Catalog Database is well configured, and that BWeb is installed
324 The new Online help mode displays automatic help text suggestions when the
325 user searches data types.
327 \bsysimageH{bweb_config_screen}{Configuration with BWeb Management Suite}{fig:BwebBconfigScreen}
330 This project was funded by Bacula Systems and is available with the Bacula
333 \subsection{Performance Improvements}
334 Bacula Enterprise 6.2 has a number of new performance improvements:
337 \item An improved way of storing Bacula Resources (as defined in
338 the .conf files). This new handling permits much faster loading or
339 reloading of the conf files, and permits larger numbers of resources.
341 \item Improved performance when inserting large numbers of files in
342 the DB catalog by breaking the insertion into smaller chunks, thus
343 allowing better sharing when running multiple simultaneous jobs.
345 \item Performance enhancements in BVFS concerning eliminating
346 duplicate path records.
348 \item Performance improvement when getting Pool records.
350 \item Pruning performance enhancements.
353 \subsection{Enhanced Status and Error Messages}
354 We have enhanced the Storage daemon status output to be more
355 readable. This is important when there are a large number of
356 devices. In addition to formatting changes, it also includes more
357 details on which devices are reading and writing.
359 A number of error messages have been enhanced to have more specific
360 data on what went wrong.
362 If a file changes size while being backed up the old and new size
365 \subsection{WinBMR 3}
366 The Windows Bare Metal Recovery (BMR) plugin enables you to do safe, reliable
367 Disaster Recovery with Bacula Enterprise Edition on Windows and allows you to
368 get critical systems up and running again quickly. The Enterprise Edition
369 Windows BMR is a toolkit that allows the Administrator to perform the restore
370 of a complete operating system to the same or similar hardware without actually
371 going through the operating system's installation procedure.
375 The WinBMR 3 version is a major rewrite of the product that support all x86
376 Windows versions and technologies. Especially UEFI and secure boot systems. The
377 WinBMR 3 File Daemon plugin is now part of the plugins included with the Bacula
378 File Daemon package. The rescue CD or USB key is available separately.
380 \subsection{Miscellaneous New Features}
382 \item Allow unlimited line lengths in .conf files (previously limited
385 \item Allow /dev/null in ChangerCommand to indicated a Virtual Autochanger.
387 \item Add a --fileprune option to the manual\_prune.pl script.
389 \item Add a -m option to make\_catalog\_backup.pl to do maintenance
392 \item Safer code that cleans up the working directory when starting
393 the daemons. It limits what files can be deleted, hence enhances
396 \item Added a new .ls command in bconsole to permit browsing a client's
399 \item Fixed a number of bugs, includes some obscure seg faults, and a
400 race condition that occurred infrequently when running Copy, Migration,
401 or Virtual Full backups.
403 \item Included a new vSphere library version, which will hopefully
404 fix some of the more obscure bugs.
406 \item Upgraded to a newer version of Qt4 for bat. All indications
407 are that this will improve bat's stability on Windows machines.
409 \item The Windows installers now detect and refuse to install on
410 an OS that does not match the 32/64 bit value of the installer.
414 \section{Bacula Enterprise 6.0.6}
416 \subsection{Incremental Accelerator Plugin for NetApp}
418 The Incremental Accelerator for NetApp Plugin is designed to simplify the
419 backup and restore procedure of your NetApp NAS hosting a huge number of files.
421 \smallskip{} When using the NetApp HFC Plugin, Bacula Enterprise will query the
422 NetApp device to get the list of all files modified since the last backup
423 instead of having to walk through the entire filesystem. Once Bacula have the
424 list of all files to back's up, it will use a standard network share (such as
425 NFS or CIFS) to access files.
428 This project was funded by Bacula Systems and is available with the Bacula
431 \subsection{PostgreSQL Plugin}
433 The PostgreSQL plugin is designed to simplify the backup and restore procedure
434 of your PostgreSQL cluster, the backup administrator doesn't need to learn about
435 internals of Postgres backup techniques or write complex scripts. The plugin
436 will automatically take care for you to backup essential information such as
437 configuration, users definition or tablespaces. The PostgreSQL plugin supports
438 both dump and Point In Time Recovery (PITR) backup techniques.
441 This project was funded by Bacula Systems and is available with the Bacula
444 \subsection{Maximum Reload Requests}
446 The new Director directive \texttt{Maximum Reload Requests} permits to
447 configure the number of reload requests that can be done while jobs are
453 Maximum Reload Requests = 64
459 \subsection{FD Storage Address}
461 When the Director is behind a NAT, in a WAN area, to connect to
463 the StorageDaemon, the Director uses an ``external'' ip address,
464 and the FileDaemon should use an ``internal'' IP address to contact the
467 The normal way to handle this situation is to use a canonical name such as
468 ``storage-server'' that will be resolved on the Director side as the WAN
469 address and on the Client side as the LAN address. This is now possible to
470 configure this parameter using the new directive \texttt{FDStorageAddress} in
471 the Storage or Client resource.
474 \bsysimageH{BackupOverWan1}{Backup Over WAN}{figbs6:fdstorageaddress}
475 % \label{fig:fdstorageaddress}
481 FD Storage Address = 10.0.0.1
487 % # or in the Client resouce
494 FD Storage Address = 10.0.0.1
500 Note that using the Client \texttt{FDStorageAddress} directive will not allow
501 to use multiple Storage Daemon, all Backup or Restore requests will be sent to
502 the specified \texttt{FDStorageAddress}.
504 \subsection{Maximum Concurrent Read Jobs}
505 This is a new directive that can be used in the {\bf bacula-dir.conf} file
506 in the Storage resource. The main purpose is to limit the number
507 of concurrent Copy, Migration, and VirtualFull jobs so that
508 they don't monopolize all the Storage drives causing a deadlock situation
509 where all the drives are allocated for reading but none remain for
510 writing. This deadlock situation can occur when running multiple
511 simultaneous Copy, Migration, and VirtualFull jobs.
514 The default value is set to 0 (zero), which means there is no
515 limit on the number of read jobs. Note, limiting the read jobs
516 does not apply to Restore jobs, which are normally started by
517 hand. A reasonable value for this directive is one half the number
518 of drives that the Storage resource has rounded down. Doing so,
519 will leave the same number of drives for writing and will generally
520 avoid over committing drives and a deadlock.
523 \section{Bacula Enterprise 6.0.4}
525 \subsection{VMWare vSphere VADP Plugin}
527 The Bacula Enterprise vSphere plugin provides virtual
528 machine bare metal recovery, while the backup at the guest level simplify data
529 protection of critical applications.
531 The plugin integrates the VMware's Changed Block Tracking (CBT) technology to
532 ensure only blocks that have changed since the initial Full, and/or the last
533 Incremental or Differential Backup are sent to the current Incremental or
534 Differential backup stream to give you more efficient backups and reduced
537 \subsection{Oracle RMAN Plugin}
539 The Bacula Enterprise Oracle Plugin is designed to simplify the backup and
540 restore procedure of your Oracle Database instance, the backup administrator
541 don't need to learn about internals of Oracle backup techniques or write
542 complex scripts. The Bacula Enterprise Oracle plugin supports both dump and
543 Point In Time Recovery (PITR) with RMAN backup techniques.
546 \section{Bacula Enterprise 6.0.2}
548 To make Bacula function properly with multiple Autochanger definitions, in
549 the Director's configuration, you must adapt your {\bf bacula-dir.conf}
550 {\bf Storage} directives.
553 Each autochanger that you have defined in an {\bf Autochanger}
554 resource in the Storage daemon's {\bf bacula-sd.conf} file,
555 must have a corresponding {\bf Autochanger} resource defined
556 in the Director's {\bf bacula-dir.conf} file. Normally you will
557 already have a {\bf Storage} resource that points to the
558 Storage daemon's {\bf Autochanger} resource. Thus you need
559 only to change the name of the {\bf Storage} resource to
560 {\bf Autochanger}. In addition the {\bf Autochanger = yes}
561 directive is not needed in the Director's {\bf Autochanger}
562 resource, since the resource name is {\bf Autochanger}, the
563 Director already knows that it represents an autochanger.
566 In addition to the above change ({\bf Storage} to {\bf Autochanger}),
567 you must modify any additional {\bf Storage} resources that correspond
568 to devices that are part of the {\bf Autochanger} device.
569 Instead of the previous {\bf Autochanger = yes} directive they
570 should be modified to be {\bf Autochanger = xxx} where you
571 replace the {\bf xxx} with the name of the Autochanger.
574 For example, in the bacula-dir.conf file:
577 Autochanger { # New resource
579 Address = cibou.company.com
581 Password = "xxxxxxxxxx"
582 Device = LTO-Changer-1
584 Maximum Concurrent Jobs = 50
588 Name = Changer-1-Drive0
589 Address = cibou.company.com
591 Password = "xxxxxxxxxx"
592 Device = LTO4_1_Drive0
594 Maximum Concurrent Jobs = 5
595 Autochanger = Changer-1 # New directive
599 Name = Changer-1-Drive1
600 Address = cibou.company.com
602 Password = "xxxxxxxxxx"
603 Device = LTO4_1_Drive1
605 Maximum Concurrent Jobs = 5
606 Autochanger = Changer-1 # New directive
612 Note that Storage resources {\bf Changer-1-Drive0} and
613 {\bf Changer-1-Drive1} are not required since they make
614 up part of an autochanger, and normally, Jobs refer only
615 to the Autochanger resource.
616 However, by referring to those
617 Storage definitions in a Job, you will use only
618 the indicated drive. This is not normally what
619 you want to do, but it is very useful and often used
620 for reserving a drive for restores. See the Storage daemon
621 example .conf below and the use of {\bf AutoSelect = no}.
623 So, in summary, the changes are:
625 \item Change {\bf Storage} to {\bf Autochanger} in the LTO4 resource.
626 \item Remove the {\bf Autochanger = yes} from the {\bf Autochanger}
628 \item Change the {\bf Autochanger = yes} in each of the {\bf Storage}
629 device that belong to the {\bf Autochanger} to point to the
630 {\bf Autochanger} resource with for the example above the
631 directive {\bf Autochanger = LTO4}.
634 \section{Bacula Enterprise 6.0.0}
636 \subsection{Incomplete Jobs}
637 During a backup, if the Storage daemon experiences disconnection
638 with the File daemon during backup (normally a comm line problem
639 or possibly an FD failure), under conditions that the SD determines
640 to be safe it will make the failed job as Incomplete rather than
641 failed. This is done only if there is sufficient valid backup
642 data that was written to the Volume. The advantage of an Incomplete
643 job is that it can be restarted by the new bconsole {\bf restart}
644 command from the point where it left off rather than from the
645 beginning of the jobs as is the case with a cancel.
647 \subsection{The Stop Command}
648 Bacula has been enhanced to provide a {\bf stop} command,
649 very similar to the {\bf cancel} command with the main difference
650 that the Job that is stopped is marked as Incomplete so that
651 it can be restarted later by the {\bf restart} command where
652 it left off (see below). The {\bf stop} command with no
653 arguments, will like the cancel command, prompt you with the
654 list of running jobs allowing you to select one, which might
655 look like the following:
660 1: JobId=3 Job=Incremental.2012-03-26_12.04.26_07
661 2: JobId=4 Job=Incremental.2012-03-26_12.04.30_08
662 3: JobId=5 Job=Incremental.2012-03-26_12.04.36_09
663 Choose Job to stop (1-3): 2
664 2001 Job "Incremental.2012-03-26_12.04.30_08" marked to be stopped.
665 3000 JobId=4 Job="Incremental.2012-03-26_12.04.30_08" marked to be stopped.
668 \subsection{The Restart Command}
669 The new {\bf Restart command} allows console users to restart
670 a canceled, failed, or incomplete Job. For canceled and failed
671 Jobs, the Job will restart from the beginning. For incomplete
672 Jobs the Job will restart at the point that it was stopped either
673 by a stop command or by some recoverable failure.
676 If you enter the {\bf restart} command in bconsole, you will get the
681 You have the following choices:
686 Select termination code: (1-4):
689 If you select the {\bf All} option, you may see something like:
692 Select termination code: (1-4): 4
693 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
694 | jobid | name | starttime | type | level | jobfiles |
695 jobbytes | jobstatus |
696 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
697 | 1 | Incremental | 2012-03-26 12:15:21 | B | F | 0 |
699 | 2 | Incremental | 2012-03-26 12:18:14 | B | F | 350 |
701 | 3 | Incremental | 2012-03-26 12:18:30 | B | F | 0 |
703 | 4 | Incremental | 2012-03-26 12:18:38 | B | F | 331 |
705 +-------+-------------+---------------------+------+-------+----------+-----------+-----------+
706 Enter the JobId list to select:
709 Then you may enter one or more JobIds to be restarted, which may
710 take the form of a list of JobIds separated by commas, and/or JobId
711 ranges such as {\bf 1-4}, which indicates you want to restart JobIds
712 1 through 4, inclusive.
714 \subsection{Support for Exchange Incremental Backups}
715 The Bacula Enterprise version 6.0 VSS plugin now supports
716 Full and Incremental backups for Exchange. We strongly
717 recommend that you do not attempt to run Differential jobs with
718 Exchange as it is likely to produce a situation where restores
719 will no longer select the correct jobs, and thus the
720 Windows Exchange VSS writer will fail when applying log files.
721 There is a Bacula Systems Enterprise white paper that provides
722 the details of backup and restore of Exchange 2010 with the
726 Restores can be done while Exchange is running, but you
727 must first unmount (dismount in Microsoft terms) any database
728 you wish to restore and explicitly mark them to permit a
729 restore operation (see the white paper for details).
732 This project was funded by Bacula Systems and is available with the Bacula
735 \subsection{Support for MSSQL Block Level Backups}
736 With the addition of block level backup support to the
737 Bacula Enterprise VSS MSSQL component, you can now do
738 Differential backups in addition to Full backups.
739 Differential backups use Microsoft's partial block backup
740 (a block differencing or deduplication that we call Delta).
741 This partial block backup permits backing up only those
742 blocks that have changed. Database restores can be made while
743 the MSSQL server is running, but any databases selected for
744 restore will be automatically taken offline by the MSSQL
745 server during the restore process.
747 Incremental backups for MSSQL are not support by
748 Microsoft. We strongly recommend that you not perform Incremental
749 backups with MSSQL as they will probably produce a situation
750 where restore will no longer work correctly.
753 We are currently working on producing a white paper that will give more
754 details of backup and restore with MSSQL. One point to note is that during
755 a restore, you will normally not want to restore the {\bf master} database.
756 You must exclude it from the backup selections that you have made or the
760 It is possible to restore the {\bf master} database, but you must
761 first shutdown the MSSQL server, then you must perform special
762 recovery commands. Please see Microsoft documentation on how
763 to restore the master database.
766 This project was funded by Bacula Systems and is available with the Bacula
770 \subsection{Job Bandwidth Limitation}
772 The new {\bf Job Bandwidth Limitation} directive may be added to the File
773 daemon's and/or Director's configuration to limit the bandwidth used by a
774 Job on a Client. It can be set in the File daemon's conf file for all Jobs
775 run in that File daemon, or it can be set for each Job in the Director's
776 conf file. The speed is always specified in bytes per second.
782 Working Directory = /some/path
783 Pid Directory = /some/path
785 Maximum Bandwidth Per Job = 5Mb/s
789 The above example would cause any jobs running with the FileDaemon to not
790 exceed 5 megabytes per second of throughput when sending data to the
791 Storage Daemon. Note, the speed is always specified in bytes per second
792 (not in bits per second), and the case (upper/lower) of the specification
793 characters is ignored (i.e. 1MB/s = 1Mb/s).
795 You may specify the following speed parameter modifiers:
796 k/s (1,000 bytes per second), kb/s (1,024 bytes per second),
797 m/s (1,000,000 bytes per second), or mb/s (1,048,576 bytes per second).
803 FileSet = FS_localhost
806 Maximum Bandwidth = 5Mb/s
811 The above example would cause Job \texttt{localhost-data} to not exceed 5MB/s
812 of throughput when sending data from the File daemon to the Storage daemon.
814 A new console command \texttt{setbandwidth} permits to set dynamically the
815 maximum throughput of a running Job or for future jobs of a Client.
818 * setbandwidth limit=1000 jobid=10
821 Please note that the value specified for the \texttt{limit} command
822 line parameter is always in units of 1024 bytes (i.e. the number
823 is multiplied by 1024 to give the number of bytes per second). As
824 a consequence, the above limit of 1000 will be interpreted as a
825 limit of 1000 * 1024 = 1,024,000 bytes per second.
828 This project was funded by Bacula Systems and is available in
829 the Enterprise Edition.
831 \subsection{Incremental/Differential Block Level Difference Backup}
833 The new \texttt{delta} Plugin is able to compute and apply signature-based file
834 differences. It can be used to backup only changes in a big binary file like
835 Outlook PST, VirtualBox/VMware images or database files.
837 It supports both Incremental and Differential backups and stores signatures
838 database in the File Daemon working directory. This plugin is available on all
839 platform including Windows 32 and 64bit.
841 Accurate option should be turned on in the Job resource.
854 Plugin = "delta:/home/eric/.VirtualBox/HardDisks/lenny-i386.vdi"
859 Name = DeltaFS-Include
867 # Use the Options{} filtering and options
868 File = /home/user/.VirtualBox
874 Please contact Bacula Systems support to get Delta Plugin specific
878 This project was funded by Bacula Systems and is available with the Bacula
881 \subsection{SAN Shared Tape Storage Plugin}
883 The problem with backing up multiple servers at the same time to the
884 same tape library (or autoloader) is that if both servers access the
885 same tape drive same time, you will very likely get data corruption.
886 This is where the Bacula Systems shared tape storage plugin comes into play. The
887 plugin ensures that only one server at a time can connect to each device
888 (tape drive) by using the SPC-3 SCSI reservation protocol. Please contact
889 Bacula Systems support to get SAN Shared Storage Plugin specific
893 This project was funded by Bacula Systems and is available with Bacula
896 \subsection{Advanced Autochanger Usage}
898 The new \texttt{Shared Storage} Director's directive is a Bacula Enterprise
899 feature that allows you to share volumes between different Storage
900 resources. This directive should be used \textbf{only} if all \texttt{Media
901 Type} are correctly set across all Devices.
903 The \texttt{Shared Storage} directive should be used when using the SAN
904 Shared Storage plugin or when accessing from the Director Storage resources
905 directly to Devices of an Autochanger.
907 When sharing volumes between different Storage resources, you will
908 need also to use the \texttt{reset-storageid} script before using the
909 \texttt{update slots} command. This script can be scheduled once a day in
913 $ /opt/bacula/scripts/reset-storageid MediaType StorageName
915 * update slots storage=StorageName drive=0
918 Please contact Bacula Systems support to get help on this advanced
922 This project was funded by Bacula Systems and is available with Bacula
926 \textbf{The reset-storageid procedure is no longer required when using
927 the appropriate Autochanger configuration in the Director configuration
930 \subsection{Enhancement of the NDMP Plugin}
932 The previous NDMP Plugin 4.0 was fully supporting only the NetApp hardware, the
933 new NDMP Plugin should now be able to support all NAS vendors with the
934 \texttt{volume\_format} plugin command option.
936 On some NDMP devices such as Celera or Blueray, the administrator can use arbitrary
937 volume structure name, ex:
941 /rootvolume/volume_tmp
945 The NDMP plugin should be aware of the structure organization in order to
946 detect if the administrator wants to restore in a new volume
947 (\texttt{where=/dev/vol\_tmp}) or inside a subdirectory of the targeted volume
948 (\texttt{where=/tmp}).
955 Plugin = "ndmp:host=nasbox user=root pass=root file=/dev/vol1 volume_format=/dev/"
960 Please contact Bacula Systems support to get NDMP Plugin specific
964 This project was funded by Bacula Systems and is available with the Bacula
967 \subsection{Always Backup a File}
969 When the Accurate mode is turned on, you can decide to always backup a file
970 by using then new {\bf A} Accurate option in your FileSet. For example:
993 This project was funded by Bacula Systems based on an idea of James Harper and
994 is available with the Bacula Enterprise Edition.
996 \subsection{Setting Accurate Mode During at Runtime}
998 You are now able to specify the Accurate mode on the \texttt{run} command and
999 in the Schedule resource.
1002 * run accurate=yes job=Test
1008 Run = Full 1st sun at 23:05
1009 Run = Differential accurate=yes 2nd-5th sun at 23:05
1010 Run = Incremental accurate=no mon-sat at 23:05
1014 It can allow you to save memory and and CPU resources on the catalog server in
1018 These advanced tuning options are available with the Bacula Enterprise Edition.
1020 % Common with community
1021 \subsection{Additions to RunScript variables}
1022 You can have access to JobBytes, JobFiles and Director name using \%b, \%F and \%D
1023 in your runscript command. The Client address is now available through \%h.
1026 RunAfterJob = "/bin/echo Job=%j JobBytes=%b JobFiles=%F ClientAddress=%h Dir=%D"
1029 \subsection{LZO Compression}
1031 LZO compression was added in the Unix File Daemon. From the user point of view,
1032 it works like the GZIP compression (just replace {\bf compression=GZIP} with
1033 {\bf compression=LZO}).
1038 Options { compression=LZO }
1044 LZO provides much faster compression and decompression speed but lower
1045 compression ratio than GZIP. It is a good option when you backup to disk. For
1046 tape, the built-in compression may be a better option.
1048 LZO is a good alternative for GZIP1 when you don't want to slow down your
1049 backup. On a modern CPU it should be able to run almost as fast as:
1052 \item your client can read data from disk. Unless you have very fast disks like
1053 SSD or large/fast RAID array.
1054 \item the data transfers between the file daemon and the storage daemon even on
1058 Note that bacula only use one compression level LZO1X-1.
1061 The code for this feature was contributed by Laurent Papier.
1063 \subsection{New Tray Monitor}
1065 Since the old integrated Windows tray monitor doesn't work with
1066 recent Windows versions, we have written a new Qt Tray Monitor that is available
1067 for both Linux and Windows. In addition to all the previous features,
1068 this new version allows you to run Backups from
1069 the tray monitor menu.
1071 \bsysimageH{tray-monitor}{New tray monitor}{figbs6:traymonitor}
1073 \bsysimageH{tray-monitor1}{Run a Job through the new tray monitor}{figbs6:traymonitor1}
1077 To be able to run a job from the tray monitor, you need to
1078 allow specific commands in the Director monitor console:
1083 CommandACL = status, .clients, .jobs, .pools, .storage, .filesets, .messages, run
1084 ClientACL = *all* # you can restrict to a specific host
1096 This project was funded by Bacula Systems and is available with Bacula
1097 the Enterprise Edition and the Community Edition.
1099 \subsection{Purge Migration Job}
1101 The new {\bf Purge Migration Job} directive may be added to the Migration
1102 Job definition in the Director's configuration file. When it is enabled
1103 the Job that was migrated during a migration will be purged at
1104 the end of the migration job.
1109 Name = "migrate-job"
1112 Client = localhost-fd
1113 FileSet = "Full Set"
1115 Storage = DiskChanger
1117 Selection Type = Job
1118 Selection Pattern = ".*Save"
1120 Purge Migration Job = yes
1126 This project was submitted by Dunlap Blake; testing and documentation was funded
1129 \subsection{Changes in the Pruning Algorithm}
1131 We rewrote the job pruning algorithm in this version. Previously, in some users
1132 reported that the pruning process at the end of jobs was very long. It should
1133 not be longer the case. Now, Bacula won't prune automatically a Job if this
1134 particular Job is needed to restore data. Example:
1137 JobId: 1 Level: Full
1138 JobId: 2 Level: Incremental
1139 JobId: 3 Level: Incremental
1140 JobId: 4 Level: Differential
1141 .. Other incrementals up to now
1144 In this example, if the Job Retention defined in the Pool or in the Client
1145 resource causes that Jobs with Jobid in 1,2,3,4 can be pruned, Bacula will
1146 detect that JobId 1 and 4 are essential to restore data at the current state
1147 and will prune only JobId 2 and 3.
1149 \texttt{Important}, this change affect only the automatic pruning step after a
1150 Job and the \texttt{prune jobs} Bconsole command. If a volume expires after the
1151 \texttt{VolumeRetention} period, important jobs can be pruned.
1153 \subsection{Ability to Verify any specified Job}
1154 You now have the ability to tell Bacula which Job should verify instead of
1155 automatically verify just the last one.
1157 This feature can be used with VolumeToCatalog, DiskToCatalog and Catalog level.
1159 To verify a given job, just specify the Job jobid in argument when starting the
1162 *run job=VerifyVolume jobid=1 level=VolumeToCatalog
1164 JobName: VerifyVolume
1165 Level: VolumeToCatalog
1166 Client: 127.0.0.1-fd
1168 Pool: Default (From Job resource)
1169 Storage: File (From Job resource)
1170 Verify Job: VerifyVol.2010-09-08_14.17.17_03
1171 Verify List: /tmp/regress/working/VerifyVol.bsr
1172 When: 2010-09-08 14:17:31
1174 OK to run? (yes/mod/no):
1178 This project was funded by Bacula Systems and is available with Bacula
1179 Enterprise Edition and Community Edition.