1%% 2%% 3 4\chapter{Configuring the Director} 5\label{DirectorChapter} 6\index[general]{Director!Configuring the} 7\index[general]{Configuring the Director} 8 9Of all the configuration files needed to run {\bf Bacula}, the Director's is 10the most complicated, and the one that you will need to modify the most often 11as you add clients or modify the FileSets. 12 13For a general discussion of configuration files and resources including the 14data types recognized by {\bf Bacula}. Please see the 15\ilink{Configuration}{ConfigureChapter} chapter of this manual. 16 17\section{Director Resource Types} 18\index[general]{Types!Director Resource} 19\index[general]{Director Resource Types} 20 21Director resource type may be one of the following: 22 23Job, JobDefs, Client, Storage/Autochange, Catalog, Schedule, FileSet, Pool, 24Director, or Messages. We present them here in the most logical order for 25defining them: 26 27Note, everything revolves around a job and is tied to a job in one 28way or another. 29 30\begin{itemize} 31\item 32 \ilink{Director}{DirectorResource4} -- to define the Director's 33 name and its access password used for authenticating the Console program. 34 Only a single Director resource definition may appear in the Director's 35 configuration file. If you have either {\bf /dev/random} or {\bf bc} on your 36 machine, Bacula will generate a random password during the configuration 37 process, otherwise it will be left blank. 38\item 39 \ilink{Job}{JobResource} -- to define the backup/restore Jobs 40 and to tie together the Client, FileSet and Schedule resources to be used 41 for each Job. Normally, you will Jobs of different names corresponding 42 to each client (i.e. one Job per client, but a different one with a different name 43 for each client). 44\item 45 \ilink{JobDefs}{JobDefsResource} -- optional resource for 46 providing defaults for Job resources. 47\item 48 \ilink{Schedule}{ScheduleResource} -- to define when a Job is to 49 be automatically run by {\bf Bacula's} internal scheduler. You 50 may have any number of Schedules, but each job will reference only 51 one. 52\item 53 \ilink{FileSet}{FileSetResource} -- to define the set of files 54 to be backed up for each Client. You may have any number of 55 FileSets but each Job will reference only one. 56\item 57 \ilink{Client}{ClientResource2} -- to define what Client is to be 58 backed up. You will generally have multiple Client definitions. Each 59 Job will reference only a single client. 60\item 61 \ilink{Storage}{StorageResource2} (or Autochanger) -- to define on what 62 physical device the Volumes should be mounted. The keywords Storage 63 and Autochanger are interchangable. You may have one or more 64 Storage/Autochanger definitions. 65 66\item 67 \ilink{Pool}{PoolResource} -- to define the pool of Volumes 68 that can be used for a particular Job. Most people use a 69 single default Pool. However, if you have a large number 70 of clients or volumes, you may want to have multiple Pools. 71 Pools allow you to restrict a Job (or a Client) to use 72 only a particular set of Volumes. 73 74\item 75 \ilink{Catalog}{CatalogResource} -- to define in what database to 76 keep the list of files and the Volume names where they are backed up. 77 Most people only use a single catalog. However, if you want to 78 scale the Director to many clients, multiple catalogs can be helpful. 79 Multiple catalogs require a bit more management because in general 80 you must know what catalog contains what data. Currently, all 81 Pools are defined in each catalog. This restriction will be removed 82 in a later release. 83\item 84 \ilink{Console}{ConsoleResource1} -- to define which the administrator 85 or user can use to interact with the Director. 86 87 \item 88 \ilink{Counter}{CounterResource} -- to define a counter variable that 89 can be accessed by variable expansion used for creating Volume labels. 90 91\item 92 \ilink{Messages}{MessagesChapter} -- to define where error and 93 information messages are to be sent or logged. You may define 94 multiple different message resources and hence direct particular 95 classes of messages to different users or locations (files, ...). 96\end{itemize} 97 98\section{The Director Resource} 99\label{DirectorResource4} 100\index[general]{Director Resource} 101\index[general]{Resource!Director} 102 103The Director resource defines the attributes of the Directors running on the 104network. In the current implementation, there is only a single Director 105resource, but the final design will contain multiple Directors to maintain 106index and media database redundancy. 107 108\begin{description} 109 110\item [Director] 111 \index[dir]{Director} 112 Start of the Director resource. One and only one director resource must be 113supplied. 114 115\item [Name = \lt{}name\gt{}] 116 \index[dir]{Name} 117 \index[dir]{Directive!Name} 118 The director name used by the system administrator. This directive is 119required. 120 121\item [Description = \lt{}text\gt{}] 122 \index[dir]{Description} 123 \index[dir]{Directive!Description} 124 The text field contains a description of the Director that will be displayed 125in the graphical user interface. This directive is optional. 126 127\item [Password = \lt{}UA-password\gt{}] 128 \index[dir]{Password} 129 \index[dir]{Directive!Password} 130 Specifies the password that must be supplied for the default Bacula 131 Console to be authorized. The same password must appear in the {\bf 132 Director} resource of the Console configuration file. For added 133 security, the password is never passed across the network but instead a 134 challenge response hash code created with the password. This directive 135 is required. If you have either {\bf /dev/random} or {\bf bc} on your 136 machine, Bacula will generate a random password during the configuration 137 process, otherwise it will be left blank and you must manually supply 138 it. 139 140 The password is plain text. It is not generated through any special 141 process but as noted above, it is better to use random text for 142 security reasons. 143 144\item [Messages = \lt{}Messages-resource-name\gt{}] 145 \index[dir]{Messages} 146 \index[dir]{Directive!Messages} 147 The messages resource specifies where to deliver Director messages that are 148 not associated with a specific Job. Most messages are specific to a job and 149 will be directed to the Messages resource specified by the job. However, 150 there are a few messages that can occur when no job is running. This 151 directive is required. 152 153\item [Working Directory = \lt{}Directory\gt{}] 154 \index[dir]{Working Directory} 155 \index[dir]{Directive!Working Directory} 156 This directive is mandatory and specifies a directory in which the Director 157 may put its status files. This directory should be used only by Bacula but 158 may be shared by other Bacula daemons. However, please note, if this 159 directory is shared with other Bacula daemons (the File daemon and Storage 160 daemon), you must ensure that the {\bf Name} given to each daemon is 161 unique so that the temporary filenames used do not collide. By default 162 the Bacula configure process creates unique daemon names by postfixing them 163 with -dir, -fd, and -sd. Standard shell expansion of the {\bf 164 Directory} is done when the configuration file is read so that values such 165 as {\bf \$HOME} will be properly expanded. This directive is required. 166 The working directory specified must already exist and be 167 readable and writable by the Bacula daemon referencing it. 168 169 If you have specified a Director user and/or a Director group on your 170 ./configure line with {\bf {-}{-}with-dir-user} and/or 171 {\bf {-}{-}with-dir-group} the Working Directory owner and group will 172 be set to those values. 173 174\item [Pid Directory = \lt{}Directory\gt{}] 175 \index[dir]{Pid Directory} 176 \index[dir]{Directive!Pid Directory} 177 This directive is mandatory and specifies a directory in which the Director 178 may put its process Id file. The process Id file is used to shutdown 179 Bacula and to prevent multiple copies of Bacula from running simultaneously. 180 Standard shell expansion of the {\bf Directory} is done when the 181 configuration file is read so that values such as {\bf \$HOME} will be 182 properly expanded. 183 184 The PID directory specified must already exist and be 185 readable and writable by the Bacula daemon referencing it 186 187 Typically on Linux systems, you will set this to: {\bf /var/run}. If you are 188 not installing Bacula in the system directories, you can use the {\bf Working 189 Directory} as defined above. This directive is required. 190 191\item [Scripts Directory = \lt{}Directory\gt{}] 192 \index[dir]{Scripts Directory} 193 \index[dir]{Directive!Scripts Directory} 194 This directive is optional and, if defined, specifies a directory in 195 which the Director and the Storage daemon will look for many of the 196 scripts that it needs to use during particular operations such as 197 starting/stopping, the mtx-changer script, tape alerts, as well as 198 catalog updates. 199 This directory may be shared by other Bacula daemons. 200 Standard shell expansion of the directory is done when the configuration 201 file is read so that values such as {\bf \$HOME} will be properly 202 expanded. 203 204\item [QueryFile = \lt{}Path\gt{}] 205 \index[dir]{QueryFile} 206 \index[dir]{Directive!QueryFile} 207 This directive is mandatory and specifies a directory and file in which 208 the Director can find the canned SQL statements for the {\bf Query} 209 command of the Console. Standard shell expansion of the {\bf Path} is 210 done when the configuration file is read so that values such as {\bf 211 \$HOME} will be properly expanded. This directive is required. 212 213\item [Heartbeat Interval = \lt{}time-interval\gt{}] 214 \index[dir]{Heartbeat Interval} 215 \index[dir]{Directive!Heartbeat} 216 This directive is optional and if specified will cause the Director to 217 set a keepalive interval (heartbeat) in seconds on each of the sockets 218 it opens for the Client resource. This value will override any 219 specified at the Director level. It is implemented only on systems 220 (Linux, ...) that provide the {\bf setsockopt} TCP\_KEEPIDLE function. 221 The default vaule is 300 seconds. 222 223\label{DirMaxConJobs} 224\item [Maximum Concurrent Jobs = \lt{}number\gt{}] 225 \index[dir]{Maximum Concurrent Jobs} 226 \index[dir]{Directive!Maximum Concurrent Jobs} 227 \index[general]{Simultaneous Jobs} 228 \index[general]{Concurrent Jobs} 229 where \lt{}number\gt{} is the maximum number of total Director Jobs that 230 should run concurrently. The default is set to 20, but you may set it 231 to a larger number. Every valid connection to any daemon (Director, 232 File daemon, or Storage daemon) results in a Job. This includes 233 connections from {\bf bconsole}. Thus the number of concurrent Jobs 234 must, in general, be greater than the maximum number of Jobs that you 235 wish to actually run. 236 237 In general, increasing the number of Concurrent Jobs increases the total 238 through put of Bacula, because the simultaneous Jobs can all feed data 239 to the Storage daemon and to the Catalog at the same time. However, 240 keep in mind, that the Volume format becomes more complicated with 241 multiple simultaneous jobs, consequently, restores may take slightly 242 longer if Bacula must sort through interleaved volume blocks from 243 multiple simultaneous jobs. Though normally unnecessary, interleaved 244 job data can be avoided by having each simultaneous job write to a 245 different volume or by using data spooling, which will first spool the 246 data to disk simultaneously, then write one spool file at a time to the 247 volume thus avoiding excessive interleaving of the different job blocks. 248 249\item [FD Connect Timeout = \lt{}time\gt{}] 250 \index[dir]{FD Connect Timeout} 251 \index[dir]{Directive!FD Connect Timeout} 252 where {\bf time} is the time that the Director should continue 253 attempting to contact the File daemon to start a job, and after which 254 the Director will cancel the job. The default is 3 minutes. 255 256\item [SD Connect Timeout = \lt{}time\gt{}] 257 \index[dir]{SD Connect Timeout} 258 \index[dir]{Directive!SD Connect Timeout} 259 where {\bf time} is the time that the Director should continue 260 attempting to contact the Storage daemon to start a job, and after which 261 the Director will cancel the job. The default is 30 minutes. 262 263\item [DirAddresses = \lt{}IP-address-specification\gt{}] 264 \index[dir]{DirAddresses} 265 \index[dir]{Address} 266 \index[general]{Address} 267 \index[dir]{Directive!DirAddresses} 268 Specify the ports and addresses on which the Director daemon will listen 269 for Bacula Console connections. Probably the simplest way to explain 270 this is to show an example: 271 272\footnotesize 273\begin{verbatim} 274 DirAddresses = { 275 ip = {addr = 1.2.3.4; port = 1205;} 276 ipv4 = { 277 addr = 1.2.3.4; port = http;} 278 ipv6 = { 279 addr = 1.2.3.4; 280 port = 1205; 281 } 282 ip = { 283 addr = 1.2.3.4 284 port = 1205 285 } 286 ip = {addr = 1.2.3.4 } 287 ip = {addr = 201:220:222::2 } 288 ip = { 289 addr = bluedot.thun.net 290 } 291} 292\end{verbatim} 293\normalsize 294 295where ip, ip4, ip6, addr, and port are all keywords. Note, that the address 296can be specified as either a dotted quadruple, or IPv6 colon notation, or as 297a symbolic name (only in the ip specification). Also, port can be specified 298as a number or as the mnemonic value from the /etc/services file. If a port 299is not specified, the default will be used. If an ip section is specified, 300the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then 301only IPv4 resolutions will be permitted, and likewise with ip6. 302 303Please note that if you use the DirAddresses directive, you must 304not use either a DirPort or a DirAddress directive in the same 305resource. 306 307\item [DirPort = \lt{}port-number\gt{}] 308 \index[dir]{DirPort} 309 \index[dir]{Directive!DirPort} 310 Specify the port (a positive integer) on which the Director daemon will 311 listen for Bacula Console connections. This same port number must be 312 specified in the Director resource of the Console configuration file. The 313 default is 9101, so normally this directive need not be specified. This 314 directive should not be used if you specify DirAddresses (N.B plural) 315 directive. 316 317\item [DirAddress = \lt{}IP-Address\gt{}] 318 \index[dir]{DirAddress} 319 \index[dir]{Directive!DirAddress} 320 This directive is optional, but if it is specified, it will cause the 321 Director server (for the Console program) to bind to the specified {\bf 322 IP-Address}, which is either a domain name or an IP address specified as a 323 dotted quadruple in string or quoted string format. If this directive is 324 not specified, the Director will bind to any available address (the 325 default). Note, unlike the DirAddresses specification noted above, this 326 directive only permits a single address to be specified. This directive 327 should not be used if you specify a DirAddresses (N.B. plural) directive. 328 329\item [DirSourceAddress = \lt{}IP-Address\gt{}] 330 \index[fd]{DirSourceAddress} 331 \index[fd]{Directive!DirSourceAddress} 332 This record is optional, and if it is specified, it will cause the Director 333 server (when initiating connections to a storage or file daemon) to source 334 its connections from the specified address. Only a single IP address may be 335 specified. If this record is not specified, the Director server will source 336 its outgoing connections according to the system routing table (the default). 337 338\item[Statistics Retention = \lt{}time\gt{}] 339 \index[dir]{StatisticsRetention} 340 \index[dir]{Directive!StatisticsRetention} 341 \label{PruneStatistics} 342 343 The \texttt{Statistics Retention} directive defines the length of time that 344 Bacula will keep statistics job records in the Catalog database after the 345 Job End time. (In \texttt{JobHistory} table) When this time period expires, 346 and if user runs \texttt{prune stats} command, Bacula will prune (remove) 347 Job records that are older than the specified period. 348 349 Theses statistics records aren't use for restore purpose, but mainly for 350 capacity planning, billings, etc. See \ilink{Statistics chapter}{TO-BE-REPLACED} for 351 additional information. 352 353 See the \ilink{Configuration chapter}{Time} of this manual for additional 354 details of time specification. 355 356 The default is 5 years. 357 358\item[VerId = \lt{}string\gt{}] 359 \index[dir]{Directive!VerId} 360 where \lt{}string\gt{} is an identifier which can be used for support purpose. 361 This string is displayed using the \texttt{version} command. 362 363\item[MaximumConsoleConnections = \lt{}number\gt{}] 364 \index[dir]{MaximumConsoleConnections} 365 \index[dir]{Directive!MaximumConsoleConnections} 366 \index[dir]{Console} 367 where \lt{}number\gt{} is the maximum number of Console Connections that 368 could run concurrently. The default is set to 20, but you may set it to a 369 larger number. 370 371\label{Director:Director:MaximumReloadRequests} 372 \item[MaximumReloadRequests = \lt{}number\gt{}] 373\index[dir]{MaximumReloadRequests} 374\index[dir]{Directive!MaximumReloadRequests} 375\index[dir]{Console} 376 377Where \lt{}number\gt{} is the maximum number of \texttt{reload} command that 378can be done while jobs are running. The default is set to 32 and is usually 379sufficient. 380 381\end{description} 382 383The following is an example of a valid Director resource definition: 384 385\footnotesize 386\begin{verbatim} 387Director { 388 Name = HeadMan 389 WorkingDirectory = "$HOME/bacula/bin/working" 390 Password = UA_password 391 PidDirectory = "$HOME/bacula/bin/working" 392 QueryFile = "$HOME/bacula/bin/query.sql" 393 Messages = Standard 394} 395\end{verbatim} 396\normalsize 397 398\section{The Job Resource} 399\label{JobResource} 400\index[general]{Resource!Job} 401\index[general]{Job Resource} 402 403The Job resource defines a Job (Backup, Restore, ...) that Bacula must 404perform. Each Job resource definition contains the name of a Client and 405a FileSet to backup, the Schedule for the Job, where the data 406are to be stored, and what media Pool can be used. In effect, each Job 407resource must specify What, Where, How, and When or FileSet, Storage, 408Backup/Restore/Level, and Schedule respectively. Note, the FileSet must 409be specified for a restore job for historical reasons, but it is no longer used. 410 411Only a single type ({\bf Backup}, {\bf Restore}, ...) can be specified for any 412job. If you want to backup multiple FileSets on the same Client or multiple 413Clients, you must define a Job for each one. 414 415Note, you define only a single Job to do the Full, Differential, and 416Incremental backups since the different backup levels are tied together by 417a unique Job name. Normally, you will have only one Job per Client, but 418if a client has a really huge number of files (more than several million), 419you might want to split it into to Jobs each with a different FileSet 420covering only part of the total files. 421 422Multiple Storage daemons are not currently supported for Jobs, so if 423you do want to use multiple storage daemons, you will need to create 424a different Job and ensure that for each Job that the combination of 425Client and FileSet are unique. The Client and FileSet are what Bacula 426uses to restore a client, so if there are multiple Jobs with the same 427Client and FileSet or multiple Storage daemons that are used, the 428restore will not work. This problem can be resolved by defining multiple 429FileSet definitions (the names must be different, but the contents of 430the FileSets may be the same). 431 432 433\begin{description} 434 435\item [Job] 436 \index[dir]{Job} 437 \index[dir]{Directive!Job} 438 Start of the Job resource. At least one Job resource is required. 439 440\item [Name = \lt{}name\gt{}] 441 \index[dir]{Name} 442 \index[dir]{Directive!Name} 443 The Job name. This name can be specified on the {\bf Run} command in the 444 console program to start a job. If the name contains spaces, it must be 445 specified between quotes. It is generally a good idea to give your job the 446 same name as the Client that it will backup. This permits easy 447 identification of jobs. 448 449 When the job actually runs, the unique Job Name will consist of the name you 450 specify here followed by the date and time the job was scheduled for 451 execution. This directive is required. 452 453\item [Enabled = \lt{}yes\vb{}no\gt{}] 454 \index[dir]{Enable} 455 \index[dir]{Directive!Enable} 456 This directive allows you to enable or disable automatic execution 457 via the scheduler of a Job. 458 This directive allows you to enable or disable a Job resource. When the 459 resource of the Job is disabled, the Job will no longer be scheduled and 460 it will not be available in the list of Jobs to be run. To be able 461 to use the Job you must Enable it. 462 463 464\item [Type = \lt{}job-type\gt{}] 465 \index[dir]{Type} 466 \index[dir]{Directive!Type} 467 The {\bf Type} directive specifies the Job type, which may be one of the 468 following: {\bf Backup}, {\bf Restore}, {\bf Verify}, or {\bf Admin}. This 469 directive is required. Within a particular Job Type, there are also Levels 470 as discussed in the next item. 471 472\begin{description} 473 474\item [Backup] 475 \index[dir]{Backup} 476 Run a backup Job. Normally you will have at least one Backup job for each 477 client you want to save. Normally, unless you turn off cataloging, most all 478 the important statistics and data concerning files backed up will be placed 479 in the catalog. 480 481\item [Restore] 482 \index[dir]{Restore} 483 Run a restore Job. Normally, you will specify only one Restore job 484 which acts as a sort of prototype that you will modify using the console 485 program in order to perform restores. Although certain basic 486 information from a Restore job is saved in the catalog, it is very 487 minimal compared to the information stored for a Backup job -- for 488 example, no File database entries are generated since no Files are 489 saved. 490 491 {\bf Restore} jobs cannot be 492 automatically started by the scheduler as is the case for Backup, Verify 493 and Admin jobs. To restore files, you must use the {\bf restore} command 494 in the console. 495 496 497\item [Verify] 498 \index[dir]{Verify} 499 Run a verify Job. In general, {\bf verify} jobs permit you to compare the 500 contents of the catalog to the file system, or to what was backed up. In 501 addition, to verifying that a tape that was written can be read, you can 502 also use {\bf verify} as a sort of tripwire intrusion detection. 503 504\item [Admin] 505 \index[dir]{Admin} 506 Run an admin Job. An {\bf Admin} job can be used to periodically run catalog 507 pruning, if you do not want to do it at the end of each {\bf Backup} Job. 508 Although an Admin job is recorded in the catalog, very little data is 509 saved. The Client is not involved in an Admin job, so features such as 510 ``Client Run Before Job'' are not available. Only Director's runscripts will 511 be executed. 512 513\item [Migration] 514 \index[dir]{Migration} 515 Run a Migration Job (similar to a backup job) that reads data that was 516 previously backed up to a Volume and writes it to another Volume. (See 517 \vref{MigrationChapter}) 518 519\item [Copy] 520 \index[dir]{Copy} 521 Run a Copy Job that essentially creates two identical copies of the same 522 backup. The Copy process is essentially identical to the Migration feature 523 with the exception that the Job that is copied is left unchanged. (See 524 \vref{MigrationChapter}) 525 526\end{description} 527 528\label{Level} 529 530\item [Level = \lt{}job-level\gt{}] 531\index[dir]{Level} 532\index[dir]{Directive!Level} 533 The Level directive specifies the default Job level to be run. Each 534 different Job Type (Backup, Restore, ...) has a different set of Levels 535 that can be specified. The Level is normally overridden by a different 536 value that is specified in the {\bf Schedule} resource. This directive 537 is not required, but must be specified either by a {\bf Level} directive 538 or as an override specified in the {\bf Schedule} resource. 539 540For a {\bf Backup} Job, the Level may be one of the following: 541 542\begin{description} 543 544\item [Full] 545\index[dir]{Full} 546 When the Level is set to Full all files in the FileSet whether or not 547 they have changed will be backed up. 548 549\item [Incremental] 550 \index[dir]{Incremental} 551 When the Level is set to Incremental all files specified in the FileSet 552 that have changed since the last successful backup of the the same Job 553 using the same FileSet and Client, will be backed up. If the Director 554 cannot find a previous valid Full backup then the job will be upgraded 555 into a Full backup. When the Director looks for a valid backup record 556 in the catalog database, it looks for a previous Job with: 557 558\begin{itemize} 559\item The same Job name. 560\item The same Client name. 561\item The same FileSet (any change to the definition of the FileSet such as 562 adding or deleting a file in the Include or Exclude sections constitutes a 563 different FileSet. 564\item The Job was a Full, Differential, or Incremental backup. 565\item The Job terminated normally (i.e. did not fail or was not canceled). 566\item The Job started no longer ago than {\bf Max Full Interval}. 567\end{itemize} 568 569 If all the above conditions do not hold, the Director will upgrade the 570 Incremental to a Full save. Otherwise, the Incremental backup will be 571 performed as requested. 572 573 The File daemon (Client) decides which files to backup for an 574 Incremental backup by comparing start time of the prior Job (Full, 575 Differential, or Incremental) against the time each file was last 576 "modified" (st\_mtime) and the time its attributes were last 577 "changed"(st\_ctime). If the file was modified or its attributes 578 changed on or after this start time, it will then be backed up. 579 580 Some virus scanning software may change st\_ctime while 581 doing the scan. For example, if the virus scanning program attempts to 582 reset the access time (st\_atime), which Bacula does not use, it will 583 cause st\_ctime to change and hence Bacula will backup the file during 584 an Incremental or Differential backup. In the case of Sophos virus 585 scanning, you can prevent it from resetting the access time (st\_atime) 586 and hence changing st\_ctime by using the {\bf \verb:--:no-reset-atime} 587 option. For other software, please see their manual. 588 589 When Bacula does an Incremental backup, all modified files that are 590 still on the system are backed up. However, any file that has been 591 deleted since the last Full backup remains in the Bacula catalog, 592 which means that if between a Full save and the time you do a 593 restore, some files are deleted, those deleted files will also be 594 restored. The deleted files will no longer appear in the catalog 595 after doing another Full save. 596 597 In addition, if you move a directory rather than copy it, the files in 598 it do not have their modification time (st\_mtime) or their attribute 599 change time (st\_ctime) changed. As a consequence, those files will 600 probably not be backed up by an Incremental or Differential backup which 601 depend solely on these time stamps. If you move a directory, and wish 602 it to be properly backed up, it is generally preferable to copy it, then 603 delete the original. 604 605 However, to manage deleted files or directories changes in the 606 catalog during an Incremental backup you can use \texttt{accurate} 607 mode. This is quite memory consuming process. See \ilink{Accurate mode}{accuratemode} for more details. 608 609\item [Differential] 610 \index[dir]{Differential} 611 When the Level is set to Differential 612 all files specified in the FileSet that have changed since the last 613 successful Full backup of the same Job will be backed up. 614 If the Director cannot find a 615 valid previous Full backup for the same Job, FileSet, and Client, 616 backup, then the Differential job will be upgraded into a Full backup. 617 When the Director looks for a valid Full backup record in the catalog 618 database, it looks for a previous Job with: 619 620\begin{itemize} 621\item The same Job name. 622\item The same Client name. 623\item The same FileSet (any change to the definition of the FileSet such as 624 adding or deleting a file in the Include or Exclude sections constitutes a 625 different FileSet. 626\item The Job was a FULL backup. 627\item The Job terminated normally (i.e. did not fail or was not canceled). 628\item The Job started no longer ago than {\bf Max Full Interval}. 629\end{itemize} 630 631 If all the above conditions do not hold, the Director will upgrade the 632 Differential to a Full save. Otherwise, the Differential backup will be 633 performed as requested. 634 635 The File daemon (Client) decides which files to backup for a 636 differential backup by comparing the start time of the prior Full backup 637 Job against the time each file was last "modified" (st\_mtime) and the 638 time its attributes were last "changed" (st\_ctime). If the file was 639 modified or its attributes were changed on or after this start time, it 640 will then be backed up. The start time used is displayed after the {\bf 641 Since} on the Job report. In rare cases, using the start time of the 642 prior backup may cause some files to be backed up twice, but it ensures 643 that no change is missed. As with the Incremental option, you should 644 ensure that the clocks on your server and client are synchronized or as 645 close as possible to avoid the possibility of a file being skipped. 646 Note, on versions 1.33 or greater Bacula automatically makes the 647 necessary adjustments to the time between the server and the client so 648 that the times Bacula uses are synchronized. 649 650 When Bacula does a Differential backup, all modified files that are 651 still on the system are backed up. However, any file that has been 652 deleted since the last Full backup remains in the Bacula catalog, which 653 means that if between a Full save and the time you do a restore, some 654 files are deleted, those deleted files will also be restored. The 655 deleted files will no longer appear in the catalog after doing another 656 Full save. However, to remove deleted files from the catalog during a 657 Differential backup is quite a time consuming process and not currently 658 implemented in Bacula. It is, however, a planned future feature. 659 660 As noted above, if you move a directory rather than copy it, the 661 files in it do not have their modification time (st\_mtime) or 662 their attribute change time (st\_ctime) changed. As a 663 consequence, those files will probably not be backed up by an 664 Incremental or Differential backup which depend solely on these 665 time stamps. If you move a directory, and wish it to be 666 properly backed up, it is generally preferable to copy it, then 667 delete the original. Alternatively, you can move the directory, then 668 use the {\bf touch} program to update the timestamps. 669 670%% TODO: merge this with incremental 671 However, to manage deleted files or directories changes in the 672 catalog during an Differential backup you can use \texttt{accurate} 673 mode. This is quite memory consuming process. See \ilink{Accurate mode}{accuratemode} for more details. 674 675 Every once and a while, someone asks why we need Differential 676 backups as long as Incremental backups pickup all changed files. 677 There are possibly many answers to this question, but the one 678 that is the most important for me is that a Differential backup 679 effectively merges 680 all the Incremental and Differential backups since the last Full backup 681 into a single Differential backup. This has two effects: 1. It gives 682 some redundancy since the old backups could be used if the merged backup 683 cannot be read. 2. More importantly, it reduces the number of Volumes 684 that are needed to do a restore effectively eliminating the need to read 685 all the volumes on which the preceding Incremental and Differential 686 backups since the last Full are done. 687 688\item [VirtualFull] 689 \index[dir]{VirtualFull} 690 691 When the Backup Level is set to VirtualFull, Bacula will consolidate the 692 previous Full backup plus the most recent Differential backup and any 693 subsequent Incremental backups into a new Full backup. This new Full 694 backup will then be considered as the most recent Full for any future 695 Incremental or Differential backups. The VirtualFull backup is 696 accomplished without contacting the client by reading the previous 697 backup data and writing it to a volume in a different pool. 698 699 Bacula's virtual backup feature is often called Synthetic Backup or 700 Consolidation in other backup products. 701 702\end{description} 703 704For a {\bf Restore} Job, no level needs to be specified. 705 706For a {\bf Verify} Job, the Level may be one of the following: 707 708\begin{description} 709 710\item [InitCatalog] 711\index[dir]{InitCatalog} 712 does a scan of the specified {\bf FileSet} and stores the file 713 attributes in the Catalog database. Since no file data is saved, you 714 might ask why you would want to do this. It turns out to be a very 715 simple and easy way to have a {\bf Tripwire} like feature using {\bf 716 Bacula}. In other words, it allows you to save the state of a set of 717 files defined by the {\bf FileSet} and later check to see if those files 718 have been modified or deleted and if any new files have been added. 719 This can be used to detect system intrusion. Typically you would 720 specify a {\bf FileSet} that contains the set of system files that 721 should not change (e.g. /sbin, /boot, /lib, /bin, ...). Normally, you 722 run the {\bf InitCatalog} level verify one time when your system is 723 first setup, and then once again after each modification (upgrade) to 724 your system. Thereafter, when your want to check the state of your 725 system files, you use a {\bf Verify} {\bf level = Catalog}. This 726 compares the results of your {\bf InitCatalog} with the current state of 727 the files. 728 729\item [Catalog] 730\index[dir]{Catalog} 731 Compares the current state of the files against the state previously 732 saved during an {\bf InitCatalog}. Any discrepancies are reported. The 733 items reported are determined by the {\bf verify} options specified on 734 the {\bf Include} directive in the specified {\bf FileSet} (see the {\bf 735 FileSet} resource below for more details). Typically this command will 736 be run once a day (or night) to check for any changes to your system 737 files. 738 739 Please note! If you run two Verify Catalog jobs on the same client at 740 the same time, the results will certainly be incorrect. This is because 741 Verify Catalog modifies the Catalog database while running in order to 742 track new files. 743 744\item [VolumeToCatalog] 745\index[dir]{VolumeToCatalog} 746 This level causes Bacula to read the file attribute data written to the 747 Volume from the last backup Job for the job specified on the {\bf VerifyJob} 748 directive. The file attribute data are compared to the 749 values saved in the Catalog database and any differences are reported. 750 This is similar to the {\bf DiskToCatalog} level except that instead of 751 comparing the disk file attributes to the catalog database, the 752 attribute data written to the Volume is read and compared to the catalog 753 database. Although the attribute data including the signatures (MD5 or 754 SHA1) are compared, the actual file data is not compared (it is not in 755 the catalog). 756 757 Please note! If you run two Verify VolumeToCatalog jobs on the same 758 client at the same time, the results will certainly be incorrect. This 759 is because the Verify VolumeToCatalog modifies the Catalog database 760 while running. 761 762\item [DiskToCatalog] 763\index[dir]{DiskToCatalog} 764 This level causes Bacula to read the files as they currently are on 765 disk, and to compare the current file attributes with the attributes 766 saved in the catalog from the last backup for the job specified on the 767 {\bf VerifyJob} directive. This level differs from the {\bf VolumeToCatalog} 768 level described above by the fact that it doesn't compare against a 769 previous Verify job but against a previous backup. When you run this 770 level, you must supply the verify options on your Include statements. 771 Those options determine what attribute fields are compared. 772 773 This command can be very useful if you have disk problems because it 774 will compare the current state of your disk against the last successful 775 backup, which may be several jobs. 776 777 Note, the current implementation (1.32c) does not identify files that 778 have been deleted. 779\end{description} 780 781\item [Accurate = \lt{}yes\vb{}no\gt{}] 782\index[dir]{Accurate} 783 In accurate mode, the File daemon knowns exactly which files were present 784 after the last backup. So it is able to handle deleted or renamed files. 785 786 When restoring a FileSet for a specified date (including "most 787 recent"), Bacula is able to restore exactly the files and 788 directories that existed at the time of the last backup prior to 789 that date including ensuring that deleted files are actually deleted, 790 and renamed directories are restored properly. 791 792 In this mode, the File daemon must keep data concerning all files in 793 memory. So If you do not have sufficient memory, the backup may 794 either be terribly slow or fail. 795 796%% $$ memory = \sum_{i=1}^{n}(strlen(path_i + file_i) + sizeof(CurFile))$$ 797 798 For 500.000 files (a typical desktop linux system), it will require 799 approximately 64 Megabytes of RAM on your File daemon to hold the 800 required information. 801 802\item [Verify Job = \lt{}Job-Resource-Name\gt{}] 803 \index[dir]{Verify Job} 804 \index[dir]{Directive!Verify Job} 805 If you run a verify job without this directive, the last job run will be 806 compared with the catalog, which means that you must immediately follow 807 a backup by a verify command. If you specify a {\bf Verify Job} Bacula 808 will find the last job with that name that ran. This permits you to run 809 all your backups, then run Verify jobs on those that you wish to be 810 verified (most often a {\bf VolumeToCatalog}) so that the tape just 811 written is re-read. 812 813\item [JobDefs = \lt{}JobDefs-Resource-Name\gt{}] 814\index[dir]{JobDefs} 815\index[dir]{Directive!JobDefs} 816 If a JobDefs-Resource-Name is specified, all the values contained in the 817 named JobDefs resource will be used as the defaults for the current Job. 818 Any value that you explicitly define in the current Job resource, will 819 override any defaults specified in the JobDefs resource. The use of 820 this directive permits writing much more compact Job resources where the 821 bulk of the directives are defined in one or more JobDefs. This is 822 particularly useful if you have many similar Jobs but with minor 823 variations such as different Clients. A simple example of the use of 824 JobDefs is provided in the default bacula-dir.conf file. 825 826\item [Bootstrap = \lt{}bootstrap-file\gt{}] 827\index[dir]{Bootstrap} 828\index[dir]{Directive!Bootstrap} 829 The Bootstrap directive specifies a bootstrap file that, if provided, 830 will be used during {\bf Restore} Jobs and is ignored in other Job 831 types. The {\bf bootstrap} file contains the list of tapes to be used 832 in a restore Job as well as which files are to be restored. 833 Specification of this directive is optional, and if specified, it is 834 used only for a restore job. In addition, when running a Restore job 835 from the console, this value can be changed. 836 837 If you use the {\bf Restore} command in the Console program, to start a 838 restore job, the {\bf bootstrap} file will be created automatically from 839 the files you select to be restored. 840 841 For additional details of the {\bf bootstrap} file, please see 842 \ilink{Restoring Files with the Bootstrap File}{BootstrapChapter} chapter 843 of this manual. 844 845\label{writebootstrap} 846\item [Write Bootstrap = \lt{}bootstrap-file-specification\gt{}] 847\index[dir]{Write Bootstrap} 848\index[dir]{Directive!Write Bootstrap} 849 The {\bf writebootstrap} directive specifies a file name where Bacula 850 will write a {\bf bootstrap} file for each Backup job run. This 851 directive applies only to Backup Jobs. If the Backup job is a Full 852 save, Bacula will erase any current contents of the specified file 853 before writing the bootstrap records. If the Job is an Incremental 854 or Differential 855 save, Bacula will append the current bootstrap record to the end of the 856 file. 857 858 Using this feature, permits you to constantly have a bootstrap file that 859 can recover the current state of your system. Normally, the file 860 specified should be a mounted drive on another machine, so that if your 861 hard disk is lost, you will immediately have a bootstrap record 862 available. Alternatively, you should copy the bootstrap file to another 863 machine after it is updated. Note, it is a good idea to write a separate 864 bootstrap file for each Job backed up including the job that backs up 865 your catalog database. 866 867 If the {\bf bootstrap-file-specification} begins with a vertical bar 868 (\verb+|+), Bacula will use the specification as the name of a program to which 869 it will pipe the bootstrap record. It could for example be a shell 870 script that emails you the bootstrap record. 871 872 On versions 1.39.22 or greater, before opening the file or executing the 873 specified command, Bacula performs 874 \ilink{character substitution}{character substitution} like in RunScript 875 directive. To automatically manage your bootstrap files, you can use 876 this in your {\bf JobDefs} resources: 877\begin{verbatim} 878JobDefs { 879 Write Bootstrap = "%c_%n.bsr" 880 ... 881} 882\end{verbatim} 883 884 For more details on using this file, please see the chapter entitled 885 \ilink{The Bootstrap File}{BootstrapChapter} of this manual. 886 887\item [Client = \lt{}client-resource-name\gt{}] 888\index[dir]{Client} 889\index[dir]{Directive!Client} 890 The Client directive specifies the Client (File daemon) that will be used in 891 the current Job. Only a single Client may be specified in any one Job. The 892 Client runs on the machine to be backed up, and sends the requested files to 893 the Storage daemon for backup, or receives them when restoring. For 894 additional details, see the 895 \ilink{Client Resource section}{ClientResource2} of this chapter. 896 This directive is required. 897 898\item [FileSet = \lt{}FileSet-resource-name\gt{}] 899\index[dir]{FileSet} 900\index[dir]{Directive!FileSet} 901 The FileSet directive specifies the FileSet that will be used in the 902 current Job. The FileSet specifies which directories (or files) are to 903 be backed up, and what options to use (e.g. compression, ...). Only a 904 single FileSet resource may be specified in any one Job. For additional 905 details, see the \ilink{FileSet Resource section}{FileSetResource} of 906 this chapter. This directive is required. 907 908\item [Base = \lt{}job-resource-name, ...\gt{}] 909\index[dir]{Base} 910\index[dir]{Directive!Base} 911The Base directive permits to specify the list of jobs that will be used during 912Full backup as base. This directive is optional. See the \ilink{Base Job chapter}{basejobs} for more information. 913 914\item [Messages = \lt{}messages-resource-name\gt{}] 915\index[dir]{Messages} 916\index[dir]{Directive!Messages} 917 The Messages directive defines what Messages resource should be used for 918 this job, and thus how and where the various messages are to be 919 delivered. For example, you can direct some messages to a log file, and 920 others can be sent by email. For additional details, see the 921 \ilink{Messages Resource}{MessagesChapter} Chapter of this manual. This 922 directive is required. 923 924\label{Director:Job:SnapshotRetention} 925\item [Snapshot Retention = \lt{}time-period-specification\gt{}] 926 \index[dir]{Snapshot Retention} 927 \index[dir]{Directive!Snapshot Retention} 928 929 The Snapshot Retention directive defines the length of time that Bacula 930 will keep Snapshots in the Catalog database and on the Client after the 931 Snapshot creation. When this time period expires, and if using the 932 \texttt{snapshot prune} command, Bacula will prune (remove) Snapshot 933 records that are older than the specified Snapshot Retention period and 934 will contact the FileDaemon to delete Snapshots from the system. 935 936 The Snapshot retention period is specified as seconds, minutes, hours, 937 days, weeks, months, quarters, or years. See the 938 \ilink{ Configuration chapter}{Time} of this manual for 939 additional details of time specification. 940 941 The default is 0 seconds, Snapshots are deleted at the end of the 942 backup. The Job \textbf{SnapshotRetention} directive overwrites the 943 Client \textbf{SnapshotRetention} directive. 944 945\item [Pool = \lt{}pool-resource-name\gt{}] 946\index[dir]{Pool} 947\index[dir]{Directive!Pool} 948 The Pool directive defines the pool of Volumes where your data can be 949 backed up. Many Bacula installations will use only the {\bf Default} 950 pool. However, if you want to specify a different set of Volumes for 951 different Clients or different Jobs, you will probably want to use 952 Pools. For additional details, see the \ilink{Pool Resource section}{PoolResource} of this chapter. This directive is required. 953 954\item [Full Backup Pool = \lt{}pool-resource-name\gt{}] 955\index[dir]{Full Backup Pool} 956\index[dir]{Directive!Full Backup Pool} 957 The {\it Full Backup Pool} specifies a Pool to be used for Full backups. 958 It will override any Pool specification during a Full backup. This 959 directive is optional. 960 961\item [Differential Backup Pool = \lt{}pool-resource-name\gt{}] 962\index[dir]{Differential Backup Pool} 963\index[dir]{Directive!Differential Backup Pool} 964 The {\it Differential Backup Pool} specifies a Pool to be used for 965 Differential backups. It will override any Pool specification during a 966 Differential backup. This directive is optional. 967 968\item [Incremental Backup Pool = \lt{}pool-resource-name\gt{}] 969\index[dir]{Incremental Backup Pool} 970\index[dir]{Directive!Incremental Backup Pool} 971 The {\it Incremental Backup Pool} specifies a Pool to be used for 972 Incremental backups. It will override any Pool specification during an 973 Incremental backup. This directive is optional. 974 975\label{Director:Job:BackupsToKeep} 976\item [BackupsToKeep = \lt{}number\gt{}] 977\index[dir]{Backups to Keep} 978\index[dir]{Directive!Backups To Keep} 979 980When this directive is present during a Virtual Full (it is ignored for 981other Job types), it will look for a Full backup that has more subsequent 982backups than the value specified. In the example below, the Job will 983simply terminate unless there is a Full back followed by at least 31 984backups of either level Differential or Incremental. 985 986\begin{verbatim} 987 Job { 988 Name = "VFull" 989 Type = Backup 990 Level = VirtualFull 991 Client = "my-fd" 992 File Set = "FullSet" 993 Accurate = Yes 994 Backups To Keep = 30 995 } 996\end{verbatim} 997 998Assuming that the last Full backup is followed by 32 Incremental backups, a 999Virtual Full will be run that consolidates the Full with the first two 1000Incrementals that were run after the Full. The result is that you will end 1001up with a Full followed by 30 Incremental backups. 1002 1003\label{Director:Job:DeleteConsolidatedJobs} 1004\item [DeleteConsolidatedJobs = \lt{}yes/no\gt{}] 1005\index[dir]{Delete Consolidated Jobs} 1006\index[dir]{Directive!Delete Consolidated Jobs} 1007 1008If set to {\bf yes}, it will cause any old Job that is consolidated during 1009a Virtual Full to be deleted. In the example above we saw that a Full plus 1010one other job (either an Incremental or Differential) were consolidated 1011into a new Full backup. The original Full plus the other Job consolidated 1012will be deleted. The default value is {\bf no}. 1013 1014 1015\item [Schedule = \lt{}schedule-name\gt{}] 1016\index[dir]{Schedule} 1017\index[dir]{Directive!Schedule} 1018 The Schedule directive defines what schedule is to be used for the Job. 1019 The schedule in turn determines when the Job will be automatically 1020 started and what Job level (i.e. Full, Incremental, ...) is to be run. 1021 This directive is optional, and if left out, the Job can only be started 1022 manually using the Console program. Although you may specify only a 1023 single Schedule resource for any one job, the Schedule resource may 1024 contain multiple {\bf Run} directives, which allow you to run the Job at 1025 many different times, and each {\bf run} directive permits overriding 1026 the default Job Level Pool, Storage, and Messages resources. This gives 1027 considerable flexibility in what can be done with a single Job. For 1028 additional details, see the \ilink{Schedule Resource Chapter}{ScheduleResource} of this manual. 1029 1030 1031\item [Storage = \lt{}storage-resource-name\gt{}] 1032\index[dir]{Storage} 1033\index[dir]{Directive!Storage} 1034 The Storage directive defines the name of the storage services where you 1035 want to backup the FileSet data. For additional details, see the 1036 \ilink{Storage Resource Chapter}{StorageResource2} of this manual. 1037 The Storage resource may also be specified in the Job's Pool resource, 1038 in which case the value in the Pool resource overrides any value 1039 in the Job. This Storage resource definition is not required by either 1040 the Job resource or in the Pool, but it must be specified in 1041 one or the other, if not an error will result. 1042 1043\item [Max Start Delay = \lt{}time\gt{}] 1044\index[dir]{Max Start Delay} 1045\index[dir]{Directive!Max Start Delay} 1046 The time specifies the maximum delay between the scheduled time and the 1047 actual start time for the Job. For example, a job can be scheduled to 1048 run at 1:00am, but because other jobs are running, it may wait to run. 1049 If the delay is set to 3600 (one hour) and the job has not begun to run 1050 by 2:00am, the job will be canceled. This can be useful, for example, 1051 to prevent jobs from running during day time hours. The default is 0 1052 which indicates no limit. 1053 1054\item [Max Run Time = \lt{}time\gt{}] 1055\index[dir]{Max Run Time} 1056\index[dir]{Directive!Max Run Time} 1057 The time specifies the maximum allowed time that a job may run, counted 1058 from when the job starts, ({\bf not} necessarily the same as when the 1059 job was scheduled). 1060 1061 By default, the the watchdog thread will kill any Job that has run more 1062 than 200 days. The maximum watchdog timeout is independent of MaxRunTime 1063 and cannot be changed. 1064 1065 1066\item [Incremental|Differential Max Wait Time = \lt{}time\gt{}] 1067\index[dir]{Incremental Wait Run Time} 1068\index[dir]{Differential Wait Run Time} 1069\index[dir]{Directive!Differential Max Wait Time} 1070 Theses directives have been deprecated in favor of 1071 \texttt{Incremental|Differential Max Run Time} since bacula 2.3.18. 1072 1073\item [Incremental Max Run Time = \lt{}time\gt{}] 1074\index[dir]{Incremental Max Run Time} 1075\index[dir]{Directive!Incremental Max Run Time} 1076The time specifies the maximum allowed time that an Incremental backup job may 1077run, counted from when the job starts, ({\bf not} necessarily the same as when 1078the job was scheduled). 1079 1080\item [Differential Max Wait Time = \lt{}time\gt{}] 1081\index[dir]{Differential Max Run Time} 1082\index[dir]{Directive!Differential Max Run Time} 1083The time specifies the maximum allowed time that a Differential backup job may 1084run, counted from when the job starts, ({\bf not} necessarily the same as when 1085the job was scheduled). 1086 1087\item [Max Run Sched Time = \lt{}time\gt{}] 1088\index[dir]{Max Run Sched Time} 1089\index[dir]{Directive!Max Run Sched Time} 1090 1091The time specifies the maximum allowed time that a job may run, counted from 1092when the job was scheduled. This can be useful to prevent jobs from running 1093during working hours. We can see it like \texttt{Max Start Delay + Max Run 1094 Time}. 1095 1096\item [Max Wait Time = \lt{}time\gt{}] 1097\index[dir]{Max Wait Time} 1098\index[dir]{Directive!Max Wait Time} 1099 The time specifies the maximum allowed time that a job may block waiting 1100 for a resource (such as waiting for a tape to be mounted, or waiting for 1101 the storage or file daemons to perform their duties), counted from the 1102 when the job starts, ({\bf not} necessarily the same as when the job was 1103 scheduled). This directive works as expected since bacula 2.3.18. 1104 1105\begin{figure}[htbp] 1106 \centering 1107 \includegraphics[width=\linewidth]{different_time} 1108 \caption{Job time control directives} 1109 \label{fig:differenttime} 1110\end{figure} 1111 1112\label{Director:Job:MaximumSpawnedJobs} 1113\item [Maximum Spawned Jobs = \lt{}nb\gt{}] 1114\index[dir]{Maximum Spawned Jobs} 1115\index[dir]{Directive!Maximum Spawned Jobs} 1116 1117The Job resource now permits specifying a number of {\bf Maximum Spawn 1118Jobs}. The default is 300. This directive can be useful if you have 1119big hardware and you do a lot of Migration/Copy jobs which start 1120at the same time. 1121 1122\item [Maximum Bandwidth = \lt{}speed\gt{}] 1123\index[dir]{Maximum Bandwidth} 1124\index[dir]{Directive!Maximum Bandwidth} 1125 1126The speed parameter specifies the maximum allowed bandwidth that a job may 1127use. The speed parameter should be specified in k/s, kb/s, m/s or mb/s. 1128 1129\item [Max Full Interval = \lt{}time\gt{}] 1130\index[dir]{Max Full Interval} 1131\index[dir]{Directive!Max Full Interval} 1132 The time specifies the maximum allowed age (counting from start time) of 1133 the most recent successful Full backup that is required in order to run 1134 Incremental or Differential backup jobs. If the most recent Full backup 1135 is older than this interval, Incremental and Differential backups will be 1136 upgraded to Full backups automatically. If this directive is not present, 1137 or specified as 0, then the age of the previous Full backup is not 1138 considered. 1139 1140\label{PreferMountedVolumes} 1141\item [Prefer Mounted Volumes = \lt{}yes\vb{}no\gt{}] 1142\index[dir]{Prefer Mounted Volumes} 1143\index[dir]{Directive!Prefer Mounted Volumes} 1144 If the Prefer Mounted Volumes directive is set to {\bf yes} (default 1145 yes), the Storage daemon is requested to select either an Autochanger or 1146 a drive with a valid Volume already mounted in preference to a drive 1147 that is not ready. This means that all jobs will attempt to append 1148 to the same Volume (providing the Volume is appropriate -- right Pool, 1149 ... for that job), unless you are using multiple pools. 1150 If no drive with a suitable Volume is available, it 1151 will select the first available drive. Note, any Volume that has 1152 been requested to be mounted, will be considered valid as a mounted 1153 volume by another job. This if multiple jobs start at the same time 1154 and they all prefer mounted volumes, the first job will request the 1155 mount, and the other jobs will use the same volume. 1156 1157 If the directive is set to {\bf no}, the Storage daemon will prefer 1158 finding an unused drive, otherwise, each job started will append to the 1159 same Volume (assuming the Pool is the same for all jobs). Setting 1160 Prefer Mounted Volumes to no can be useful for those sites 1161 with multiple drive autochangers that prefer to maximize backup 1162 throughput at the expense of using additional drives and Volumes. 1163 This means that the job will prefer to use an unused drive rather 1164 than use a drive that is already in use. 1165 1166 Despite the above, we recommend against setting this directive to 1167 {\bf no} since 1168 it tends to add a lot of swapping of Volumes between the different 1169 drives and can easily lead to deadlock situations in the Storage 1170 daemon. We will accept bug reports against it, but we cannot guarantee 1171 that we will be able to fix the problem in a reasonable time. 1172 1173 A better alternative for using multiple drives is to use multiple 1174 pools so that Bacula will be forced to mount Volumes from those Pools 1175 on different drives. 1176 1177\item [Prune Jobs = \lt{}yes\vb{}no\gt{}] 1178\index[dir]{Prune Jobs} 1179\index[dir]{Directive!Prune Jobs} 1180 Normally, pruning of Jobs from the Catalog is specified on a Client by 1181 Client basis in the Client resource with the {\bf AutoPrune} directive. 1182 If this directive is specified (not normally) and the value is {\bf 1183 yes}, it will override the value specified in the Client resource. The 1184 default is {\bf no}. 1185 1186 1187\item [Prune Files = \lt{}yes\vb{}no\gt{}] 1188\index[dir]{Prune Files} 1189\index[dir]{Directive!Prune Files} 1190 Normally, pruning of Files from the Catalog is specified on a Client by 1191 Client basis in the Client resource with the {\bf AutoPrune} directive. 1192 If this directive is specified (not normally) and the value is {\bf 1193 yes}, it will override the value specified in the Client resource. The 1194 default is {\bf no}. 1195 1196\item [Prune Volumes = \lt{}yes\vb{}no\gt{}] 1197\index[dir]{Prune Volumes} 1198\index[dir]{Directive!Prune Volumes} 1199 Normally, pruning of Volumes from the Catalog is specified on a Pool by 1200 Pool basis in the Pool resource with the {\bf AutoPrune} directive. 1201 Note, this is different from File and Job pruning which is done on a 1202 Client by Client basis. If this directive is specified (not normally) 1203 and the value is {\bf yes}, it will override the value specified in the 1204 Pool resource. The default is {\bf no}. 1205 1206\item [RunScript \{\lt{}body-of-runscript\gt{}\}] 1207 \index[dir]{RunScript} 1208 \index[dir]{Directive!Run Script} 1209 1210 The RunScript directive behaves like a resource in that it 1211 requires opening and closing braces around a number of directives 1212 that make up the body of the runscript. 1213 1214 The specified {\bf Command} (see below for details) is run as an external 1215 program prior or after the current Job. This is optional. By default, the 1216 program is executed on the Client side like in \texttt{ClientRunXXXJob}. 1217 1218 \textbf{Console} options are special commands that are sent to the director instead 1219 of the OS. At this time, console command ouputs are redirected to log with 1220 the jobid 0. 1221 1222 You can use following console command : \texttt{delete}, \texttt{disable}, 1223 \texttt{enable}, \texttt{estimate}, \texttt{list}, \texttt{llist}, 1224 \texttt{memory}, \texttt{prune}, \texttt{purge}, \texttt{reload}, 1225 \texttt{status}, \texttt{setdebug}, \texttt{show}, \texttt{time}, 1226 \texttt{trace}, \texttt{update}, \texttt{version}, \texttt{.client}, 1227 \texttt{.jobs}, \texttt{.pool}, \texttt{.storage}. See console chapter for 1228 more information. You need to specify needed information on command line, nothing 1229 will be prompted. Example : 1230 1231\begin{verbatim} 1232 Console = "prune files client=%c" 1233 Console = "update stats age=3" 1234\end{verbatim} 1235 1236 You can specify more than one Command/Console option per RunScript. 1237 1238 You can use following options may be specified in the body 1239 of the runscript:\\ 1240 1241\LTXtable{\linewidth}{table_runscript} 1242 1243 Any output sent by the command to standard output will be included in the 1244 Bacula job report. The command string must be a valid program name or name 1245 of a shell script. 1246 1247 In addition, the command string is parsed then fed to the OS, 1248 which means that the path will be searched to execute your specified 1249 command, but there is no shell interpretation, as a consequence, if you 1250 invoke complicated commands or want any shell features such as redirection 1251 or piping, you must call a shell script and do it inside that script. 1252 1253 Before submitting the specified command to the operating system, Bacula 1254 performs character substitution of the following characters: 1255 1256\label{character substitution} 1257\footnotesize 1258\begin{verbatim} 1259 %% = % 1260 %b = Job Bytes 1261 %c = Client's name 1262 %C = If the job is a Cloned job (Only on director side) 1263 %d = Daemon's name (Such as host-dir or host-fd) 1264 %D = Director's name (Also valid on file daemon) 1265 %e = Job Exit Status 1266 %E = Non-fatal Job Errors 1267 %f = Job FileSet (Only on director side) 1268 %F = Job Files 1269 %h = Client address 1270 %i = JobId 1271 %I = Migration/Copy JobId (Only in Copy/Migrate Jobs) 1272 %j = Unique Job id 1273 %l = Job Level 1274 %n = Job name 1275 %p = Pool name (Only on director side) 1276 %P = Current PID process 1277 %o = Job Priority 1278 %R = Read Bytes 1279 %S = Previous Job name (Only on file daemon side) 1280 %s = Since time 1281 %t = Job type (Backup, ...) 1282 %v = Volume name (Only on director side) 1283 %w = Storage name (Only on director side) 1284 %x = Spooling enabled? ("yes" or "no") 1285 1286\end{verbatim} 1287\normalsize 1288 1289Some character substitutions are not available in all situations. The Job Exit 1290Status code \%e edits the following values: 1291 1292\index[dir]{Exit Status} 1293\begin{itemize} 1294\item OK 1295\item Error 1296\item Fatal Error 1297\item Canceled 1298\item Differences 1299\item Unknown term code 1300\end{itemize} 1301 1302 Thus if you edit it on a command line, you will need to enclose 1303 it within some sort of quotes. 1304 1305 1306You can use these following shortcuts:\\ 1307 1308\LTXtable{\linewidth}{table_runscriptshortcuts} 1309Examples: 1310\begin{verbatim} 1311RunScript { 1312 RunsWhen = Before 1313 FailJobOnError = No 1314 Command = "/etc/init.d/apache stop" 1315} 1316 1317RunScript { 1318 RunsWhen = After 1319 RunsOnFailure = yes 1320 Command = "/etc/init.d/apache start" 1321} 1322\end{verbatim} 1323 1324 {\bf Notes about ClientRunBeforeJob} 1325 1326 For compatibility reasons, with this shortcut, the command is executed 1327 directly when the client recieve it. And if the command is in error, other 1328 remote runscripts will be discarded. To be sure that all commands will be 1329 sent and executed, you have to use RunScript syntax. 1330 1331 {\bf Special Shell Considerations} 1332 1333 A "Command =" can be one of: 1334\begin{itemize} 1335\item The full path to an executable program 1336\item The name of an executable program that can be found in the \$PATH 1337\item A \textsl{complex} shell command in the form of: "sh -c \"your commands go here\"" 1338\end{itemize} 1339 1340 {\bf Special Windows Considerations} 1341 1342 You can run scripts just after snapshots initializations with 1343 \textsl{AfterVSS} keyword. 1344 1345 In addition, for a Windows client, please take 1346 note that you must ensure a correct path to your script. The script or 1347 program can be a .com, .exe or a .bat file. If you just put the program 1348 name in then Bacula will search using the same rules that cmd.exe uses 1349 (current directory, Bacula bin directory, and PATH). It will even try the 1350 different extensions in the same order as cmd.exe. 1351 The command can be anything that cmd.exe or command.com will recognize 1352 as an executable file. 1353 1354 However, if you have slashes in the program name then Bacula figures you 1355 are fully specifying the name, so you must also explicitly add the three 1356 character extension. 1357 1358 The command is run in a Win32 environment, so Unix like commands will not 1359 work unless you have installed and properly configured Cygwin in addition 1360 to and separately from Bacula. 1361 1362 The System \%Path\% will be searched for the command. (under the 1363 environment variable dialog you have have both System Environment and 1364 User Environment, we believe that only the System environment will be 1365 available to bacula-fd, if it is running as a service.) 1366 1367 System environment variables can be referenced with \%var\% and 1368 used as either part of the command name or arguments. 1369 1370 So if you have a script in the Bacula\\bin directory then the following lines 1371 should work fine: 1372 1373\footnotesize 1374\begin{verbatim} 1375 Client Run Before Job = systemstate 1376or 1377 Client Run Before Job = systemstate.bat 1378or 1379 Client Run Before Job = "systemstate" 1380or 1381 Client Run Before Job = "systemstate.bat" 1382or 1383 ClientRunBeforeJob = "\"C:/Program Files/Bacula/systemstate.bat\"" 1384\end{verbatim} 1385\normalsize 1386 1387The outer set of quotes is removed when the configuration file is parsed. 1388You need to escape the inner quotes so that they are there when the code 1389that parses the command line for execution runs so it can tell what the 1390program name is. 1391 1392 1393\footnotesize 1394\begin{verbatim} 1395ClientRunBeforeJob = "\"C:/Program Files/Software 1396 Vendor/Executable\" /arg1 /arg2 \"foo bar\"" 1397\end{verbatim} 1398\normalsize 1399 1400 The special characters 1401\begin{verbatim} 1402&<>()@^| 1403\end{verbatim} 1404 will need to be quoted, 1405 if they are part of a filename or argument. 1406 1407 If someone is logged in, a blank "command" window running the commands 1408 will be present during the execution of the command. 1409 1410 Some Suggestions from Phil Stracchino for running on Win32 machines with 1411 the native Win32 File daemon: 1412 1413 \begin{enumerate} 1414 \item You might want the ClientRunBeforeJob directive to specify a .bat 1415 file which runs the actual client-side commands, rather than trying 1416 to run (for example) regedit /e directly. 1417 \item The batch file should explicitly 'exit 0' on successful completion. 1418 \item The path to the batch file should be specified in Unix form: 1419 1420 ClientRunBeforeJob = "c:/bacula/bin/systemstate.bat" 1421 1422 rather than DOS/Windows form: 1423 1424 ClientRunBeforeJob = 1425 1426"c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat" 1427 INCORRECT 1428 \end{enumerate} 1429 1430For Win32, please note that there are certain limitations: 1431 1432ClientRunBeforeJob = "C:/Program Files/Bacula/bin/pre-exec.bat" 1433 1434Lines like the above do not work because there are limitations of 1435cmd.exe that is used to execute the command. 1436Bacula prefixes the string you supply with {\bf cmd.exe /c }. To test that 1437your command works you should type {\bf cmd /c "C:/Program Files/test.exe"} at a 1438cmd prompt and see what happens. Once the command is correct insert a 1439backslash (\textbackslash{}) before each double quote ("), and 1440then put quotes around the whole thing when putting it in 1441the director's .conf file. You either need to have only one set of quotes 1442or else use the short name and don't put quotes around the command path. 1443 1444Below is the output from cmd's help as it relates to the command line 1445passed to the /c option. 1446 1447 1448 If /C or /K is specified, then the remainder of the command line after 1449 the switch is processed as a command line, where the following logic is 1450 used to process quote (") characters: 1451 1452\begin{enumerate} 1453\item 1454 If all of the following conditions are met, then quote characters 1455 on the command line are preserved: 1456 \begin{itemize} 1457 \item no /S switch. 1458 \item exactly two quote characters. 1459 \item no special characters between the two quote characters, 1460 where special is one of: 1461\begin{verbatim} 1462&<>()@^| 1463\end{verbatim} 1464 \item there are one or more whitespace characters between the 1465 the two quote characters. 1466 \item the string between the two quote characters is the name 1467 of an executable file. 1468 \end{itemize} 1469 1470\item Otherwise, old behavior is to see if the first character is 1471 a quote character and if so, strip the leading character and 1472 remove the last quote character on the command line, preserving 1473 any text after the last quote character. 1474 1475\end{enumerate} 1476 1477 1478The following example of the use of the Client Run Before Job directive was 1479submitted by a user:\\ 1480You could write a shell script to back up a DB2 database to a FIFO. The shell 1481script is: 1482 1483\footnotesize 1484\begin{verbatim} 1485 #!/bin/sh 1486 # ===== backupdb.sh 1487 DIR=/u01/mercuryd 1488 1489 mkfifo $DIR/dbpipe 1490 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING & 1491 sleep 1 1492\end{verbatim} 1493\normalsize 1494 1495The following line in the Job resource in the bacula-dir.conf file: 1496\footnotesize 1497\begin{verbatim} 1498 Client Run Before Job = "su - mercuryd -c \"/u01/mercuryd/backupdb.sh '%t' 1499'%l'\"" 1500\end{verbatim} 1501\normalsize 1502 1503When the job is run, you will get messages from the output of the script 1504stating that the backup has started. Even though the command being run is 1505backgrounded with \&, the job will block until the "db2 BACKUP DATABASE" 1506command, thus the backup stalls. 1507 1508To remedy this situation, the "db2 BACKUP DATABASE" line should be changed to 1509the following: 1510 1511\footnotesize 1512\begin{verbatim} 1513 db2 BACKUP DATABASE mercuryd TO $DIR/dbpipe WITHOUT PROMPTING > $DIR/backup.log 15142>&1 < /dev/null & 1515\end{verbatim} 1516\normalsize 1517 1518It is important to redirect the input and outputs of a backgrounded command to 1519/dev/null to prevent the script from blocking. 1520 1521\item [Run Before Job = \lt{}command\gt{}] 1522\index[dir]{Run Before Job} 1523\index[dir]{Directive!Run Before Job} 1524\index[dir]{Directive!Run Before Job} 1525The specified {\bf command} is run as an external program prior to running the 1526current Job. This directive is not required, but if it is defined, and if the 1527exit code of the program run is non-zero, the current Bacula job will be 1528canceled. 1529 1530\begin{verbatim} 1531Run Before Job = "echo test" 1532\end{verbatim} 1533 it's equivalent to : 1534\begin{verbatim} 1535RunScript { 1536 Command = "echo test" 1537 RunsOnClient = No 1538 RunsWhen = Before 1539} 1540\end{verbatim} 1541 1542 Lutz Kittler has pointed out that using the RunBeforeJob directive can be a 1543 simple way to modify your schedules during a holiday. For example, suppose 1544 that you normally do Full backups on Fridays, but Thursday and Friday are 1545 holidays. To avoid having to change tapes between Thursday and Friday when 1546 no one is in the office, you can create a RunBeforeJob that returns a 1547 non-zero status on Thursday and zero on all other days. That way, the 1548 Thursday job will not run, and on Friday the tape you inserted on Wednesday 1549 before leaving will be used. 1550 1551\item [Run After Job = \lt{}command\gt{}] 1552\index[dir]{Run After Job} 1553\index[dir]{Directive!Run After Job} 1554 The specified {\bf command} is run as an external program if the current 1555 job terminates normally (without error or without being canceled). This 1556 directive is not required. If the exit code of the program run is 1557 non-zero, Bacula will print a warning message. Before submitting the 1558 specified command to the operating system, Bacula performs character 1559 substitution as described above for the {\bf RunScript} directive. 1560 1561 An example of the use of this directive is given in the 1562 \borgxrlink{Tips}{JobNotification}{problems}{chapter} of the \problemsman{}. 1563 1564 See the {\bf Run After Failed Job} if you 1565 want to run a script after the job has terminated with any 1566 non-normal status. 1567 1568\item [Run After Failed Job = \lt{}command\gt{}] 1569\index[dir]{Run After Job} 1570\index[dir]{Directive!Run After Job} 1571 The specified {\bf command} is run as an external program after the current 1572 job terminates with any error status. This directive is not required. The 1573 command string must be a valid program name or name of a shell script. If 1574 the exit code of the program run is non-zero, Bacula will print a 1575 warning message. Before submitting the specified command to the 1576 operating system, Bacula performs character substitution as described above 1577 for the {\bf RunScript} directive. Note, if you wish that your script 1578 will run regardless of the exit status of the Job, you can use this : 1579\begin{verbatim} 1580RunScript { 1581 Command = "echo test" 1582 RunsWhen = After 1583 RunsOnFailure = yes 1584 RunsOnClient = no 1585 RunsOnSuccess = yes # default, you can drop this line 1586} 1587\end{verbatim} 1588 1589 An example of the use of this directive is given in the 1590 \borgxrlink{Tips}{JobNotification}{problems}{chapter} of the \problemsman{}. 1591 1592 1593\item [Client Run Before Job = \lt{}command\gt{}] 1594\index[dir]{Client Run Before Job} 1595\index[dir]{Directive!Client Run Before Job} 1596 This directive is the same as {\bf Run Before Job} except that the 1597 program is run on the client machine. The same restrictions apply to 1598 Unix systems as noted above for the {\bf RunScript}. 1599 \textbf{ClientRunBeforeJob} can be used with Backup and Restore jobs. 1600 1601\item [Client Run After Job = \lt{}command\gt{}] 1602 \index[dir]{Client Run After Job} 1603 \index[dir]{Directive!Client Run After Job} 1604 The specified {\bf command} is run on the client machine as soon 1605 as data spooling is complete in order to allow restarting applications 1606 on the client as soon as possible. \textbf{ClientRunBeforeJob} can be 1607 used with Backup and Restore jobs. 1608 1609 Note, please see the notes above in {\bf RunScript} 1610 concerning Windows clients. 1611 1612\item [Rerun Failed Levels = \lt{}yes\vb{}no\gt{}] 1613 \index[dir]{Rerun Failed Levels} 1614 \index[dir]{Directive!Rerun Failed Levels} 1615 If this directive is set to {\bf yes} (default no), and Bacula detects that 1616 a previous job at a higher level (i.e. Full or Differential) has failed, 1617 the current job level will be upgraded to the higher level. This is 1618 particularly useful for Laptops where they may often be unreachable, and if 1619 a prior Full save has failed, you wish the very next backup to be a Full 1620 save rather than whatever level it is started as. 1621 1622 There are several points that must be taken into account when using this 1623 directive: first, a failed job is defined as one that has not terminated 1624 normally, which includes any running job of the same name (you need to 1625 ensure that two jobs of the same name do not run simultaneously); 1626 secondly, the {\bf Ignore FileSet Changes} directive is not considered 1627 when checking for failed levels, which means that any FileSet change will 1628 trigger a rerun. 1629 1630\item [Spool Data = \lt{}yes\vb{}no\gt{}] 1631 \index[dir]{Spool Data} 1632 \index[dir]{Directive!Spool Data} 1633 1634 If this directive is set to {\bf yes} (default no), the Storage daemon will 1635 be requested to spool the data for this Job to disk rather than write it 1636 directly to the Volume (normally a tape). 1637 1638 Thus the data is written in large blocks to the Volume rather than small 1639 blocks. This directive is particularly useful when running multiple 1640 simultaneous backups to tape. Once all the data arrives or the spool 1641 files' maximum sizes are reached, the data will be despooled and written 1642 to tape. 1643 1644 Spooling data prevents interleaving date from several job and reduces or 1645 eliminates tape drive stop and start commonly known as "shoe-shine". 1646 1647 We don't recommend using this option if you are writing to a disk file 1648 using this option will probably just slow down the backup jobs. 1649 1650 NOTE: When this directive is set to yes, Spool Attributes is also 1651 automatically set to yes. 1652 1653\item [Spool Attributes = \lt{}yes\vb{}no\gt{}] 1654 \index[dir]{Spool Attributes} 1655 \index[dir]{Directive!Spool Attributes} 1656 \index[dir]{slow} 1657 \index[general]{slow} 1658 \index[dir]{Backups!slow} 1659 \index[general]{Backups!slow} 1660 The default is set to {\bf no}, which means that the File attributes are 1661 sent by the Storage daemon to the Director as they are stored on tape. 1662 However, if you want to avoid the possibility that database updates will 1663 slow down writing to the tape, you may want to set the value to {\bf 1664 yes}, in which case the Storage daemon will buffer the File attributes 1665 and Storage coordinates to a temporary file in the Working Directory, 1666 then when writing the Job data to the tape is completed, the attributes 1667 and storage coordinates will be sent to the Director. 1668 1669 NOTE: When Spool Data is set to yes, Spool Attributes is also 1670 automatically set to yes. 1671 1672\item [SpoolSize={\it bytes}] 1673 \index[dir]{SpoolSize} 1674 \index[dir]{Directive!SpoolSize} 1675 where the bytes specify the maximum spool size for this job. 1676 The default is take from Device Maximum Spool Size limit. 1677 This directive is available only in Bacula version 2.3.5 or 1678 later. 1679 1680 1681\item [Where = \lt{}directory\gt{}] 1682 \index[dir]{Where} 1683 \index[dir]{Directive!Where} 1684 This directive applies only to a Restore job and specifies a prefix to 1685 the directory name of all files being restored. This permits files to 1686 be restored in a different location from which they were saved. If {\bf 1687 Where} is not specified or is set to backslash ({\bf /}), the files will 1688 be restored to their original location. By default, we have set {\bf 1689 Where} in the example configuration files to be {\bf 1690 /tmp/bacula-restores}. This is to prevent accidental overwriting of 1691 your files. 1692 1693\item [Add Prefix = \lt{}directory\gt{}] 1694 \label{confaddprefix} 1695 \index[dir]{AddPrefix} 1696 \index[dir]{Directive!AddPrefix} 1697 This directive applies only to a Restore job and specifies a prefix to the 1698 directory name of all files being restored. This will use \ilink{File Relocation}{filerelocation} feature implemented in Bacula 2.1.8 or later. 1699 1700\item [Add Suffix = \lt{}extention\gt{}] 1701 \index[dir]{AddSuffix} 1702 \index[dir]{Directive!AddSuffix} 1703 This directive applies only to a Restore job and specifies a suffix to all 1704 files being restored. This will use \ilink{File Relocation}{filerelocation} 1705 feature implemented in Bacula 2.1.8 or later. 1706 1707 Using \texttt{Add Suffix=.old}, \texttt{/etc/passwd} will be restored to 1708 \texttt{/etc/passwsd.old} 1709 1710\item [Strip Prefix = \lt{}directory\gt{}] 1711 \index[dir]{StripPrefix} 1712 \index[dir]{Directive!StripPrefix} 1713 This directive applies only to a Restore job and specifies a prefix to remove 1714 from the directory name of all files being restored. This will use the 1715 \ilink{File Relocation}{filerelocation} feature implemented in Bacula 2.1.8 1716 or later. 1717 1718 Using \texttt{Strip Prefix=/etc}, \texttt{/etc/passwd} will be restored to 1719 \texttt{/passwd} 1720 1721 Under Windows, if you want to restore \texttt{c:/files} to \texttt{d:/files}, 1722 you can use : 1723 1724\begin{verbatim} 1725 Strip Prefix = c: 1726 Add Prefix = d: 1727\end{verbatim} 1728 1729\item [RegexWhere = \lt{}expressions\gt{}] 1730 \index[dir]{RegexWhere} 1731 \index[dir]{Directive!RegexWhere} 1732 This directive applies only to a Restore job and specifies a regex filename 1733 manipulation of all files being restored. This will use \ilink{File Relocation}{filerelocation} feature implemented in Bacula 2.1.8 or later. 1734 1735 For more informations about how use this option, see 1736 \ilink{this}{useregexwhere}. 1737 1738\item [Replace = \lt{}replace-option\gt{}] 1739 \index[dir]{Replace} 1740 \index[dir]{Directive!Replace} 1741 This directive applies only to a Restore job and specifies what happens 1742 when Bacula wants to restore a file or directory that already exists. 1743 You have the following options for {\bf replace-option}: 1744 1745\begin{description} 1746 1747\item [always] 1748 \index[dir]{always} 1749 when the file to be restored already exists, it is deleted and then 1750 replaced by the copy that was backed up. This is the default value. 1751 1752\item [ifnewer] 1753\index[dir]{ifnewer} 1754 if the backed up file (on tape) is newer than the existing file, the 1755 existing file is deleted and replaced by the back up. 1756 1757\item [ifolder] 1758 \index[dir]{ifolder} 1759 if the backed up file (on tape) is older than the existing file, the 1760 existing file is deleted and replaced by the back up. 1761 1762\item [never] 1763 \index[dir]{never} 1764 if the backed up file already exists, Bacula skips restoring this file. 1765\end{description} 1766 1767\item [Prefix Links=\lt{}yes\vb{}no\gt{}] 1768 \index[dir]{Prefix Links} 1769 \index[dir]{Directive!Prefix Links} 1770 If a {\bf Where} path prefix is specified for a recovery job, apply it 1771 to absolute links as well. The default is {\bf No}. When set to {\bf 1772 Yes} then while restoring files to an alternate directory, any absolute 1773 soft links will also be modified to point to the new alternate 1774 directory. Normally this is what is desired -- i.e. everything is self 1775 consistent. However, if you wish to later move the files to their 1776 original locations, all files linked with absolute names will be broken. 1777 1778\item [Maximum Concurrent Jobs = \lt{}number\gt{}] 1779 \index[dir]{Maximum Concurrent Jobs} 1780 \index[dir]{Directive!Maximum Concurrent Jobs} 1781 where \lt{}number\gt{} is the maximum number of Jobs from the current 1782 Job resource that can run concurrently. Note, this directive limits 1783 only Jobs with the same name as the resource in which it appears. Any 1784 other restrictions on the maximum concurrent jobs such as in the 1785 Director, Client, or Storage resources will also apply in addition to 1786 the limit specified here. 1787 The default is set to 1, but you may set it to a larger number. If set 1788 to a large value, please be careful to not have this value higher than 1789 the Maximum Concurrent Jobs configured in the Client resource in the 1790 Client/File daemon configuration file. Otherwise, the File daemon 1791 may fail backup jobs because the File daemon's Maximum Concurrent 1792 Jobs is exceeded. 1793 We recommend that you read the WARNING 1794 documented under \ilink{Maximum Concurrent Jobs}{DirMaxConJobs} in the 1795 Director's resource. 1796 1797\item [Reschedule On Error = \lt{}yes\vb{}no\gt{}] 1798 \index[dir]{Reschedule On Error} 1799 \index[dir]{Directive!Reschedule On Error} 1800 If this directive is enabled, and the job terminates in error, the job 1801 will be rescheduled as determined by the {\bf Reschedule Interval} and 1802 {\bf Reschedule Times} directives. If you cancel the job, it will not 1803 be rescheduled. The default is {\bf no} (i.e. the job will not be 1804 rescheduled). 1805 1806 This specification can be useful for portables, laptops, or other 1807 machines that are not always connected to the network or switched on. 1808 1809\item [Reschedule Incomplete Jobs = \lt{}yes\vb{}no\gt{}] 1810 \index[dir]{Reschedule Incomplete Jobs} 1811 \index[dir]{Directive!Reschedule Incomplete Jobs} 1812 1813 If this directive is enabled, and the job terminates in incomplete 1814 status, the job will be rescheduled as determined by the {\bf Reschedule 1815 Interval} and {\bf Reschedule Times} directives. If you cancel the job, 1816 it will not be rescheduled. The default is {\bf yes} (i.e. Incomplete 1817 jobs will be rescheduled). 1818 1819\item [Reschedule Interval = \lt{}time-specification\gt{}] 1820 \index[dir]{Reschedule Interval} 1821 \index[dir]{Directive!Reschedule Interval} 1822 If you have specified {\bf Reschedule On Error = yes} and the job 1823 terminates in error, it will be rescheduled after the interval of time 1824 specified by {\bf time-specification}. See \ilink{the time specification formats}{Time} in the Configure chapter for details of 1825 time specifications. If no interval is specified, the job will not be 1826 rescheduled on error. The default Reschedule Interval 1827 is 30 minutes (1800 seconds). 1828 1829\item [Reschedule Times = \lt{}count\gt{}] 1830 \index[dir]{Reschedule Times} 1831 \index[dir]{Directive!Reschedule Times} 1832 This directive specifies the maximum number of times to reschedule the 1833 job. If it is set to zero (the default) the job will be rescheduled an 1834 indefinite number of times. 1835 1836\item [Allow Duplicate Jobs = \lt{}yes\vb{}no\gt{}] 1837\index[general]{Allow Duplicate Jobs} 1838 1839\begin{figure}[htbp] 1840 \centering 1841 \includegraphics[width=\linewidth]{duplicate-real} 1842 \caption{Allow Duplicate Jobs usage} 1843 \label{fig:allowduplicatejobs} 1844\end{figure} 1845 1846 A duplicate job in the sense we use it here means a second or subsequent 1847 job with the same name starts. This happens most frequently when the 1848 first job runs longer than expected because no tapes are available. The 1849 default is {\bf yes}. 1850 1851 If this directive is enabled duplicate jobs will be run. If 1852 the directive is set to {\bf no} (default) then only one job of a given name 1853 may run at one time, and the action that Bacula takes to ensure only 1854 one job runs is determined by the other directives (see below). 1855 1856 If {\bf Allow Duplicate Jobs} is set to {\bf no} and two jobs 1857 are present and none of the three directives given below permit 1858 cancelling a job, then the current job (the second one started) 1859 will be cancelled. 1860 1861\item [Allow Higher Duplicates = \lt{}yes\vb{}no\gt{}] 1862\index[general]{Allow Higher Duplicates} 1863 This directive was implemented in version 5.0.0, but does not work 1864 as expected. If used, it should always be set to no. In later versions 1865 of Bacula the directive is disabled (disregarded). 1866 1867 1868\item [Cancel Lower Level Duplicates = \lt{}yes\vb{}no\gt{}] 1869\index[general]{Cancel Lower Level Duplicates} 1870 If \textbf{Allow Duplicate Jobs} is set to \textbf{no} and this 1871 directive is set to \textbf{yes}, Bacula will choose between duplicated 1872 jobs the one with the highest level. For example, it will cancel a 1873 previous Incremental to run a Full backup. It works only for Backup 1874 jobs. The default is \texttt{no}. If the levels of the duplicated 1875 jobs are the same, nothing is done and the other 1876 Cancel XXX Duplicate directives will be examined. 1877 1878\item [Cancel Queued Duplicates = \lt{}yes\vb{}no\gt{}] 1879\index[general]{Cancel Queued Duplicates} 1880 If {\bf Allow Duplicate Jobs} is set to {\bf no} and 1881 if this directive is set to {\bf yes} any job that is 1882 already queued to run but not yet running will be canceled. 1883 The default is {\bf no}. 1884 1885\item[Cancel Running Duplicates = \lt{}yes\vb{}no\gt{}] 1886\index[general]{Cancel Running Duplicates} 1887 If {\bf Allow Duplicate Jobs} is set to {\bf no} and 1888 if this directive is set to {\bf yes} any job that is already running 1889 will be canceled. The default is {\bf no}. 1890 1891 1892%%\item[DuplicateJobProximity = \lt{}time-specification\gt{}] 1893%%\index[general]{Duplicate Job Proximity} 1894%% This directive permits to determine if two jobs are really duplicated. 1895%% If the first one is running for long time, this is probably not a good 1896%% idea to cancel it. 1897 1898\item [Run = \lt{}job-name\gt{}] 1899 \index[dir]{Run} 1900 \index[dir]{Directive!Run} 1901 \index[dir]{Clone a Job} 1902 The Run directive (not to be confused with the Run option in a 1903 Schedule) allows you to start other jobs or to clone jobs. By using the 1904 cloning keywords (see below), you can backup 1905 the same data (or almost the same data) to two or more drives 1906 at the same time. The {\bf job-name} is normally the same name 1907 as the current Job resource (thus creating a clone). However, it 1908 may be any Job name, so one job may start other related jobs. 1909 1910 The part after the equal sign must be enclosed in double quotes, 1911 and can contain any string or set of options (overrides) that you 1912 can specify when entering the Run command from the console. For 1913 example {\bf storage=DDS-4 ...}. In addition, there are two special 1914 keywords that permit you to clone the current job. They are {\bf level=\%l} 1915 and {\bf since=\%s}. The \%l in the level keyword permits 1916 entering the actual level of the current job and the \%s in the since 1917 keyword permits putting the same time for comparison as used on the 1918 current job. Note, in the case of the since keyword, the \%s must be 1919 enclosed in double quotes, and thus they must be preceded by a backslash 1920 since they are already inside quotes. For example: 1921 1922\begin{verbatim} 1923 run = "Nightly-backup level=%l since=\"%s\" storage=DDS-4" 1924\end{verbatim} 1925 1926 A cloned job will not start additional clones, so it is not 1927 possible to recurse. 1928 1929 Please note that all cloned jobs, as specified in the Run directives are 1930 submitted for running before the original job is run (while it is being 1931 initialized). This means that any clone job will actually start before 1932 the original job, and may even block the original job from starting 1933 until the original job finishes unless you allow multiple simultaneous 1934 jobs. Even if you set a lower priority on the clone job, if no other 1935 jobs are running, it will start before the original job. 1936 1937 If you are trying to prioritize jobs by using the clone feature (Run 1938 directive), you will find it much easier to do using a RunScript 1939 resource, or a RunBeforeJob directive. 1940 1941\label{Priority} 1942\item [Priority = \lt{}number\gt{}] 1943 \index[dir]{Priority} 1944 \index[dir]{Directive!Priority} 1945 This directive permits you to control the order in which your jobs will 1946 be run by specifying a positive non-zero number. The higher the number, 1947 the lower the job priority. Assuming you are not running concurrent jobs, 1948 all queued jobs of priority 1 will run before queued jobs of priority 2 1949 and so on, regardless of the original scheduling order. 1950 1951 The priority only affects waiting jobs that are queued to run, not jobs 1952 that are already running. If one or more jobs of priority 2 are already 1953 running, and a new job is scheduled with priority 1, the currently 1954 running priority 2 jobs must complete before the priority 1 job is 1955 run, unless Allow Mixed Priority is set. 1956 1957 The default priority is 10. 1958 1959 If you want to run concurrent jobs you should 1960 keep these points in mind: 1961 1962\begin{itemize} 1963\item See \borgxrlink{Running Concurrent Jobs}{ConcurrentJobs}{problems}{section} on how to setup 1964 concurrent jobs in the \problemsman{}. 1965 1966\item Bacula concurrently runs jobs of only one priority at a time. It 1967 will not simultaneously run a priority 1 and a priority 2 job. 1968 1969\item If Bacula is running a priority 2 job and a new priority 1 job is 1970 scheduled, it will wait until the running priority 2 job terminates even 1971 if the Maximum Concurrent Jobs settings would otherwise allow two jobs 1972 to run simultaneously. 1973 1974\item Suppose that bacula is running a priority 2 job and a new priority 1 1975 job is scheduled and queued waiting for the running priority 2 job to 1976 terminate. If you then start a second priority 2 job, the waiting 1977 priority 1 job will prevent the new priority 2 job from running 1978 concurrently with the running priority 2 job. That is: as long as there 1979 is a higher priority job waiting to run, no new lower priority jobs will 1980 start even if the Maximum Concurrent Jobs settings would normally allow 1981 them to run. This ensures that higher priority jobs will be run as soon 1982 as possible. 1983\end{itemize} 1984 1985If you have several jobs of different priority, it may not best to start 1986them at exactly the same time, because Bacula must examine them one at a 1987time. If by Bacula starts a lower priority job first, then it will run 1988before your high priority jobs. If you experience this problem, you may 1989avoid it by starting any higher priority jobs a few seconds before lower 1990priority ones. This insures that Bacula will examine the jobs in the 1991correct order, and that your priority scheme will be respected. 1992 1993\label{AllowMixedPriority} 1994\item [Allow Mixed Priority = \lt{}yes\vb{}no\gt{}] 1995\index[dir]{Allow Mixed Priority} 1996 This directive is only implemented in version 2.5 and later. When 1997 set to {\bf yes} (default {\bf no}), this job may run even if lower 1998 priority jobs are already running. This means a high priority job 1999 will not have to wait for other jobs to finish before starting. 2000 The scheduler will only mix priorities when all running jobs have 2001 this set to true. 2002 2003 Note that only higher priority jobs will start early. Suppose the 2004 director will allow two concurrent jobs, and that two jobs with 2005 priority 10 are running, with two more in the queue. If a job with 2006 priority 5 is added to the queue, it will be run as soon as one of 2007 the running jobs finishes. However, new priority 10 jobs will not 2008 be run until the priority 5 job has finished. 2009 2010%% \label{WritePartAfterJob} 2011%% \item [Write Part After Job = \lt{}yes\vb{}no\gt{}] 2012%% \index[dir]{Write Part After Job} 2013%% \index[dir]{Directive!Write Part After Job} 2014%% This directive is only implemented in version 1.37 and later. 2015%% If this directive is set to {\bf yes} (default {\bf no}), a new part file 2016%% will be created after the job is finished. 2017 2018%% It should be set to {\bf yes} when writing to devices that require mount 2019%% (for example DVD), so you are sure that the current part, containing 2020%% this job's data, is written to the device, and that no data is left in 2021%% the temporary file on the hard disk. However, on some media, like DVD+R 2022%% and DVD-R, a lot of space (about 10Mb) is lost every time a part is 2023%% written. So, if you run several jobs each after another, you could set 2024%% this directive to {\bf no} for all jobs, except the last one, to avoid 2025%% wasting too much space, but to ensure that the data is written to the 2026%% medium when all jobs are finished. 2027 2028%% This directive is ignored with tape and FIFO devices. 2029 2030\end{description} 2031 2032The following is an example of a valid Job resource definition: 2033 2034\footnotesize 2035\begin{verbatim} 2036Job { 2037 Name = "Minou" 2038 Type = Backup 2039 Level = Incremental # default 2040 Client = Minou 2041 FileSet="Minou Full Set" 2042 Storage = DLTDrive 2043 Pool = Default 2044 Schedule = "MinouWeeklyCycle" 2045 Messages = Standard 2046} 2047\end{verbatim} 2048\normalsize 2049 2050\section{The JobDefs Resource} 2051\label{JobDefsResource} 2052\index[general]{JobDefs Resource} 2053\index[general]{Resource!JobDefs} 2054 2055The JobDefs resource permits all the same directives that can appear in a Job 2056resource. However, a JobDefs resource does not create a Job, rather it can be 2057referenced within a Job to provide defaults for that Job. This permits you to 2058concisely define several nearly identical Jobs, each one referencing a JobDefs 2059resource which contains the defaults. Only the changes from the defaults need to 2060be mentioned in each Job. 2061 2062\section{The Schedule Resource} 2063\label{ScheduleResource} 2064\index[general]{Resource!Schedule} 2065\index[general]{Schedule Resource} 2066 2067The Schedule resource provides a means of automatically scheduling a Job as 2068well as the ability to override the default Level, Pool, Storage and Messages 2069resources. If a Schedule resource is not referenced in a Job, the Job can only 2070be run manually. In general, you specify an action to be taken and when. 2071 2072\begin{description} 2073 2074\item [Schedule] 2075\index[dir]{Schedule} 2076\index[dir]{Directive!Schedule} 2077 Start of the Schedule directives. No {\bf Schedule} resource is 2078 required, but you will need at least one if you want Jobs to be 2079 automatically started. 2080 2081\item [Name = \lt{}name\gt{}] 2082 \index[dir]{Name} 2083 \index[dir]{Directive!Name} 2084 The name of the schedule being defined. The Name directive is required. 2085 2086\item [Enabled = \lt{}yes\vb{}no\gt{}] 2087 \index[dir]{Enabled} 2088 \index[dir]{Directive!Enabled} 2089 This directive allows you to enable or disable the Schedule resource. 2090 2091\item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{}] 2092 \index[dir]{Run} 2093 \index[dir]{Directive!Run} 2094 The Run directive defines when a Job is to be run, and what overrides if 2095 any to apply. You may specify multiple {\bf run} directives within a 2096 {\bf Schedule} resource. If you do, they will all be applied (i.e. 2097 multiple schedules). If you have two {\bf Run} directives that start at 2098 the same time, two Jobs will start at the same time (well, within one 2099 second of each other). 2100 2101 The {\bf Job-overrides} permit overriding the Level, the Storage, the 2102 Messages, and the Pool specifications provided in the Job resource. In 2103 addition, the FullPool, the IncrementalPool, and the DifferentialPool 2104 specifications permit overriding the Pool specification according to 2105 what backup Job Level is in effect. 2106 2107 By the use of overrides, you may customize a particular Job. For 2108 example, you may specify a Messages override for your Incremental 2109 backups that outputs messages to a log file, but for your weekly or 2110 monthly Full backups, you may send the output by email by using a 2111 different Messages override. 2112 2113 {\bf Job-overrides} are specified as: {\bf keyword=value} where the 2114 keyword is Level, Storage, Messages, Pool, FullPool, DifferentialPool, 2115 or IncrementalPool, and the {\bf value} is as defined on the respective 2116 directive formats for the Job resource. You may specify multiple {\bf 2117 Job-overrides} on one {\bf Run} directive by separating them with one or 2118 more spaces or by separating them with a trailing comma. For example: 2119 2120\begin{description} 2121 2122\item [Level=Full] 2123 \index[dir]{Level} 2124 \index[dir]{Directive!Level} 2125 is all files in the FileSet whether or not they have changed. 2126 2127\item [Level=Incremental] 2128 \index[dir]{Level} 2129 \index[dir]{Directive!Level} 2130 is all files that have changed since the last backup. 2131 2132\item [Pool=Weekly] 2133 \index[dir]{Pool} 2134 \index[dir]{Directive!Pool} 2135 specifies to use the Pool named {\bf Weekly}. 2136 2137\item [Storage=DLT\_Drive] 2138 \index[dir]{Storage} 2139 \index[dir]{Directive!Storage} 2140 specifies to use {\bf DLT\_Drive} for the storage device. 2141 2142\item [Messages=Verbose] 2143 \index[dir]{Messages} 2144 \index[dir]{Directive!Messages} 2145 specifies to use the {\bf Verbose} message resource for the Job. 2146 2147\item [FullPool=Full] 2148 \index[dir]{FullPool} 2149 \index[dir]{Directive!FullPool} 2150 specifies to use the Pool named {\bf Full} if the job is a full backup, or 2151is 2152upgraded from another type to a full backup. 2153 2154\item [DifferentialPool=Differential] 2155 \index[dir]{DifferentialPool} 2156 \index[dir]{Directive!DifferentialPool} 2157 specifies to use the Pool named {\bf Differential} if the job is a 2158 differential backup. 2159 2160\item [IncrementalPool=Incremental] 2161 \index[dir]{IncrementalPool} 2162 \index[dir]{Directive!IncrementalPool} 2163 specifies to use the Pool named {\bf Incremental} if the job is an 2164 incremental backup. 2165 2166\item [NextPool=\lt{}pool-specification\gt{}] 2167 The {\bf Next Pool} directive specifies the pool to which Jobs will be 2168 migrated. This directive is used to define the Pool into which 2169 the data will be migrated. The Next Pool specified in the Run 2170 resource will take precidence over any specification in the Job 2171 or Pool resources. 2172 2173\item [Accurate=lt{}yes\vb{}no\lt{}] 2174 \index[dir]{Accurate} 2175 \index[dir]{Directive!Accurate} 2176 tells Bacula to use or not the Accurate code for the specific job. It 2177 can allow you to save memory and and CPU resources on the catalog server 2178 in some cases. 2179 2180 2181\end{description} 2182 2183{\bf Date-time-specification} determines when the Job is to be run. The 2184specification is a repetition, and as a default Bacula is set to run a job at 2185the beginning of the hour of every hour of every day of every week of every 2186month of every year. This is not normally what you want, so you must specify 2187or limit when you want the job to run. Any specification given is assumed to 2188be repetitive in nature and will serve to override or limit the default 2189repetition. This is done by specifying masks or times for the hour, day of the 2190month, day of the week, week of the month, week of the year, and month when 2191you want the job to run. By specifying one or more of the above, you can 2192define a schedule to repeat at almost any frequency you want. 2193 2194Basically, you must supply a {\bf month}, {\bf day}, {\bf hour}, and {\bf 2195minute} the Job is to be run. Of these four items to be specified, {\bf day} 2196is special in that you may either specify a day of the month such as 1, 2, 2197... 31, or you may specify a day of the week such as Monday, Tuesday, ... 2198Sunday. Finally, you may also specify a week qualifier to restrict the 2199schedule to the first, second, third, fourth, or fifth week of the month. 2200 2201For example, if you specify only a day of the week, such as {\bf Tuesday} the 2202Job will be run every hour of every Tuesday of every Month. That is the {\bf 2203month} and {\bf hour} remain set to the defaults of every month and all 2204hours. 2205 2206Note, by default with no other specification, your job will run at the 2207beginning of every hour. If you wish your job to run more than once in any 2208given hour, you will need to specify multiple {\bf run} specifications each 2209with a different minute. 2210 2211The date/time to run the Job can be specified in the following way in 2212pseudo-BNF: 2213 2214\footnotesize 2215\begin{verbatim} 2216<void-keyword> = on 2217<at-keyword> = at 2218<week-keyword> = 1st | 2nd | 3rd | 4th | 5th | 6th | first | 2219 second | third | fourth | fifth | sixth 2220<wday-keyword> = sun | mon | tue | wed | thu | fri | sat | 2221 sunday | monday | tuesday | wednesday | 2222 thursday | friday | saturday 2223<week-of-year-keyword> = w00 | w01 | ... w52 | w53 2224<month-keyword> = jan | feb | mar | apr | may | jun | jul | 2225 aug | sep | oct | nov | dec | january | 2226 february | ... | december 2227<daily-keyword> = daily 2228<weekly-keyword> = weekly 2229<monthly-keyword> = monthly 2230<hourly-keyword> = hourly 2231<digit> = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0 2232<number> = <digit> | <digit><number> 2233<12hour> = 0 | 1 | 2 | ... 12 2234<hour> = 0 | 1 | 2 | ... 23 2235<minute> = 0 | 1 | 2 | ... 59 2236<day> = 1 | 2 | ... 31 | lastday 2237<time> = <hour>:<minute> | 2238 <12hour>:<minute>am | 2239 <12hour>:<minute>pm 2240<time-spec> = <at-keyword> <time> | 2241 <hourly-keyword> 2242<date-keyword> = <void-keyword> <weekly-keyword> 2243<day-range> = <day>-<day> 2244<month-range> = <month-keyword>-<month-keyword> 2245<wday-range> = <wday-keyword>-<wday-keyword> 2246<range> = <day-range> | <month-range> | 2247 <wday-range> 2248<date> = <date-keyword> | <day> | <range> 2249<date-spec> = <date> | <date-spec> 2250<day-spec> = <day> | <wday-keyword> | 2251 <day> | <wday-range> | 2252 <week-keyword> <wday-keyword> | 2253 <week-keyword> <wday-range> | 2254 <daily-keyword> 2255<month-spec> = <month-keyword> | <month-range> | 2256 <monthly-keyword> 2257<date-time-spec> = <month-spec> <day-spec> <time-spec> 2258\end{verbatim} 2259\normalsize 2260 2261\end{description} 2262 2263Note, the Week of Year specification wnn follows the ISO standard definition 2264of the week of the year, where Week 1 is the week in which the first Thursday 2265of the year occurs, or alternatively, the week which contains the 4th of 2266January. Weeks are numbered w01 to w53. w00 for Bacula is the week that 2267precedes the first ISO week (i.e. has the first few days of the year if any 2268occur before Thursday). w00 is not defined by the ISO specification. A week 2269starts with Monday and ends with Sunday. 2270 2271According to the NIST (US National Institute of Standards and Technology), 227212am and 12pm are ambiguous and can be defined to anything. However, 227312:01am is the same as 00:01 and 12:01pm is the same as 12:01, so Bacula 2274defines 12am as 00:00 (midnight) and 12pm as 12:00 (noon). You can avoid 2275this abiguity (confusion) by using 24 hour time specifications (i.e. no 2276am/pm). This is the definition in Bacula version 2.0.3 and later. 2277 2278An example schedule resource that is named {\bf WeeklyCycle} and runs a job 2279with level full each Sunday at 2:05am and an incremental job Monday through 2280Saturday at 2:05am is: 2281 2282\footnotesize 2283\begin{verbatim} 2284Schedule { 2285 Name = "WeeklyCycle" 2286 Run = Level=Full sun at 2:05 2287 Run = Level=Incremental mon-sat at 2:05 2288} 2289\end{verbatim} 2290\normalsize 2291 2292An example of a possible monthly cycle is as follows: 2293 2294\footnotesize 2295\begin{verbatim} 2296Schedule { 2297 Name = "MonthlyCycle" 2298 Run = Level=Full Pool=Monthly 1st sun at 2:05 2299 Run = Level=Differential 2nd-5th sun at 2:05 2300 Run = Level=Incremental Pool=Daily mon-sat at 2:05 2301} 2302\end{verbatim} 2303\normalsize 2304 2305The first of every month: 2306 2307\footnotesize 2308\begin{verbatim} 2309Schedule { 2310 Name = "First" 2311 Run = Level=Full on 1 at 2:05 2312 Run = Level=Incremental on 2-31 at 2:05 2313} 2314\end{verbatim} 2315\normalsize 2316 2317Every 10 minutes: 2318 2319\footnotesize 2320\begin{verbatim} 2321Schedule { 2322 Name = "TenMinutes" 2323 Run = Level=Full hourly at 0:05 2324 Run = Level=Full hourly at 0:15 2325 Run = Level=Full hourly at 0:25 2326 Run = Level=Full hourly at 0:35 2327 Run = Level=Full hourly at 0:45 2328 Run = Level=Full hourly at 0:55 2329} 2330\end{verbatim} 2331\normalsize 2332 2333\section{Technical Notes on Schedules} 2334\index[general]{Schedules!Technical Notes on} 2335\index[general]{Technical Notes on Schedules} 2336 2337Internally Bacula keeps a schedule as a bit mask. There are six masks and a 2338minute field to each schedule. The masks are hour, day of the month (mday), 2339month, day of the week (wday), week of the month (wom), and week of the year 2340(woy). The schedule is initialized to have the bits of each of these masks 2341set, which means that at the beginning of every hour, the job will run. When 2342you specify a month for the first time, the mask will be cleared and the bit 2343corresponding to your selected month will be selected. If you specify a second 2344month, the bit corresponding to it will also be added to the mask. Thus when 2345Bacula checks the masks to see if the bits are set corresponding to the 2346current time, your job will run only in the two months you have set. Likewise, 2347if you set a time (hour), the hour mask will be cleared, and the hour you 2348specify will be set in the bit mask and the minutes will be stored in the 2349minute field. 2350 2351For any schedule you have defined, you can see how these bits are set by doing 2352a {\bf show schedules} command in the Console program. Please note that the 2353bit mask is zero based, and Sunday is the first day of the week (bit zero). 2354 2355\input{fileset} 2356 2357\section{The Client Resource} 2358\label{ClientResource2} 2359\index[general]{Resource!Client} 2360\index[general]{Client Resource} 2361 2362The Client resource defines the attributes of the Clients that are served by 2363this Director; that is the machines that are to be backed up. You will need 2364one Client resource definition for each machine to be backed up. 2365 2366\begin{description} 2367 2368\item [Client (or FileDaemon)] 2369 \index[dir]{Client (or FileDaemon)} 2370 \index[dir]{Directive!Client (or FileDaemon)} 2371 Start of the Client directives. 2372 2373\item [Name = \lt{}name\gt{}] 2374 \index[dir]{Name} 2375 \index[dir]{Directive!Name} 2376 The client name which will be used in the Job resource directive or in the 2377console run command. This directive is required. 2378 2379\item [Enabled = \lt{}yes\vb{}no\gt{}] 2380 \index[dir]{Enable} 2381 \index[dir]{Directive!Enable} 2382 This directive allows you to enable or disable the Client resource. 2383 If the resource is disabled, the Client will not be used. 2384 2385\item [Address = \lt{}address\gt{}] 2386 \index[dir]{Address} 2387 \index[dir]{Directive!FD Address} 2388 \index[dir]{File Daemon Address} 2389 \index[dir]{Client Address} 2390 Where the address is a host name, a fully qualified domain name, or a 2391 network address in dotted quad notation for a Bacula File server daemon. 2392 This directive is required. 2393 2394\item [FD Port = \lt{}port-number\gt{}] 2395 \index[dir]{FD Port} 2396 \index[dir]{Directive!FD Port} 2397 Where the port is a port number at which the Bacula File server daemon can 2398 be contacted. The default is 9102. 2399 2400\item [Catalog = \lt{}Catalog-resource-name\gt{}] 2401 \index[dir]{Catalog} 2402 \index[dir]{Directive!Catalog} 2403 This specifies the name of the catalog resource to be used for this Client. 2404 This directive is required. 2405 2406\item [Password = \lt{}password\gt{}] 2407 \index[dir]{Password} 2408 \index[dir]{Directive!Password} 2409 This is the password to be used when establishing a connection with the File 2410 services, so the Client configuration file on the machine to be backed up 2411 must have the same password defined for this Director. This directive is 2412 required. If you have either {\bf /dev/random} {\bf bc} on your machine, 2413 Bacula will generate a random password during the configuration process, 2414 otherwise it will be left blank. 2415 2416 The password is plain text. It is not generated through any special 2417 process, but it is preferable for security reasons to make the text 2418 random. 2419 2420\item [Snapshot Retention = \lt{}time-period-specification\gt{}] 2421 \index[dir]{Snapshot Retention} 2422 \index[dir]{Directive!Snapshot Retention} 2423 2424 The Snapshot Retention directive defines the length of time that Bacula 2425 will keep Snapshots in the Catalog database and on the Client after the 2426 Snapshot creation. When this time period expires, and if using the 2427 \texttt{snapshot prune} command, Bacula will prune (remove) Snapshot 2428 records that are older than the specified Snapshot Retention period and 2429 will contact the FileDaemon to delete Snapshots from the system. 2430 2431 The Snapshot retention period is specified as seconds, minutes, hours, 2432 days, weeks, months, quarters, or years. See the \ilink{ Configuration 2433 chapter}{Time} of this manual for additional details of time 2434 specification. 2435 2436 The default is 0 seconds, Snapshots are deleted at the end of the 2437 backup. The Job \textbf{SnapshotRetention} directive overwrites the 2438 Client \textbf{SnapshotRetention} directive. 2439 2440\item [File Retention = \lt{}time-period-specification\gt{}] 2441 \label{FileRetention} 2442 \index[dir]{File Retention} 2443 \index[dir]{Directive!File Retention} 2444 The File Retention directive defines the length of time that Bacula will 2445 keep File records in the Catalog database after the End time of the 2446 Job corresponding to the File records. 2447 When this time period expires, and if 2448 {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) File 2449 records that are older than the specified File Retention period. Note, 2450 this affects only records in the catalog database. It does not affect 2451 your archive backups. 2452 2453 File records may actually be retained for a shorter period than you 2454 specify on this directive if you specify either a shorter {\bf Job 2455 Retention} or a shorter {\bf Volume Retention} period. The shortest 2456 retention period of the three takes precedence. The time may be 2457 expressed in seconds, minutes, hours, days, weeks, months, quarters, or 2458 years. See the \ilink{Configuration chapter}{Time} of this manual for 2459 additional details of time specification. 2460 2461 The default is 60 days. 2462 2463\item [Job Retention = \lt{}time-period-specification\gt{}] 2464 \label{JobRetention} 2465 \index[dir]{Job Retention} 2466 \index[dir]{Directive!Job Retention} 2467 The Job Retention directive defines the length of time that Bacula will keep 2468 Job records in the Catalog database after the Job End time. When 2469 this time period expires, and if {\bf AutoPrune} is set to {\bf yes} 2470 Bacula will prune (remove) Job records that are older than the specified 2471 File Retention period. As with the other retention periods, this 2472 affects only records in the catalog and not data in your archive backup. 2473 2474 If a Job record is selected for pruning, all associated File and JobMedia 2475 records will also be pruned regardless of the File Retention period set. 2476 As a consequence, you normally will set the File retention period to be 2477 less than the Job retention period. The Job retention period can actually 2478 be less than the value you specify here if you set the {\bf Volume 2479 Retention} directive in the Pool resource to a smaller duration. This is 2480 because the Job retention period and the Volume retention period are 2481 independently applied, so the smaller of the two takes precedence. 2482 2483 The Job retention period is specified as seconds, minutes, hours, days, 2484 weeks, months, quarters, or years. See the 2485 \ilink{Configuration chapter}{Time} of this manual for 2486 additional details of time specification. 2487 2488 The default is 180 days. 2489 2490\label{AutoPrune} 2491\item [AutoPrune = \lt{}yes\vb{}no\gt{}] 2492 \index[dir]{AutoPrune} 2493 \index[dir]{Directive!AutoPrune} 2494 If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater) 2495 will automatically apply the File retention period and the Job retention 2496 period for the Client at the end of the Job. If you set {\bf AutoPrune = no}, 2497 pruning will not be done, and your Catalog will grow in size each time you 2498 run a Job. Pruning affects only information in the catalog and not data 2499 stored in the backup archives (on Volumes). 2500 2501\item [Maximum Concurrent Jobs = \lt{}number\gt{}] 2502 \index[dir]{Maximum Concurrent Jobs} 2503 \index[dir]{Directive!Maximum Concurrent Jobs} 2504 where \lt{}number\gt{} is the maximum number of Jobs with the current Client 2505 that can run concurrently. Note, this directive limits only Jobs for Clients 2506 with the same name as the resource in which it appears. Any other 2507 restrictions on the maximum concurrent jobs such as in the Director, Job, or 2508 Storage resources will also apply in addition to any limit specified here. 2509 The default is set to 1, but you may set it to a larger number. 2510 2511\item [Maximum Bandwidth Per Job = \lt{}speed\gt{}] 2512\index[dir]{Maximum Bandwidth Per Job} 2513\index[dir]{Directive!Maximum Bandwidth Per Job} 2514 2515The speed parameter specifies the maximum allowed bandwidth that a job may 2516use when started for this Client. The speed parameter should be specified 2517in k/s, Kb/s, m/s or Mb/s, which are respective 1,000 bytes per second, 25181,024 bytes per second, 1,000,000 bytes per second, or 1,048,576 bytes per 2519second. 2520 2521\item [Priority = \lt{}number\gt{}] 2522 \index[dir]{Priority} 2523 \index[dir]{Directive!Priority} 2524 The number specifies the priority of this client relative to other clients 2525 that the Director is processing simultaneously. The priority can range from 2526 1 to 1000. The clients are ordered such that the smaller number priorities 2527 are performed first (not currently implemented). 2528 2529\label{Director:Client:SDCallsClient} 2530\item [SD Calls Client = \lt{}yes/no\gt{}] 2531\index[dir]{SD Calls Client} 2532\index[dir]{Directive!SD Calls Client} 2533 2534If the {\bf SD Calls Client} directive is set to true in a Client resource 2535any Backup, Restore, Verify, Copy, or Migration Job where the client 2536is involved, the client will wait for the Storage daemon to contact it. 2537By default this directive is set to false, and the Client will call 2538the Storage daemon. This directive can be useful if your Storage daemon 2539is behind a firewall that permits outgoing connections but not incoming 2540one. The following picture shows the communications connection paths in 2541both cases. 2542 2543\includegraphics[width=0.8\linewidth]{sd-calls-client} 2544 2545 2546\end{description} 2547 2548 The following is an example of a valid Client resource definition: 2549 2550\footnotesize 2551\begin{verbatim} 2552Client { 2553 Name = Minimatou 2554 Address = minimatou 2555 Catalog = MySQL 2556 Password = very_good 2557} 2558\end{verbatim} 2559\normalsize 2560 2561\section{The Storage Resource} 2562\label{StorageResource2} 2563\index[general]{Resource!Storage} 2564\index[general]{Storage Resource} 2565 2566The Storage resource defines which Storage daemons are available for use by 2567the Director. 2568 2569\begin{description} 2570 2571\item [Storage] 2572 \index[dir]{Storage} 2573 \index[dir]{Directive!Storage} 2574 Start of the Storage resources. At least one storage resource must be 2575 specified. 2576 2577\item [Name = \lt{}name\gt{}] 2578 \index[dir]{Name} 2579 \index[dir]{Directive!Name} 2580 The name of the storage resource. This name appears on the Storage directive 2581 specified in the Job resource and is required. 2582 2583\item [Enabled = \lt{}yes\vb{}no\gt{}] 2584 \index[dir]{Enable} 2585 \index[dir]{Directive!Enable} 2586 This directive allows you to enable or disable a Storage resource. When the 2587 resource is disabled, the storage device will not be used. To reuse it 2588 you must re-enable the Storage resource. 2589 2590\item [Address = \lt{}address\gt{}] 2591 \index[dir]{Address} 2592 \index[dir]{Directive!SD Address} 2593 \index[dir]{Storage daemon Address} 2594 Where the address is a host name, a {\bf fully qualified domain name}, 2595 or an {\bf IP address}. Please note that the \lt{}address\gt{} as 2596 specified here will be transmitted to the File daemon who will then use 2597 it to contact the Storage daemon. Hence, it is {\bf not}, a good idea 2598 to use {\bf localhost} as the name but rather a fully qualified machine 2599 name or an IP address. This directive is required. 2600 2601\item [FD Storage Address = \lt{}address\gt{}] 2602 \index[dir]{FDStorageAddress} 2603 \index[dir]{Directive!FD Storage Address} 2604 \index[dir]{Storage daemon Address} 2605 Where the address is a host name, a {\bf fully qualified domain name}, 2606 or an {\bf IP address}. The \lt{}address\gt{} specified here will be 2607 transmitted to the File daemon instead of the IP address that the 2608 Director uses to contact the Storage daemon. This FDStorageAddress 2609 will then be used by the File daemon to contact the Storage daemon. 2610 This directive particularly useful if the File daemon is in a 2611 different network domain than the Director or Storage daemon. 2612 It is also useful in NAT or firewal environments. 2613 2614\begin{figure}[htbp] 2615 \centering 2616 \includegraphics[width=0.8\linewidth]{BackupOverWan1} 2617 \caption{Backup over WAN using FD Storage Address} 2618 \label{fig:backupwan} 2619\end{figure} 2620 2621\item [SD Port = \lt{}port\gt{}] 2622 \index[dir]{SD Port} 2623 \index[dir]{Directive!SD Port} 2624 Where port is the port to use to contact the storage daemon for 2625 information and to start jobs. This same port number must appear in the 2626 Storage resource of the Storage daemon's configuration file. The 2627 default is 9103. 2628 2629\item [Password = \lt{}password\gt{}] 2630 \index[dir]{Password} 2631 \index[dir]{Directive!Password} 2632 This is the password to be used when establishing a connection with the 2633 Storage services. This same password also must appear in the Director 2634 resource of the Storage daemon's configuration file. This directive is 2635 required. If you have either {\bf /dev/random} {\bf bc} on your machine, 2636 Bacula will generate a random password during the configuration process, 2637 otherwise it will be left blank. 2638 2639 The password is plain text. It is not generated through any special 2640 process, but it is preferable for security reasons to use random text. 2641 2642\item [Device = \lt{}device-name\gt{}] 2643 \index[dir]{Device} 2644 \index[dir]{Directive!Device} 2645 This directive specifies the Storage daemon's name of the device 2646 resource to be used for the storage. If you are using an Autochanger, 2647 the name specified here should be the name of the Storage daemon's 2648 Autochanger resource rather than the name of an individual device. This 2649 name is not the physical device name, but the logical device name as 2650 defined on the {\bf Name} directive contained in the {\bf Device} or the 2651 {\bf Autochanger} resource definition of the {\bf Storage daemon} 2652 configuration file. You can specify any name you would like (even the 2653 device name if you prefer) up to a maximum of 127 characters in length. 2654 The physical device name associated with this device is specified in the 2655 {\bf Storage daemon} configuration file (as {\bf Archive Device}). 2656 Please take care not to define two different Storage resource directives 2657 in the Director that point to the same Device in the Storage daemon. 2658 Doing so may cause the Storage daemon to block (or hang) attempting to 2659 open the same device that is already open. This directive is required. 2660 2661\label{MediaType} 2662\item [Media Type = \lt{}MediaType\gt{}] 2663 \index[dir]{Media Type} 2664 \index[dir]{Directive!Media Type} 2665 This directive specifies the Media Type to be used to store the data. 2666 This is an arbitrary string of characters up to 127 maximum that you 2667 define. It can be anything you want. However, it is best to make it 2668 descriptive of the storage media (e.g. File, DAT, "HP DLT8000", 8mm, 2669 ...). 2670 2671\smallskip 2672 In addition, it is essential that you make the {\bf Media Type} 2673 specification unique for each storage Device in the bacula-sd.conf file. 2674 If you have two DDS-4 drives that have incompatible formats, or if you 2675 have a DDS-4 drive and a DDS-4 autochanger, you almost certainly should 2676 specify different {\bf Media Types}. During a restore, assuming a {\bf 2677 DDS-4} Media Type is associated with the Job, Bacula can decide to use 2678 any Storage daemon that supports Media Type {\bf DDS-4} and on any drive 2679 that supports it. 2680 2681\smallskip 2682 If you are writing to disk Volumes, please make doubly sure that each 2683 Device resource defined in the Storage daemon (and hence in the 2684 Director's conf file) has a unique media type. Otherwise for Bacula 2685 your restores may not work because Bacula will assume that you can mount 2686 any Media Type with the same name on any Device associated with that 2687 Media Type. This is possible with tape drives, but with disk drives, 2688 unless you are very clever you cannot mount a Volume in any directory -- 2689 this can be done by creating an appropriate soft link. 2690 2691\smallskip 2692 Currently Bacula permits only a single Media Type per Storage Device 2693 definition. Consequently, if you have a drive that supports more than 2694 one Media Type, you can give a unique string to Volumes with different 2695 intrinsic Media Type (Media Type = DDS-3-4 for DDS-3 and DDS-4 types), 2696 but then those volumes will only be mounted on drives indicated with the 2697 dual type (DDS-3-4). 2698 2699\smallskip 2700 If you want to tie Bacula to using a single Storage daemon or drive, you 2701 must specify a unique Media Type for that drive. This is an important 2702 point that should be carefully understood. Note, this applies equally 2703 to Disk Volumes. If you define more than one disk Device resource in 2704 your Storage daemon's conf file, the Volumes on those two devices are in 2705 fact incompatible because one can not physically be mounted on the other 2706 device since they are found in different directories. For this reason, 2707 you probably should use two different Media Types for your two disk 2708 Devices (even though you might think of them as both being File types). 2709 You can find more on this subject in the \ilink{Basic Volume 2710 Management}{DiskChapter} chapter of this manual. 2711 2712\smallskip 2713 The {\bf MediaType} specified in the Director's Storage resource, {\bf 2714 must} correspond to the {\bf Media Type} specified in the {\bf Device} 2715 resource of the {\bf Storage daemon} configuration file. This directive 2716 is required, and it is used by the Director and the Storage daemon to 2717 ensure that a Volume automatically selected from the Pool corresponds to 2718 the physical device. If a Storage daemon handles multiple devices (e.g. 2719 will write to various file Volumes on different partitions), this 2720 directive allows you to specify exactly which device. 2721 2722\smallskip 2723 As mentioned above, the value specified in the Director's Storage 2724 resource must agree with the value specified in the Device resource in 2725 the {\bf Storage daemon's} configuration file. It is also an additional 2726 check so that you don't try to write data for a DLT onto an 8mm device. 2727 2728\label{Autochanger1} 2729\item [Autochanger = \lt{}yes\vb{}no\gt{}] 2730 \index[dir]{Autochanger} 2731 \index[dir]{Directive!Autochanger} 2732 If you specify {\bf yes} for this command (the default is {\bf no}), 2733 when you use the {\bf label} command or the {\bf add} command to create 2734 a new Volume, {\bf Bacula} will also request the Autochanger Slot 2735 number. This simplifies creating database entries for Volumes in an 2736 autochanger. If you forget to specify the Slot, the autochanger will 2737 not be used. However, you may modify the Slot associated with a Volume 2738 at any time by using the {\bf update volume} or {\bf update slots} 2739 command in the console program. When {\bf autochanger} is enabled, the 2740 algorithm used by Bacula to search for available volumes will be 2741 modified to consider only Volumes that are known to be in the 2742 autochanger's magazine. If no {\bf in changer} volume is found, Bacula 2743 will attempt recycling, pruning, ..., and if still no volume is found, 2744 Bacula will search for any volume whether or not in the magazine. By 2745 privileging in changer volumes, this procedure minimizes operator 2746 intervention. The default is {\bf no}. 2747 2748\smallskip 2749 For the autochanger to be used, you must also specify {\bf Autochanger = 2750 yes} in the \ilink{Device Resource}{Autochanger} in the Storage daemon's 2751 configuration file as well as other important Storage daemon 2752 configuration information. To help Bacula understand your 2753 Autochanger setup, instead of using the Directive {\bf Autochanger = 2754 yes}, it is preferable to specify the name of the Autochanger in place 2755 of the word {\bf yes}. 2756 Please consult the \ilink{Using 2757 Autochangers}{AutochangersChapter} manual of this chapter for the 2758 details of using autochangers. 2759 2760\item [Maximum Concurrent Jobs = \lt{}number\gt{}] 2761 \index[dir]{Maximum Concurrent Jobs} 2762 \index[dir]{Directive!Maximum Concurrent Jobs} 2763 where \lt{}number\gt{} is the maximum number of Jobs with the current 2764 Storage resource that can run concurrently. Note, this directive limits 2765 only Jobs for Jobs using this Storage daemon. Any other restrictions on 2766 the maximum concurrent jobs such as in the Director, Job, or Client 2767 resources will also apply in addition to any limit specified here. The 2768 default is set to 1, but you may set it to a larger number. However, if 2769 you set the Storage daemon's number of concurrent jobs greater than one, 2770 we recommend that you read the warning documented under \ilink{Maximum 2771 Concurrent Jobs}{DirMaxConJobs} in the Director's resource or simply 2772 turn data spooling on as documented in the \ilink{Data 2773 Spooling}{SpoolingChapter} chapter of this manual. 2774 2775\item [Maximum Concurrent Read Jobs = \lt{}number\gt{}] 2776 \index[dir]{MaximumConcurrentReadJobs} 2777 \index[dir]{Directive!MaximumConcurrentReadJobs} 2778 The main purpose of this directive is to limit the number of concurrent 2779 Copy, Migration, and VirtualFull jobs so that they don't monopolize all 2780 the Storage drives causing a deadlock situation where all the drives are 2781 allocated for reading but none remain for writing. This deadlock 2782 situation can occur when running multiple simultaneous Copy, Migration, 2783 and VirtualFull jobs. 2784 2785\smallskip 2786 The default value is set to 0 (zero), which means there is no limit on 2787 the number of read jobs. Note, limiting the read jobs does not apply to 2788 Restore jobs, which are normally started by hand. A reasonable value for 2789 this directive is one half the number of drives that the Storage resource 2790 has rounded down. Doing so, will leave the same number of drives for 2791 writing and will generally avoid over committing drives and a deadlock. 2792 2793\item [AllowCompression = \lt{}yes\vb{}no\gt{}] 2794 \label{AllowCompression} 2795 \index[dir]{AllowCompression} 2796 \index[dir]{Directive!AllowCompression} 2797 2798 This directive is optional, and if you specify {\bf No} (the default is 2799 {\bf Yes}), it will cause backups jobs running on this storage resource 2800 to run without client File Daemon compression. This effectively 2801 overrides compression options in FileSets used by jobs which use this 2802 storage resource. 2803 2804\item [Heartbeat Interval = \lt{}time-interval\gt{}] 2805 \index[dir]{Heartbeat Interval} 2806 \index[dir]{Directive!Heartbeat} 2807 This directive is optional and if specified will cause the Director to 2808 set a keepalive interval (heartbeat) in seconds on each of the sockets 2809 it opens for the Storage resource. This value will override any 2810 specified at the Director level. It is implemented only on systems 2811 (Linux, ...) that provide the {\bf setsockopt} TCP\_KEEPIDLE function. 2812 The default value is 300 seconds (5 minutes). 2813 2814\end{description} 2815 2816The following is an example of a valid Storage resource definition: 2817 2818\footnotesize 2819\begin{verbatim} 2820# Definition of tape storage device 2821Storage { 2822 Name = DLTDrive 2823 Address = lpmatou 2824 Password = storage_password # password for Storage daemon 2825 Device = "HP DLT 80" # same as Device in Storage daemon 2826 Media Type = DLT8000 # same as MediaType in Storage daemon 2827} 2828\end{verbatim} 2829\normalsize 2830 2831\section{The Autochanger Resources} 2832\index[general]{Resource!Autochanger} 2833\index[general]{Autochanger Resource} 2834 2835Each autochanger that you have defined in an {\bf Autochanger} resource in 2836the Storage daemon's {\bf bacula-sd.conf} file, must have a corresponding 2837{\bf Autochanger} resource defined in the Director's {\bf bacula-dir.conf} file. 2838The {\bf Autochanger} resource uses the same directives as the {\bf Storage} 2839resource defined \vref{StorageResource}. 2840 2841Normally you will already have a {\bf Storage} resource that points to the 2842Storage daemon's {\bf Autochanger} resource. Thus you need only to change 2843the name of the {\bf Storage} resource to {\bf Autochanger}. In addition 2844the {\bf Autochanger = yes} directive is not needed in the Director's {\bf 2845 Autochanger} resource, since the resource name is {\bf Autochanger}, the 2846Director already knows that it represents an autochanger. 2847 2848\smallskip 2849In addition to the above change ({\bf Storage} to {\bf Autochanger}), 2850you must modify any additional {\bf Storage} resources that correspond 2851to devices that are part of the {\bf Autochanger} device. 2852Instead of the previous {\bf Autochanger = yes} directive they 2853should be modified to be {\bf Autochanger = xxx} where you 2854replace the {\bf xxx} with the name of the Autochanger. 2855 2856\smallskip 2857For example, in the bacula-dir.conf file: 2858 2859\begin{verbatim} 2860Autochanger { # New resource 2861 Name = Changer-1 2862 Address = cibou.company.com 2863 SDPort = 9103 2864 Password = "xxxxxxxxxx" 2865 Device = LTO-Changer-1 2866 Media Type = LTO-4 2867 Maximum Concurrent Jobs = 50 2868} 2869 2870Storage { 2871 Name = Changer-1-Drive0 2872 Address = cibou.company.com 2873 SDPort = 9103 2874 Password = "xxxxxxxxxx" 2875 Device = LTO4_1_Drive0 2876 Media Type = LTO-4 2877 Maximum Concurrent Jobs = 5 2878 Autochanger = Changer-1 # New directive 2879} 2880 2881Storage { 2882 Name = Changer-1-Drive1 2883 Address = cibou.company.com 2884 SDPort = 9103 2885 Password = "xxxxxxxxxx" 2886 Device = LTO4_1_Drive1 2887 Media Type = LTO-4 2888 Maximum Concurrent Jobs = 5 2889 Autochanger = Changer-1 # New directive 2890} 2891 2892... 2893\end{verbatim} 2894 2895Note that Storage resources {\bf Changer-1-Drive0} and {\bf 2896Changer-1-Drive1} are not required since they make up part of an 2897autochanger, and normally, Jobs refer only to the Autochanger resource. 2898However, by referring to those Storage definitions in a Job, you will use 2899only the indicated drive. This is not normally what you want to do, but it 2900is very useful and often used for reserving a drive for restores. See the 2901Storage daemon example .conf below and the use of {\bf AutoSelect = no}. 2902 2903 2904\section{The Pool Resource} 2905\label{PoolResource} 2906\index[general]{Resource!Pool} 2907\index[general]{Pool Resource} 2908 2909The Pool resource defines the set of storage Volumes (tapes or files) to be 2910used by Bacula to write the data. By configuring different Pools, you can 2911determine which set of Volumes (media) receives the backup data. This permits, 2912for example, to store all full backup data on one set of Volumes and all 2913incremental backups on another set of Volumes. Alternatively, you could assign 2914a different set of Volumes to each machine that you backup. This is most 2915easily done by defining multiple Pools. 2916 2917Another important aspect of a Pool is that it contains the default attributes 2918(Maximum Jobs, Retention Period, Recycle flag, ...) that will be given to a 2919Volume when it is created. This avoids the need for you to answer a large 2920number of questions when labeling a new Volume. Each of these attributes can 2921later be changed on a Volume by Volume basis using the {\bf update} command in 2922the console program. Note that you must explicitly specify which Pool Bacula 2923is to use with each Job. Bacula will not automatically search for the correct 2924Pool. 2925 2926Most often in Bacula installations all backups for all machines (Clients) go 2927to a single set of Volumes. In this case, you will probably only use the {\bf 2928Default} Pool. If your backup strategy calls for you to mount a different tape 2929each day, you will probably want to define a separate Pool for each day. For 2930more information on this subject, please see the 2931\ilink{Backup Strategies}{StrategiesChapter} chapter of this 2932manual. 2933 2934To use a Pool, there are three distinct steps. First the Pool must be defined 2935in the Director's configuration file. Then the Pool must be written to the 2936Catalog database. This is done automatically by the Director each time that it 2937starts, or alternatively can be done using the {\bf create} command in the 2938console program. Finally, if you change the Pool definition in the Director's 2939configuration file and restart Bacula, the pool will be updated alternatively 2940you can use the {\bf update pool} console command to refresh the database 2941image. It is this database image rather than the Director's resource image 2942that is used for the default Volume attributes. Note, for the pool to be 2943automatically created or updated, it must be explicitly referenced by a Job 2944resource. 2945 2946Next the physical media must be labeled. The labeling can either be done with 2947the {\bf label} command in the {\bf console} program or using the {\bf btape} 2948program. The preferred method is to use the {\bf label} command in the {\bf 2949console} program. 2950 2951Finally, you must add Volume names (and their attributes) to the Pool. For 2952Volumes to be used by Bacula they must be of the same {\bf Media Type} as the 2953archive device specified for the job (i.e. if you are going to back up to a 2954DLT device, the Pool must have DLT volumes defined since 8mm volumes cannot be 2955mounted on a DLT drive). The {\bf Media Type} has particular importance if you 2956are backing up to files. When running a Job, you must explicitly specify which 2957Pool to use. Bacula will then automatically select the next Volume to use from 2958the Pool, but it will ensure that the {\bf Media Type} of any Volume selected 2959from the Pool is identical to that required by the Storage resource you have 2960specified for the Job. 2961 2962If you use the {\bf label} command in the console program to label the 2963Volumes, they will automatically be added to the Pool, so this last step is 2964not normally required. 2965 2966It is also possible to add Volumes to the database without explicitly labeling 2967the physical volume. This is done with the {\bf add} console command. 2968 2969As previously mentioned, each time Bacula starts, it scans all the Pools 2970associated with each Catalog, and if the database record does not already 2971exist, it will be created from the Pool Resource definition. {\bf Bacula} 2972probably should do an {\bf update pool} if you change the Pool definition, but 2973currently, you must do this manually using the {\bf update pool} command in 2974the Console program. 2975 2976The Pool Resource defined in the Director's configuration file 2977(bacula-dir.conf) may contain the following directives: 2978 2979\begin{description} 2980 2981\item [Pool] 2982 \index[dir]{Pool} 2983 \index[dir]{Directive!Pool} 2984 Start of the Pool resource. There must be at least one Pool resource 2985 defined. 2986 2987 2988\item [Name = \lt{}name\gt{}] 2989 \index[dir]{Name} 2990 \index[dir]{Directive!Name} 2991 The name of the pool. For most applications, you will use the default 2992 pool name {\bf Default}. This directive is required. 2993 2994\label{MaxVolumes} 2995\item [Maximum Volumes = \lt{}number\gt{}] 2996 \index[dir]{Maximum Volumes} 2997 \index[dir]{Directive!Maximum Volumes} 2998 This directive specifies the maximum number of volumes (tapes or files) 2999 contained in the pool. This directive is optional, if omitted or set to 3000 zero, any number of volumes will be permitted. In general, this 3001 directive is useful for Autochangers where there is a fixed number of 3002 Volumes, or for File storage where you wish to ensure that the backups 3003 made to disk files do not become too numerous or consume too much space. 3004\smallskip 3005 This directive is only applied to case of volumes automatically created 3006 by Bacula. If you add volumes to a pool manually with the {\bf label} 3007 command, it is possible to have more volumes in a pool than specified by 3008 {\bf Maximum Volumes}. 3009 3010\item [Pool Type = \lt{}type\gt{}] 3011 \index[dir]{Pool Type} 3012 \index[dir]{Directive!Pool Type} 3013 This directive defines the pool type, which corresponds to the type of 3014 Job being run. It is required and may be one of the following: 3015 3016\begin{itemize} 3017 \item [Backup] 3018 \item [*Archive] 3019 \item [*Cloned] 3020 \item [*Migration] 3021 \item [*Copy] 3022 \item [*Save] 3023\end{itemize} 3024 Note, only Backup is current implemented. 3025 3026\item [Storage = \lt{}storage-resource-name\gt{}] 3027\index[dir]{Storage} 3028\index[dir]{Directive!Storage} 3029 The Storage directive defines the name of the storage services where you 3030 want to backup the FileSet data. For additional details, see the 3031 \ilink{Storage Resource Chapter}{StorageResource2} of this manual. 3032 The Storage resource may also be specified in the Job resource, 3033 but the value, if any, in the Pool resource overrides any value 3034 in the Job. This Storage resource definition is not required by either 3035 the Job resource or in the Pool, but it must be specified in 3036 one or the other. If not configuration error will result. 3037 3038\item [Use Volume Once = \lt{}yes\vb{}no\gt{}] 3039 \index[dir]{Use Volume Once} 3040 \index[dir]{Directive!Use Volume Once} 3041 This directive if set to {\bf yes} specifies that each volume is to be 3042 used only once. This is most useful when the Media is a file and you 3043 want a new file for each backup that is done. The default is {\bf no} 3044 (i.e. use volume any number of times). This directive will most likely 3045 be phased out (deprecated), so you are recommended to use {\bf Maximum 3046 Volume Jobs = 1} instead. 3047 3048 The value defined by this directive in the bacula-dir.conf file is the 3049 default value used when a Volume is created. Once the volume is 3050 created, changing the value in the bacula-dir.conf file will not change 3051 what is stored for the Volume. To change the value for an existing 3052 Volume you must use the {\bf update} command in the Console. 3053 3054 Please see the notes below under {\bf Maximum Volume Jobs} concerning 3055 using this directive with multiple simultaneous jobs. 3056 3057\item [Maximum Volume Jobs = \lt{}positive-integer\gt{}] 3058 \index[dir]{Maximum Volume Jobs} 3059 \index[dir]{Directive!Maximum Volume Jobs} 3060 This directive specifies the maximum number of Jobs that can be written 3061 to the Volume. If you specify zero (the default), there is no limit. 3062 Otherwise, when the number of Jobs backed up to the Volume equals {\bf 3063 positive-integer} the Volume will be marked {\bf Used}. When the Volume 3064 is marked {\bf Used} it can no longer be used for appending Jobs, much 3065 like the {\bf Full} status, but it can be recycled if recycling is 3066 enabled, and thus used again. By setting {\bf MaximumVolumeJobs} to 3067 one, you get the same effect as setting {\bf UseVolumeOnce = yes}. 3068 3069 The value defined by this directive in the bacula-dir.conf 3070 file is the default value used when a Volume is created. Once the volume is 3071 created, changing the value in the bacula-dir.conf file will not change what 3072 is stored for the Volume. To change the value for an existing Volume you 3073 must use the {\bf update} command in the Console. 3074 3075 If you are running multiple simultaneous jobs, this directive may not 3076 work correctly because when a drive is reserved for a job, this 3077 directive is not taken into account, so multiple jobs may try to 3078 start writing to the Volume. At some point, when the Media record is 3079 updated, multiple simultaneous jobs may fail since the Volume can no 3080 longer be written. 3081 3082\item [Maximum Volume Files = \lt{}positive-integer\gt{}] 3083 \index[dir]{Maximum Volume Files} 3084 \index[dir]{Directive!Maximum Volume Files} 3085 This directive specifies the maximum number of files that can be written 3086 to the Volume. If you specify zero (the default), there is no limit. 3087 Otherwise, when the number of files written to the Volume equals {\bf 3088 positive-integer} the Volume will be marked {\bf Used}. When the Volume 3089 is marked {\bf Used} it can no longer be used for appending Jobs, much 3090 like the {\bf Full} status but it can be recycled if recycling is 3091 enabled and thus used again. This value is checked and the {\bf Used} 3092 status is set only at the end of a job that writes to the particular 3093 volume. 3094 3095 The value defined by this directive in the bacula-dir.conf file is the 3096 default value used when a Volume is created. Once the volume is 3097 created, changing the value in the bacula-dir.conf file will not change 3098 what is stored for the Volume. To change the value for an existing 3099 Volume you must use the {\bf update} command in the Console. 3100 3101\item [Maximum Volume Bytes = \lt{}size\gt{}] 3102 \index[dir]{Maximum Volume Bytes} 3103 \index[dir]{Directive!Maximum Volume Bytes} 3104 This directive specifies the maximum number of bytes that can be written 3105 to the Volume. If you specify zero (the default), there is no limit 3106 except the physical size of the Volume. Otherwise, when the number of 3107 bytes written to the Volume equals {\bf size} the Volume will be marked 3108 {\bf Full}. When the Volume is marked {\bf Full} it can no longer be 3109 used for appending Jobs, but it can be 3110 recycled if recycling is enabled, and thus the Volume can be re-used 3111 after recycling. The size specified is checked just before each 3112 block is written to the Volume and if the Volume size would exceed the 3113 specified Maximum Volume Bytes the {\bf Full} status will be set and 3114 the Job will request the next available Volume to continue. 3115 3116 This directive is particularly useful for restricting the size 3117 of disk volumes, and will work correctly even in the case of 3118 multiple simultaneous jobs writing to the volume. 3119 3120 The value defined by this directive in the bacula-dir.conf file is the 3121 default value used when a Volume is created. Once the volume is 3122 created, changing the value in the bacula-dir.conf file will not change 3123 what is stored for the Volume. To change the value for an existing 3124 Volume you must use the {\bf update} command in the Console. 3125 3126\item [Volume Use Duration = \lt{}time-period-specification\gt{}] 3127 \index[dir]{Volume Use Duration} 3128 \index[dir]{Directive!Volume Use Duration} 3129 The Volume Use Duration directive defines the time period that the 3130 Volume can be written beginning from the time of first data write to the 3131 Volume. If the time-period specified is zero (the default), the Volume 3132 can be written indefinitely. Otherwise, the next time a job 3133 runs that wants to access this Volume, and the time period from the 3134 first write to the volume (the first Job written) exceeds the 3135 time-period-specification, the Volume will be marked {\bf Used}, which 3136 means that no more Jobs can be appended to the Volume, but it may be 3137 recycled if recycling is enabled. Using the command {\bf 3138 status dir} applies algorithms similar to running jobs, so 3139 during such a command, the Volume status may also be changed. 3140 Once the Volume is 3141 recycled, it will be available for use again. 3142 3143 You might use this directive, for example, if you have a Volume used for 3144 Incremental backups, and Volumes used for Weekly Full backups. Once the 3145 Full backup is done, you will want to use a different Incremental 3146 Volume. This can be accomplished by setting the Volume Use Duration for 3147 the Incremental Volume to six days. I.e. it will be used for the 6 3148 days following a Full save, then a different Incremental volume will be 3149 used. Be careful about setting the duration to short periods such as 23 3150 hours, or you might experience problems of Bacula waiting for a tape 3151 over the weekend only to complete the backups Monday morning when an 3152 operator mounts a new tape. 3153 3154 The use duration is checked and the {\bf Used} status is set only at the 3155 end of a job that writes to the particular volume, which means that even 3156 though the use duration may have expired, the catalog entry will not be 3157 updated until the next job that uses this volume is run. This 3158 directive is not intended to be used to limit volume sizes 3159 and will not work correctly (i.e. will fail jobs) if the use 3160 duration expires while multiple simultaneous jobs are writing 3161 to the volume. 3162 3163 Please note that the value defined by this directive in the bacula-dir.conf 3164 file is the default value used when a Volume is created. Once the volume is 3165 created, changing the value in the bacula-dir.conf file will not change what 3166 is stored for the Volume. To change the value for an existing Volume you 3167 must use the 3168 \borgxrlink{update volume}{UpdateCommand}{console}{command} in the \consoleman{}. 3169 3170\item [Catalog Files = \lt{}yes\vb{}no\gt{}] 3171 \index[dir]{Catalog Files} 3172 \index[dir]{Directive!Catalog Files} 3173 This directive defines whether or not you want the names of the files 3174 that were saved to be put into the catalog. The default is {\bf yes}. 3175 The advantage of specifying {\bf Catalog Files = No} is that you will 3176 have a significantly smaller Catalog database. The disadvantage is that 3177 you will not be able to produce a Catalog listing of the files backed up 3178 for each Job (this is often called Browsing). Also, without the File 3179 entries in the catalog, you will not be able to use the Console {\bf 3180 restore} command nor any other command that references File entries. 3181 3182\label{PoolAutoPrune} 3183\item [AutoPrune = \lt{}yes\vb{}no\gt{}] 3184 \index[dir]{AutoPrune} 3185 \index[dir]{Directive!AutoPrune} 3186 If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or 3187 greater) will automatically apply the Volume Retention period when new 3188 Volume is needed and no appendable Volumes exist in the Pool. Volume 3189 pruning causes expired Jobs (older than the {\bf Volume Retention} 3190 period) to be deleted from the Catalog and permits possible recycling of 3191 the Volume. 3192 3193\label{VolRetention} 3194\item [Volume Retention = \lt{}time-period-specification\gt{}] 3195 \index[dir]{Volume Retention} 3196 \index[dir]{Directive!Volume Retention} 3197 The Volume Retention directive defines the longest amount of time that 3198 {\bf Bacula} will keep records associated with the Volume in the Catalog 3199 database after the End time of each Job written to the Volume. When 3200 this time period expires, and if {\bf AutoPrune} is set to {\bf yes} 3201 Bacula may prune (remove) Job records that are older than the specified 3202 Volume Retention period if it is necessary to free up a Volume. Note, 3203 it is also possible for all the Job and File records to be pruned before 3204 the Volume Retention period is reached. In that case the Volume can 3205 then be marked Pruned and subsequently recycled prior to expiration of 3206 the Volume Retention period. 3207 3208\smallskip 3209 Recycling will not occur until it is absolutely necessary to 3210 free up a volume (i.e. no other writable volume exists). 3211 All File records associated with pruned Jobs are also 3212 pruned. The time may be specified as seconds, minutes, hours, days, 3213 weeks, months, quarters, or years. The {\bf Volume Retention} is 3214 applied independently of the {\bf Job Retention} and the {\bf File 3215 Retention} periods defined in the Client resource. This means that all 3216 the retention periods are applied in turn and that the shorter period 3217 is the one that effectively takes precedence. Note, that when the {\bf 3218 Volume Retention} period has been reached, and it is necessary to obtain 3219 a new volume, Bacula will prune both the Job and the File records. And 3220 the inverse is also true that if all the Job and File records that 3221 refer to a Volume are pruned, then the Volume may be pruned and recycled 3222 regardless of its retention period. Pruning may also occur during a 3223 {\bf status dir} command because it uses similar algorithms for finding 3224 the next available Volume. 3225 3226 It is important to know that when the Volume Retention period expires, 3227 or all the Job and File records have been pruned that refer to a Volume, 3228 Bacula does not automatically recycle a Volume. It attempts to keep the 3229 Volume data intact as long as possible before over writing the Volume. 3230 3231 By defining multiple Pools with different Volume Retention periods, you 3232 may effectively have a set of tapes that is recycled weekly, another 3233 Pool of tapes that is recycled monthly and so on. However, one must 3234 keep in mind that if your {\bf Volume Retention} period is too short, it 3235 may prune the last valid Full backup, and hence until the next Full 3236 backup is done, you will not have a complete backup of your system, and 3237 in addition, the next Incremental or Differential backup will be 3238 promoted to a Full backup. As a consequence, the minimum {\bf Volume 3239 Retention} period should be at twice the interval of your Full backups. 3240 This means that if you do a Full backup once a month, the minimum Volume 3241 retention period should be two months. 3242 3243 The default Volume retention period is 365 days, and either the default 3244 or the value defined by this directive in the bacula-dir.conf file is 3245 the default value used when a Volume is created. Once the volume is 3246 created, changing the value in the bacula-dir.conf file will not change 3247 what is stored for the Volume. To change the value for an existing 3248 Volume you must use the {\bf update} command in the Console. 3249 3250\item [Cache Retention = \lt{}time-period-specification\gt{}] 3251 \index[dir]{Directive!Cache Retention} 3252 The Cache Retention directive defines the longest amount of time that 3253 {\bf Bacula} will keep Parts associated with the Volume in the Storage 3254 daemon Cache directory after a successful upload to the Cloud. 3255 When this time period expires, and if the \texttt{cloud prune} command 3256 is issued, Bacula may prune (remove) Parts that are older than the specified 3257 Cache Retention period. 3258 3259 Note, it is also possible for all the Parts to be removed before the Cache 3260 Retention period is reached. In that case the \texttt{cloud truncate} command 3261 must be used. 3262 3263 3264\item [Action On Purge = \lt{Truncate}] 3265\index[dir]{actiononpurge} 3266 3267The directive \textbf{ActionOnPurge=Truncate} instructs Bacula to 3268permit the Volume to be truncated after it has been purged. 3269Note: the ActionOnPurge is a bit misleading since the volume 3270is not actually truncated when it is purged, but is enabled 3271to be truncated. The actual truncation is done with the Truncate 3272command/ 3273 3274To actually truncate a Volume, you must first set the ActionOnPurge 3275to Truncate in the Pool, then you must ensure that any existing 3276Volumes also have this information in them, by doing an 3277{\bf update Volumes} comand. Finally, after the Volume 3278has been purged, you may then truncate it. 3279It is useful to prevent disk based volumes from consuming too much 3280space. See below for more details of how to ensure Volumes are 3281truncated after being purged. 3282 3283First set the Pool to permit truncation. 3284\begin{verbatim} 3285Pool { 3286 Name = Default 3287 Action On Purge = Truncate 3288 ... 3289} 3290\end{verbatim} 3291 3292Then assuming a Volume has been Purged, you can schedule 3293truncate operation at the end of your CatalogBackup job 3294like in this example: 3295 3296\begin{verbatim} 3297Job { 3298 Name = CatalogBackup 3299 ... 3300 RunScript { 3301 RunsWhen=After 3302 RunsOnClient=No 3303 Console = "purge volume action=all allpools storage=File" 3304 } 3305} 3306\end{verbatim} 3307 3308\label{PoolScratchPool} 3309\item [ScratchPool = \lt{}pool-resource-name\gt{}] 3310 \index[dir]{ScrachPool} 3311 \index[dir]{Directive!ScrachPool} 3312 This directive permits to specify a dedicate \textsl{Scratch} for the 3313 current pool. This pool will replace the special pool named \textsl{Scrach} 3314 for volume selection. For more information about \textsl{Scratch} see 3315 \ilink{Scratch Pool}{TheScratchPool} section of this manual. This is useful 3316 when using multiple storage sharing the same mediatype or when you want to 3317 dedicate volumes to a particular set of pool. 3318 3319\label{PoolRecyclePool} 3320\item [RecyclePool = \lt{}pool-resource-name\gt{}] 3321 \index[dir]{RecyclePool} 3322 \index[dir]{Directive!RecyclePool} 3323 This directive defines to which pool 3324 the Volume will be placed (moved) when it is recycled. Without 3325 this directive, a Volume will remain in the same pool when it is 3326 recycled. With this directive, it can be moved automatically to any 3327 existing pool during a recycle. This directive is probably most 3328 useful when defined in the Scratch pool, so that volumes will 3329 be recycled back into the Scratch pool. For more on the see the 3330 \ilink{Scratch Pool}{TheScratchPool} section of this manual. 3331 3332 Although this directive is called RecyclePool, the Volume in 3333 question is actually moved from its current pool to the one 3334 you specify on this directive when Bacula prunes the Volume and 3335 discovers that there are no records left in the catalog and hence 3336 marks it as {\bf Purged}. 3337 3338 3339\label{PoolRecycle} 3340\item [Recycle = \lt{}yes\vb{}no\gt{}] 3341 \index[dir]{Recycle} 3342 \index[dir]{Directive!Recycle} 3343 This directive specifies whether or not Purged Volumes may be recycled. 3344 If it is set to {\bf yes} (default) and Bacula needs a volume but finds 3345 none that are appendable, it will search for and recycle (reuse) Purged 3346 Volumes (i.e. volumes with all the Jobs and Files expired and thus 3347 deleted from the Catalog). If the Volume is recycled, all previous data 3348 written to that Volume will be overwritten. If Recycle is set to {\bf 3349 no}, the Volume will not be recycled, and hence, the data will remain 3350 valid. If you want to reuse (re-write) the Volume, and the recycle flag 3351 is no (0 in the catalog), you may manually set the recycle flag (update 3352 command) for a Volume to be reused. 3353 3354 Please note that the value defined by this directive in the 3355 bacula-dir.conf file is the default value used when a Volume is created. 3356 Once the volume is created, changing the value in the bacula-dir.conf 3357 file will not change what is stored for the Volume. To change the value 3358 for an existing Volume you must use the {\bf update} command in the 3359 Console. 3360 3361 When all Job and File records have been pruned or purged from the 3362 catalog for a particular Volume, if that Volume is marked as 3363 Full or Used, it will then be marked as Purged. Only 3364 Volumes marked as Purged will be considered to be converted to the 3365 Recycled state if the {\bf Recycle} directive is set to {\bf yes}. 3366 3367 3368\label{RecycleOldest} 3369\item [Recycle Oldest Volume = \lt{}yes\vb{}no\gt{}] 3370 \index[dir]{Recycle Oldest Volume} 3371 \index[dir]{Directive!Recycle Oldest Volume} 3372 This directive instructs the Director to search for the oldest used 3373 Volume in the Pool when another Volume is requested by the Storage 3374 daemon and none are available. The catalog is then {\bf pruned} 3375 respecting the retention periods of all Files and Jobs written to this 3376 Volume. If all Jobs are pruned (i.e. the volume is Purged), then the 3377 Volume is recycled and will be used as the next Volume to be written. 3378 This directive respects any Job, File, or Volume retention periods that 3379 you may have specified, and as such it is {\bf much} better to use this 3380 directive than the Purge Oldest Volume. 3381 3382 This directive can be useful if you have a fixed number of Volumes in the 3383 Pool and you want to cycle through them and you have specified the correct 3384 retention periods. 3385 3386 However, if you use this directive and have only one 3387 Volume in the Pool, you will immediately recycle your Volume if you fill 3388 it and Bacula needs another one. Thus your backup will be totally invalid. 3389 Please use this directive with care. The default is {\bf no}. 3390 3391\label{RecycleCurrent} 3392 3393\item [Recycle Current Volume = \lt{}yes\vb{}no\gt{}] 3394 \index[dir]{Recycle Current Volume} 3395 \index[dir]{Directive!Recycle Current Volume} 3396 If Bacula needs a new Volume, this directive instructs Bacula to Prune 3397 the volume respecting the Job and File retention periods. If all Jobs 3398 are pruned (i.e. the volume is Purged), then the Volume is recycled and 3399 will be used as the next Volume to be written. This directive respects 3400 any Job, File, or Volume retention periods that you may have specified, 3401 and thus it is {\bf much} better to use it rather than the Purge Oldest 3402 Volume directive. 3403 3404 This directive can be useful if you have: a fixed number of Volumes in 3405 the Pool, you want to cycle through them, and you have specified 3406 retention periods that prune Volumes before you have cycled through the 3407 Volume in the Pool. 3408 3409 However, if you use this directive and have only one Volume in the Pool, 3410 you will immediately recycle your Volume if you fill it and Bacula needs 3411 another one. Thus your backup will be totally invalid. Please use this 3412 directive with care. The default is {\bf no}. 3413 3414\label{PurgeOldest} 3415\item [Purge Oldest Volume = \lt{}yes\vb{}no\gt{}] 3416 \index[dir]{Purge Oldest Volume} 3417 \index[dir]{Directive!Purge Oldest Volume} 3418 This directive instructs the Director to search for the oldest used 3419 Volume in the Pool when another Volume is requested by the Storage 3420 daemon and none are available. The catalog is then {\bf purged} 3421 irrespective of retention periods of all Files and Jobs written to this 3422 Volume. The Volume is then recycled and will be used as the next Volume 3423 to be written. This directive overrides any Job, File, or Volume 3424 retention periods that you may have specified. 3425 3426 This directive can be useful if you have a fixed number of Volumes in 3427 the Pool and you want to cycle through them and reusing the oldest one 3428 when all Volumes are full, but you don't want to worry about setting 3429 proper retention periods. However, by using this option you risk losing 3430 valuable data. 3431 3432 Please be aware that {\bf Purge Oldest Volume} disregards all retention 3433 periods. If you have only a single Volume defined and you turn this 3434 variable on, that Volume will always be immediately overwritten when it 3435 fills! So at a minimum, ensure that you have a decent number of Volumes 3436 in your Pool before running any jobs. If you want retention periods to 3437 apply do not use this directive. To specify a retention period, use the 3438 {\bf Volume Retention} directive (see above). 3439 3440 We {\bf highly} recommend against using this directive, because it is 3441 sure that some day, Bacula will recycle a Volume that contains current 3442 data. The default is {\bf no}. 3443 3444\item [File Retention = \lt{}time-period-specification\gt{}] 3445 \index[dir]{File Retention} 3446 \index[dir]{Directive!File Retention} 3447 The File Retention directive defines the length of time that Bacula will 3448 keep File records in the Catalog database after the End time of the 3449 Job corresponding to the File records. 3450 3451 This directive takes precedence over Client directives of the same name. For 3452 example, you can decide to increase Retention times for Archive or OffSite 3453 Pool. 3454 3455 Note, this affects only records in the catalog database. It does not affect 3456 your archive backups. 3457 3458 For more information see Client documentation about 3459 \ilink{FileRetention}{FileRetention} 3460 3461\item [Job Retention = \lt{}time-period-specification\gt{}] 3462 \index[dir]{Job Retention} 3463 \index[dir]{Directive!Job Retention} 3464 3465 The Job Retention directive defines the length of time that Bacula will keep 3466 Job records in the Catalog database after the Job End time. As with the 3467 other retention periods, this affects only records in the catalog and not 3468 data in your archive backup. 3469 3470 This directive takes precedence over Client directives of the same name. 3471 For example, you can decide to increase Retention times for Archive or 3472 OffSite Pool. 3473 3474 For more information see Client side documentation 3475 \ilink{JobRetention}{JobRetention} 3476 3477\item [Cleaning Prefix = \lt{}string\gt{}] 3478 \index[dir]{Cleaning Prefix} 3479 \index[dir]{Directive!Cleaning Prefix} 3480 This directive defines a prefix string, which if it matches the 3481 beginning of a Volume name during labeling of a Volume, the Volume will 3482 be defined with the VolStatus set to {\bf Cleaning} and thus Bacula will 3483 never attempt to use this tape. This is primarily for use with 3484 autochangers that accept barcodes where the convention is that barcodes 3485 beginning with {\bf CLN} are treated as cleaning tapes. 3486 3487\label{Label} 3488\item [Label Format = \lt{}format\gt{}] 3489 \index[dir]{Label Format} 3490 \index[dir]{Directive!Label Format} 3491 This directive specifies the format of the labels contained in this 3492 pool. The format directive is used as a sort of template to create new 3493 Volume names during automatic Volume labeling. 3494 3495 The {\bf format} should be specified in double quotes, and consists of 3496 letters, numbers and the special characters hyphen ({\bf -}), underscore 3497 ({\bf \_}), colon ({\bf :}), and period ({\bf .}), which are the legal 3498 characters for a Volume name. The {\bf format} should be enclosed in 3499 double quotes ("). 3500 3501 In addition, the format may contain a number of variable expansion 3502 characters which will be expanded by a complex algorithm allowing you to 3503 create Volume names of many different formats. In all cases, the 3504 expansion process must resolve to the set of characters noted above that 3505 are legal Volume names. Generally, these variable expansion characters 3506 begin with a dollar sign ({\bf \$}) or a left bracket ({\bf [}). If you 3507 specify variable expansion characters, you should always enclose the 3508 format with double quote characters ({\bf "}). For more details on 3509 variable expansion, please see the \borgxrlink{Variable Expansion}{VarsChapter}{misc}{chapter} of the \miscman{}. 3510 3511 If no variable expansion characters are found in the string, the Volume 3512 name will be formed from the {\bf format} string appended with the 3513 a unique number that increases. If you do not remove volumes from the 3514 pool, this number should be the number of volumes plus one, but this 3515 is not guaranteed. The unique number will be edited as four 3516 digits with leading zeros. For example, with a {\bf Label Format = 3517 "File-"}, the first volumes will be named {\bf File-0001}, {\bf 3518 File-0002}, ... 3519 3520 With the exception of Job specific variables, you can test your {\bf 3521 LabelFormat} by using the \borgxrlink{var}{var}{console}{command} in the 3522 \consoleman{}. 3523 3524{\small 3525\begin{verbatim} 3526 Label Format="${Level}_${Type}_${Client}_${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}" 3527\end{verbatim} 3528} 3529 Once defined, the name of the volume cannot be changed. When the volume is 3530 recycled, the volume can be used by an other Job at an other time, and 3531 possibly from an other Pool. In the example above, the volume defined 3532 with such name is probably not supposed to be recycled or reused. 3533 3534 3535 In almost all cases, you should enclose the format specification (part 3536 after the equal sign) in double quotes. 3537\end{description} 3538 3539In order for a Pool to be used during a Backup Job, the Pool must have at 3540least one Volume associated with it. Volumes are created for a Pool using 3541the {\bf label} or the {\bf add} commands in the {\bf Bacula Console}, 3542program. In addition to adding Volumes to the Pool (i.e. putting the 3543Volume names in the Catalog database), the physical Volume must be labeled 3544with a valid Bacula software volume label before {\bf Bacula} will accept 3545the Volume. This will be automatically done if you use the {\bf label} 3546command. Bacula can automatically label Volumes if instructed to do so, 3547but this feature is not yet fully implemented. 3548 3549The following is an example of a valid Pool resource definition: 3550 3551\footnotesize 3552\begin{verbatim} 3553 3554Pool { 3555 Name = Default 3556 Pool Type = Backup 3557} 3558\end{verbatim} 3559\normalsize 3560 3561\subsection{The Scratch Pool} 3562\label{TheScratchPool} 3563\index[general]{Scratch Pool} 3564In general, you can give your Pools any name you wish, but there is one 3565important restriction: the Pool named {\bf Scratch}, if it exists behaves 3566like a scratch pool of Volumes in that when Bacula needs a new Volume for 3567writing and it cannot find one, it will look in the Scratch pool, and if 3568it finds an available Volume, it will move it out of the Scratch pool into 3569the Pool currently being used by the job. 3570 3571 3572\section{The Catalog Resource} 3573\label{CatalogResource} 3574\index[general]{Resource!Catalog} 3575\index[general]{Catalog Resource} 3576 3577The Catalog Resource defines what catalog to use for the current job. 3578Currently, Bacula can only handle a single database server (MySQL or 3579PostgreSQL) that is defined when configuring {\bf Bacula}. However, there 3580may be as many Catalogs (databases) defined as you wish. For example, you 3581may want each Client to have its own Catalog database, or you may want 3582backup jobs to use one database and verify or restore jobs to use another 3583database. 3584 3585Since both MySQL and PostgreSQL are networked 3586databases, they may reside either on the same machine as the Director 3587or on a different machine on the network. See below for more details. 3588 3589\begin{description} 3590 3591\item [Catalog] 3592 \index[dir]{Catalog} 3593 \index[dir]{Directive!Catalog} 3594 Start of the Catalog resource. At least one Catalog resource must be 3595defined. 3596 3597 3598\item [Name = \lt{}name\gt{}] 3599 \index[dir]{Name} 3600 \index[dir]{Directive!Name} 3601 The name of the Catalog. No necessary relation to the database server 3602 name. This name will be specified in the Client resource directive 3603 indicating that all catalog data for that Client is maintained in this 3604 Catalog. This directive is required. 3605 3606\item [password = \lt{}password\gt{}] 3607 \index[dir]{password} 3608 \index[dir]{Directive!password} 3609 This specifies the password to use when logging into the database. This 3610 directive is required. 3611 3612\item [DB Name = \lt{}name\gt{}] 3613 \index[dir]{DB Name} 3614 \index[dir]{Directive!DB Name} 3615 This specifies the name of the database. If you use multiple catalogs 3616 (databases), you specify which one here. If you are using an external 3617 database server rather than the internal one, you must specify a name 3618 that is known to the server (i.e. you explicitly created the Bacula 3619 tables using this name. This directive is required. 3620 3621\item [user = \lt{}user\gt{}] 3622 \index[dir]{user} 3623 \index[dir]{Directive!user} 3624 This specifies what user name to use to log into the database. This 3625 directive is required. 3626 3627\item [DB Socket = \lt{}socket-name\gt{}] 3628 \index[dir]{DB Socket} 3629 \index[dir]{Directive!DB Socket} 3630 This is the name of a socket to use on the local host to connect to the 3631 database. This directive is used only by MySQL. 3632 Normally, if neither {\bf DB Socket} or {\bf DB Address} are specified, MySQL 3633 will use the default socket. If the DB Socket is specified, the 3634 MySQL server must reside on the same machine as the Director. 3635 3636\item [DB Address = \lt{}address\gt{}] 3637 \index[dir]{DB Address} 3638 \index[dir]{Directive!DB Address} 3639 This is the host address of the database server. Normally, you would specify 3640 this instead of {\bf DB Socket} if the database server is on another machine. 3641 In that case, you will also specify {\bf DB Port}. This directive is used 3642 only by MySQL and PostgreSQL. 3643 This directive is optional. 3644 3645\item [DB Port = \lt{}port\gt{}] 3646 \index[dir]{DB Port} 3647 \index[dir]{Directive!DBPort} 3648 This defines the port to be used in conjunction with {\bf DB Address} to 3649 access the database if it is on another machine. This directive is used only 3650 by MySQL and PostgreSQL. 3651 directive is optional. 3652 3653%% \item [Multiple Connections = \lt{}yes\vb{}no\gt{}] 3654%% \index[dir]{Multiple Connections} 3655%% \index[dir]{Directive!Multiple Connections} 3656%% By default, this directive is set to no. In that case, each job that uses 3657the 3658%% same Catalog will use a single connection to the catalog. It will be shared, 3659%% and Bacula will allow only one Job at a time to communicate. If you set this 3660%% directive to yes, Bacula will permit multiple connections to the database, 3661%% and the database must be multi-thread capable. For and PostgreSQL, 3662%% this is no problem. For MySQL, you must be *very* careful to have the 3663%% multi-thread version of the client library loaded on your system. When this 3664%% directive is set yes, each Job will have a separate connection to the 3665%% database, and the database will control the interaction between the 3666different 3667%% Jobs. This can significantly speed up the database operations if you are 3668%% running multiple simultaneous jobs. In addition, for and PostgreSQL, 3669%% Bacula will automatically enable transactions. This can significantly speed 3670%% up insertion of attributes in the database either for a single Job or 3671%% multiple simultaneous Jobs. 3672 3673%% This directive has not been tested. Please test carefully before running it 3674%% in production and report back your results. 3675 3676\end{description} 3677 3678The following is an example of a valid Catalog resource definition: 3679 3680\footnotesize 3681\begin{verbatim} 3682Catalog 3683{ 3684 Name = MySQL 3685 dbname = bacula; 3686 user = bacula; 3687 password = "" # no password = no security 3688} 3689\end{verbatim} 3690\normalsize 3691 3692or for a Catalog on another machine: 3693 3694\footnotesize 3695\begin{verbatim} 3696Catalog 3697{ 3698 Name = MySQL 3699 dbname = bacula 3700 user = bacula 3701 password = "" 3702 DB Address = remote.acme.com 3703 DB Port = 1234 3704} 3705\end{verbatim} 3706\normalsize 3707 3708\section{The Messages Resource} 3709\label{MessagesResource2} 3710\index[general]{Resource!Messages} 3711\index[general]{Messages Resource} 3712 3713For the details of the Messages Resource, please see the 3714\ilink{Messages Resource Chapter}{MessagesChapter} of this 3715manual. 3716 3717\section{The Console Resource} 3718\label{ConsoleResource1} 3719\index[general]{Console Resource} 3720\index[general]{Resource!Console} 3721 3722As of Bacula version 1.33 and higher, there are three different kinds of 3723consoles, which the administrator or user can use to interact with the 3724Director. These three kinds of consoles comprise three different security 3725levels. 3726 3727\begin{itemize} 3728\item The first console type is an {\bf anonymous} or {\bf default} console, 3729 which has full privileges. There is no console resource necessary for 3730 this type since the password is specified in the Director's resource and 3731 consequently such consoles do not have a name as defined on a {\bf Name 3732 =} directive. This is the kind of console that was initially 3733 implemented in versions prior to 1.33 and remains valid. Typically you 3734 would use it only for administrators. 3735 3736\item The second type of console, and new to version 1.33 and higher is a 3737 "named" console defined within a Console resource in both the Director's 3738 configuration file and in the Console's configuration file. Both the 3739 names and the passwords in these two entries must match much as is the 3740 case for Client programs. 3741 3742 This second type of console begins with absolutely no privileges except 3743 those explicitly specified in the Director's Console resource. Thus you 3744 can have multiple Consoles with different names and passwords, sort of 3745 like multiple users, each with different privileges. As a default, 3746 these consoles can do absolutely nothing -- no commands whatsoever. You 3747 give them privileges or rather access to commands and resources by 3748 specifying access control lists in the Director's Console resource. The 3749 ACLs are specified by a directive followed by a list of access names. 3750 Examples of this are shown below. 3751 3752\item The third type of console is similar to the above mentioned one in that 3753 it requires a Console resource definition in both the Director and the 3754 Console. In addition, if the console name, provided on the {\bf Name =} 3755 directive, is the same as a Client name, that console is permitted to 3756 use the {\bf SetIP} command to change the Address directive in the 3757 Director's client resource to the IP address of the Console. This 3758 permits portables or other machines using DHCP (non-fixed IP addresses) 3759 to "notify" the Director of their current IP address. 3760\end{itemize} 3761 3762The Console resource is optional and need not be specified. The following 3763directives are permitted within the Director's configuration resource: 3764 3765\begin{description} 3766 3767\item [Name = \lt{}name\gt{}] 3768 \index[dir]{Name} 3769 \index[dir]{Directive!Name} 3770 The name of the console. This name must match the name specified in the 3771Console's configuration resource (much as is the case with Client 3772definitions). 3773 3774\item [Password = \lt{}password\gt{}] 3775 \index[dir]{Password} 3776 \index[dir]{Directive!Password} 3777 Specifies the password that must be supplied for a named Bacula Console 3778 to be authorized. The same password must appear in the {\bf Console} 3779 resource of the Console configuration file. For added security, the 3780 password is never actually passed across the network but rather a 3781 challenge response hash code created with the password. This directive 3782 is required. If you have either {\bf /dev/random} {\bf bc} on your 3783 machine, Bacula will generate a random password during the configuration 3784 process, otherwise it will be left blank. 3785 3786 The password is plain text. It is not generated through any special 3787 process. However, it is preferable for security reasons to choose 3788 random text. 3789 3790\item [JobACL = \lt{}name-list\gt{}] 3791 \index[dir]{JobACL} 3792 \index[dir]{Directive!JobACL} 3793 This directive is used to specify a list of Job resource names that can 3794 be accessed by the console. Without this directive, the console cannot 3795 access any of the Director's Job resources. Multiple Job resource names 3796 may be specified by separating them with commas, and/or by specifying 3797 multiple JobACL directives. For example, the directive may be specified 3798 as: 3799 3800\footnotesize 3801\begin{verbatim} 3802 JobACL = kernsave, "Backup client 1", "Backup client 2" 3803 JobACL = "RestoreFiles" 3804 3805\end{verbatim} 3806\normalsize 3807 3808With the above specification, the console can access the Director's resources 3809for the four jobs named on the JobACL directives, but for no others. 3810 3811\item [ClientACL = \lt{}name-list\gt{}] 3812 \index[dir]{ClientACL} 3813 \index[dir]{Directive!ClientACL} 3814 This directive is used to specify a list of Client resource names that can 3815be 3816accessed by the console. 3817 3818\item [StorageACL = \lt{}name-list\gt{}] 3819 \index[dir]{StorageACL} 3820 \index[dir]{Directive!StorageACL} 3821 This directive is used to specify a list of Storage resource names that can 3822be accessed by the console. 3823 3824\item [ScheduleACL = \lt{}name-list\gt{}] 3825 \index[dir]{ScheduleACL} 3826 \index[dir]{Directive!ScheduleACL} 3827 This directive is used to specify a list of Schedule resource names that can 3828 be accessed by the console. 3829 3830\item [PoolACL = \lt{}name-list\gt{}] 3831 \index[dir]{PoolACL} 3832 \index[dir]{Directive!PoolACL} 3833 This directive is used to specify a list of Pool resource names that can be 3834 accessed by the console. 3835 3836\item [FileSetACL = \lt{}name-list\gt{}] 3837 \index[dir]{FileSetACL} 3838 \index[dir]{Directive!FileSetACL} 3839 This directive is used to specify a list of FileSet resource names that 3840 can be accessed by the console. 3841 3842\item [CatalogACL = \lt{}name-list\gt{}] 3843 \index[dir]{CatalogACL} 3844 \index[dir]{Directive!CatalogACL} 3845 This directive is used to specify a list of Catalog resource names that 3846 can be accessed by the console. 3847 3848\item [CommandACL = \lt{}name-list\gt{}] 3849 \index[dir]{CommandACL} 3850 \index[dir]{Directive!CommandACL} 3851 This directive is used to specify a list of of console commands that can 3852 be executed by the console. 3853 3854\item [WhereACL = \lt{}string\gt{}] 3855 \index[dir]{WhereACL} 3856 \index[dir]{Directive!WhereACL} 3857 This directive permits you to specify where a restricted console 3858 can restore files. If this directive is not specified, only the 3859 default restore location is permitted (normally {\bf 3860 /tmp/bacula-restores}. If {\bf *all*} is specified any path the 3861 user enters will be accepted (not very secure), any other 3862 value specified (there may be multiple WhereACL directives) will 3863 restrict the user to use that path. For example, on a Unix system, 3864 if you specify "/", the file will be restored to the original 3865 location. This directive is untested. 3866 3867\end{description} 3868 3869Aside from Director resource names and console command names, the special 3870keyword {\bf *all*} can be specified in any of the above access control lists. 3871When this keyword is present, any resource or command name (which ever is 3872appropriate) will be accepted. For an example configuration file, please see 3873the 3874\ilink{Console Configuration}{ConsoleConfChapter} chapter of this 3875manual. 3876 3877\section{The Counter Resource} 3878\label{CounterResource} 3879\index[general]{Resource!Counter} 3880\index[general]{Counter Resource} 3881 3882The Counter Resource defines a counter variable that can be accessed by 3883variable expansion used for creating Volume labels with the {\bf LabelFormat} 3884directive. See the 3885\ilink{LabelFormat}{Label} directive in this chapter for more 3886details. 3887 3888\begin{description} 3889 3890\item [Counter] 3891 \index[dir]{Counter} 3892 \index[dir]{Directive!Counter} 3893 Start of the Counter resource. Counter directives are optional. 3894 3895\item [Name = \lt{}name\gt{}] 3896 \index[dir]{Name} 3897 \index[dir]{Directive!Name} 3898 The name of the Counter. This is the name you will use in the variable 3899expansion to reference the counter value. 3900 3901\item [Minimum = \lt{}integer\gt{}] 3902 \index[dir]{Minimum} 3903 \index[dir]{Directive!Minimum} 3904 This specifies the minimum value that the counter can have. It also becomes 3905the default. If not supplied, zero is assumed. 3906 3907\item [Maximum = \lt{}integer\gt{}] 3908 \index[dir]{Maximum} 3909 \index[dir]{Directive!Maximum} 3910 \index[dir]{Directive!Maximum} 3911 This is the maximum value value that the counter can have. If not specified 3912or set to zero, the counter can have a maximum value of 2,147,483,648 (2 to 3913the 31 power). When the counter is incremented past this value, it is reset 3914to the Minimum. 3915 3916\item [*WrapCounter = \lt{}counter-name\gt{}] 3917 \index[dir]{*WrapCounter} 3918 \index[dir]{Directive!*WrapCounter} 3919 If this value is specified, when the counter is incremented past the 3920maximum 3921and thus reset to the minimum, the counter specified on the {\bf WrapCounter} 3922is incremented. (This is not currently implemented). 3923 3924\item [Catalog = \lt{}catalog-name\gt{}] 3925 \index[dir]{Catalog} 3926 \index[dir]{Directive!Catalog} 3927 If this directive is specified, the counter and its values will be saved in 3928the specified catalog. If this directive is not present, the counter will be 3929redefined each time that Bacula is started. 3930\end{description} 3931 3932\section{Example Director Configuration File} 3933\label{SampleDirectorConfiguration} 3934\index[general]{File!Example Director Configuration} 3935\index[general]{Example Director Configuration File} 3936 3937An example Director configuration file might be the following: 3938 3939\footnotesize 3940\begin{verbatim} 3941# 3942# Default Bacula Director Configuration file 3943# 3944# The only thing that MUST be changed is to add one or more 3945# file or directory names in the Include directive of the 3946# FileSet resource. 3947# 3948# For Bacula release 1.15 (5 March 2002) -- redhat 3949# 3950# You might also want to change the default email address 3951# from root to your address. See the "mail" and "operator" 3952# directives in the Messages resource. 3953# 3954Director { # define myself 3955 Name = rufus-dir 3956 QueryFile = "/home/kern/bacula/bin/query.sql" 3957 WorkingDirectory = "/home/kern/bacula/bin/working" 3958 PidDirectory = "/home/kern/bacula/bin/working" 3959 Password = "XkSfzu/Cf/wX4L8Zh4G4/yhCbpLcz3YVdmVoQvU3EyF/" 3960} 3961# Define the backup Job 3962Job { 3963 Name = "NightlySave" 3964 Type = Backup 3965 Level = Incremental # default 3966 Client=rufus-fd 3967 FileSet="Full Set" 3968 Schedule = "WeeklyCycle" 3969 Storage = DLTDrive 3970 Messages = Standard 3971 Pool = Default 3972} 3973Job { 3974 Name = "Restore" 3975 Type = Restore 3976 Client=rufus-fd 3977 FileSet="Full Set" 3978 Where = /tmp/bacula-restores 3979 Storage = DLTDrive 3980 Messages = Standard 3981 Pool = Default 3982} 3983 3984# List of files to be backed up 3985FileSet { 3986 Name = "Full Set" 3987 Include { 3988 Options {signature=SHA1} 3989# 3990# Put your list of files here, one per line or include an 3991# external list with: 3992# 3993# @file-name 3994# 3995# Note: / backs up everything 3996 File = / 3997} 3998 Exclude {} 3999} 4000# When to do the backups 4001Schedule { 4002 Name = "WeeklyCycle" 4003 Run = level=Full sun at 2:05 4004 Run = level=Incremental mon-sat at 2:05 4005} 4006# Client (File Services) to backup 4007Client { 4008 Name = rufus-fd 4009 Address = rufus 4010 Catalog = MyCatalog 4011 Password = "MQk6lVinz4GG2hdIZk1dsKE/LxMZGo6znMHiD7t7vzF+" 4012 File Retention = 60d # sixty day file retention 4013 Job Retention = 1y # 1 year Job retention 4014 AutoPrune = yes # Auto apply retention periods 4015} 4016# Definition of DLT tape storage device 4017Storage { 4018 Name = DLTDrive 4019 Address = rufus 4020 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ" 4021 Device = "HP DLT 80" # same as Device in Storage daemon 4022 Media Type = DLT8000 # same as MediaType in Storage daemon 4023} 4024# Definition for a DLT autochanger device 4025Storage { 4026 Name = Autochanger 4027 Address = rufus 4028 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ" 4029 Device = "Autochanger" # same as Device in Storage daemon 4030 Media Type = DLT-8000 # Different from DLTDrive 4031 Autochanger = yes 4032} 4033# Definition of DDS tape storage device 4034Storage { 4035 Name = SDT-10000 4036 Address = rufus 4037 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ" 4038 Device = SDT-10000 # same as Device in Storage daemon 4039 Media Type = DDS-4 # same as MediaType in Storage daemon 4040} 4041# Definition of 8mm tape storage device 4042Storage { 4043 Name = "8mmDrive" 4044 Address = rufus 4045 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ" 4046 Device = "Exabyte 8mm" 4047 MediaType = "8mm" 4048} 4049# Definition of file storage device 4050Storage { 4051 Name = File 4052 Address = rufus 4053 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ" 4054 Device = FileStorage 4055 Media Type = File 4056} 4057# Generic catalog service 4058Catalog { 4059 Name = MyCatalog 4060 dbname = bacula; user = bacula; password = "" 4061} 4062# Reasonable message delivery -- send most everything to 4063# the email address and to the console 4064Messages { 4065 Name = Standard 4066 mail = root@localhost = all, !skipped, !terminate 4067 operator = root@localhost = mount 4068 console = all, !skipped, !saved 4069} 4070 4071# Default pool definition 4072Pool { 4073 Name = Default 4074 Pool Type = Backup 4075 AutoPrune = yes 4076 Recycle = yes 4077} 4078# 4079# Restricted console used by tray-monitor to get the status of the director 4080# 4081Console { 4082 Name = Monitor 4083 Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR" 4084 CommandACL = status, .status 4085} 4086\end{verbatim} 4087\normalsize 4088