5 \label{NewFeaturesChapter}
6 \index[general]{New Features}
8 This chapter presents the new features added to the development 2.5.x
9 versions to be released as Bacula version 3.0.0 near the end of 2008.
12 \index[general]{Copy Jobs}
13 A new {\bf Copy} job type has been implemented. It is essentially
14 identical to the existing Migration feature with the exception that
15 the Job that is copied is left unchanged. This essentially creates
16 two identical copies of the same backup. The Copy Job runs without
17 using the File daemon by copying the data from the old backup Volume to
18 a different Volume in a different Pool. See the Migration documentation
19 for additional details.
21 \section{Virtual Backup (Vbackup)}
22 \index[general]{Virtual Backup}
23 \index[general]{Vbackup}
25 Bacula's virtual backup feature is often called Synthetic Backup or
26 Consolidation in other backup products. It permits you to consolidate
27 the previous Full backup plus the most recent Differential backup and any
28 subsequent Incremental backups into a new Full backup. This is accomplished
29 without contacting the client by reading the previous backup data and
30 writing it to a volume in a different pool.
32 In some respects the Vbackup feature works similar to a Migration job, in
33 that Bacula normally reads the data from the pool specified in the
34 Job resource, and writes it to the {\bf Next Pool} specified in the
35 Job resource. The input Storage resource and the Output Storage resource
38 The Vbackup is enabled on a Job by Job in the Job resource by specifying
39 a level of {\bf VirtualFull}.
41 A typical Job resource definition might look like the following:
55 # Default pool definition
59 Recycle = yes # Bacula can automatically recycle Volumes
60 AutoPrune = yes # Prune expired volumes
61 Volume Retention = 365d # one year
69 Recycle = yes # Bacula can automatically recycle Volumes
70 AutoPrune = yes # Prune expired volumes
71 Volume Retention = 365d # one year
75 # Definition of file storage device
82 Maximum Concurrent Jobs = 5
85 # Definition of DDS Virtual tape disk storage device
88 Address = localhost # N.B. Use a fully qualified name here
91 Media Type = DiskChangerMedia
92 Maximum Concurrent Jobs = 4
97 Then in bconsole or via a Run schedule, you would run the job as:
100 run job=MyBackup level=Full
101 run job=MyBackup level=Incremental
102 run job=MyBackup level=Differential
103 run job=MyBackup level=Incremental
104 run job=MyBackup level=Incremental
107 So providing there were changes between each of those jobs, you would end up
108 with a Full backup, a Differential, which includes the first Incremental
109 backup, then two Incremental backups. All the above jobs would be written to
110 the {\bf Default} pool.
112 To consolidate those backups into a new Full backup, you would run the
116 run job=MyBackup level=VirtualFull
119 And it would produce a new Full backup without using the client, and the output
120 would be written to the {\bf Full} Pool which uses the Diskchanger Storage.
122 \section{TLS Authentication}
123 \index[general]{TLS Authentication}
124 In Bacula version 2.5.x and later, in addition to the normal Bacula
125 CRAM-MD5 authentication that is used to authenticate each Bacula
126 connection, you can specify that you want TLS Authentication as well,
127 which will provide more secure authentication.
129 This new feature uses Bacula's existing TLS code (normally used for
130 communications encryption) to do authentication. To use it, you must
131 specify all the TLS directives normally used to enable communications
132 encryption (TLS Enable, TLS Verify Peer, TLS Certificate, ...) and
136 TLS Authenticate = yes
139 in the main daemon configuration resource (Director for the Director,
140 Client for the File daemon, and Storage for the Storage daemon).
142 When {\bf TLS Authenticate} is enabled, after doing the CRAM-MD5
143 authentication, Bacula will do the normal TLS authentication, then TLS
144 encryption will be turned off.
146 If you want to encrypt communications data, do not turn on {\bf TLS
149 \section{bextract non-portable Win32 data}
150 \index[general]{bextract handles Win32 non-portable data}
151 {\bf bextract} has been enhanced to be able to restore
152 non-portable Win32 data to any OS. Previous versions were
153 unable to restore non-portable Win32 data to machines that
154 did not have the Win32 BackupRead and BackupWrite API calls.
156 \section{State File updated at Job Termination}
157 \index[general]{State File}
158 In previous versions of Bacula, the state file, which provides a
159 summary of previous jobs run in the {\bf status} command output was
160 updated only when Bacula terminated, thus if the daemon crashed, the
161 state file might not contain all the run data. This version of
162 the Bacula daemons updates the state file on each job termination.
164 \section{MaxFullInterval}
165 \index[general]{MaxFullInterval}
166 The new Job resource directive {\bf Max Full Interval = \lt{}time-interval\gt{}}
167 can be used to specify the maximum time interval between {\bf Full} backup
168 jobs. When a job starts, if the time since the last Full backup is
169 greater than the specified interval, and the job would normally be an
170 {\bf Incremental} or {\bf Differential}, it will be automatically
171 upgraded to a {\bf Full} backup.
173 \section{MaxDiffInterval}
174 \index[general]{MaxDiffInterval}
175 The new Job resource directive {\bf Max Diff Interval = \lt{}time-interval\gt{}}
176 can be used to specify the maximum time interval between {\bf Differential} backup
177 jobs. When a job starts, if the time since the last Differential backup is
178 greater than the specified interval, and the job would normally be an
179 {\bf Incremental}, it will be automatically
180 upgraded to a {\bf Differential} backup.
182 \section{No Dump Flag}
183 \index[general]{MaxDiffInterval}
184 On FreeBSD systems, each file has a {\bf no dump flag} that can be set
185 by the user, and when it is set it is an indication to backup programs
186 to not backup that particular file. This version of Bacula contains a
187 new Options directive within a FileSet resource, which instructs Bacula to
188 obey this flag. The new directive is:
191 Honor No Dump Flag = yes|no
194 The default value is {\bf no}.
197 \section{Duplicate Job Control}
198 \index[general]{Duplicate Jobs}
199 The new version of Bacula provides four new directives that
200 give additional control over what Bacula does if duplicate jobs
201 are started. A duplicate job in the sense we use it here means
202 a second or subsequent job with the same name starts. This
203 happens most frequently when the first job runs longer than expected because no
206 The four directives each take as an argument a yes or no value and
207 are specified in the Job resource.
212 \item [Allow Duplicate Jobs = \lt{}yes|no\gt{}]
213 If this directive is enabled duplicate jobs will be run. If
214 the directive is set to {\bf no} (default) then only one job of a given name
215 may run at one time, and the action that Bacula takes to ensure only
216 one job runs is determined by the other directives (see below).
218 \item [Allow Higher Duplicates = \lt{}yes|no\gt{}]
219 If this directive is set to {\bf yes} (default) the job with a higher
220 priority (lower priority number) will be permitted to run. If the
221 priorities of the two jobs are the same, the outcome is determined by
222 other directives (see below).
224 \item [Cancel Queued Duplicates = \lt{}yes|no\gt{}]
225 If this directive is set to {\bf yes} (default) any job that is
226 already queued to run but not yet running will be canceled.
228 \item [Cancel Running Duplicates = \lt{}yes|no\gt{}]
229 If this directive is set to {\bf yes} any job that is already running
230 will be canceled. The default is {\bf no}.
235 \index[general]{IgnoreDir}
236 The {\bf Ignore Dir = \lt{}filename\gt{}} is a new directive that can be added to the Include
237 section of the FileSet resource. If the specified
238 filename is found on the Client in any directory to be backed up,
239 the whole directory will be ignored (not backed up).
243 # List of files to be backed up
251 IgnoreDir = .excludeme
256 But in /home, there may be hundreds of directories of users and some
257 people want to indicate that they don't want to have certain
258 directories backed up. For example, with the above FileSet, if
259 the user or sysadmin creates a file named {\bf .excludeme} in
260 specific directories, such as
263 /home/user/www/cache/.excludeme
264 /home/user/temp/.excludeme
267 then Bacula will not backup the two directories named:
277 \index[general]{Accurate Backup}
278 As with most other backup programs, Bacula decides what files to backup
279 for Incremental and Differental backup by comparing the change (st\_ctime)
280 and modification (st\_mtime) times of the file to the time the last backup completed.
281 If one of those two times is later than the last backup time, then the file
282 will be backed up. This does not, however, permit tracking what files have
283 been deleted and will miss any file with an old time that may have been
284 restored or moved on the client filesystem.
286 If the {\bf Accurate = \lt{}yes|no\gt{}} directive is enabled (default no) in the
287 Job resource, the job will be run as an Accurate Job. For a {\bf Full}
288 backup, there is no difference, but for {\bf Differential} and {\bf Incremental}
289 backups, the Director will send a list of all previous files backed up, and the
290 File daemon will use that list to determine if any new files have been added or
291 or moved and if any files have been deleted. This allows Bacula to make an accurate
292 backup of your system to that point in time so that if you do a restore, it
293 will restore your system exactly. The downside of using Accurate backup is that
294 it requires significantly more resources (CPU and memory) on both the Director and
295 the Client machine to create the list of previous files backed up, to send that
296 list to the File daemon, and do comparisons on the File daemon between every file
299 \section{Bacula Plugins}
300 \index[general]{Plugin}
301 Support for shared object plugins has been implemented in the Linux
302 (and Unix) File daemon. The API will be documented separately in
303 the Developer's Guide or in a new document. For the moment, there is
304 a single plugin named {\bf bpipe} that allows an external program to
305 get control to backup and restore a file.
307 Plugins are also planned (partially implemented) in the Director and the
308 Storage daemon. Also we plan (at some point) to port (partially implemented)
309 the plugin code to Win32 machines.
312 \section{Display Autochanger Content}
313 \index[general]{StatusSlots}
315 The {\bf status slots storage=\lt{}storage-name\gt{}} command displays autochanger content.
319 Slot | Volume Name | Status | Media Type | Pool | Loaded |
320 ------+-----------------+----------+-------------------+----------------+---------|
321 1 | 00001 | Append | DiskChangerMedia | Default | 0 |
322 2 | 00002 | Append | DiskChangerMedia | Default | 0 |
323 3*| 00003 | Append | DiskChangerMedia | Scratch | 0 |
328 If you an asterisk ({\bf *}) appears after the slot number, you must run an {\bf update slots}
329 command to synchronize autochanger content with your catalog.
331 \section{Miscellaneous}
332 \index[general]{Misc New Features}
334 \item [Virtual Tape Emulation]
335 We now have a Virtual Tape emulator that allows us to run though 99.9\% of the
336 tape code but actually reading and writing to a disk file. This feature is most
338 It is enabled by using {\bf Device Type = vtape} in the Storage daemon's Device
339 directive. This feature is only implemented on Linux machines.
341 \item [Bat Enhancements]
342 Bat (the Bacula Administration Tool) GUI program has been significantly
343 enhanced and stabilized. In particular, there are new table based status
344 commands; it can now be easily localized using Qt4 Linguist.
346 The Bat communications protocol has been significantly enhanced to improve
349 \item [RunScript Enhancements]
350 The {\bf RunScript} resource has been enhanced to permit multiple
351 commands per RunScript. Simply specify multiple {\bf Command} directives
354 A new Client RunScript {\bf RunsWhen} keyword of {\bf AfterVSS} has been implemented, which
355 runs the command after the Volume Shadow Copy has been made.
357 Console commands can be specified within a RunScript by using:
358 {\bf Console = \lt{}command\gt{}}, however, this command has not been
359 carefully tested and debugged and is known to easily crash the Director.
360 We would appreciate feedback. Due to the recursive nature of this command, we
361 may remove it before the final release.
363 \item [Status Enhancements]
364 The bconsole {\bf status dir} output has been enhanced to indicate
365 Storage daemon job spooling and despooling activity.