4 \section*{Configurer le Director}
5 \label{_ChapterStart40}
6 \index[general]{Director!Configurer le }
7 \index[general]{Configurer le Director }
8 \addcontentsline{toc}{section}{Configurer le Director}
10 Parmi tous les fichiers de configuration requis pour ex\'ecuter {\bf Bacula},
11 celui du Director est le plus compliqu\'e, et c'est celui que vous modifierez
12 le plus souvent, en ajoutant des clients ou en modifiant les FileSets.
14 Pour une discussion g\'en\'erale concernant les fichiers et ressources ainsi
15 que les types de donn\'ees reconnus par {\bf Bacula}, veuillez consulter le
17 \ilink{Configuration}{_ChapterStart16} de ce manuel.
19 \subsection*{Les types de ressources du Director}
20 \index[general]{Les types de ressources du Director }
21 \index[general]{Director!Les types de ressources du }
22 \addcontentsline{toc}{subsection}{Les types de ressources du Director}
24 Les types de ressources du Director sont :
26 Job, JobDefs, Client, Storage, Catalog, Schedule, FileSet, Pool, Director, et
27 Messages. Nous les pr\'esentons ici dans l'ordre le plus logique (relativement
28 au fichier de configuration du Director) :
32 \ilink{Director}{DirectorResource4} -- Pour d\'efinir le nom du
33 Director et son mot de passe pour l'authentification du programme Console. Il
34 ne doit y avoir qu'une seule d\'efinition de ressource Director dans le
35 fichier de configuration. Si vouc avez soit {\bf /dev/random} soit {\bf bc}
36 sur votre machine, Bacula g\'en\`erera un mot de passe al\'eatoire lors du
37 processus de configuration, sinon, il sera laiss\'e blanc.
39 \ilink{Job}{JobResource} -- Pour d\'efinir les Jobs de types
40 sauvegarde et restauration, et pour lier les ressources Client, FileSet et
41 Schedules \`a utiliser conjointement pour chaque Job.
43 \ilink{JobDefs}{JobDefsResource} -- Ressource optionnelle pour
44 fournir des valeurs par d\'efaut pour les ressources Job.
46 \ilink{Schedule}{ScheduleResource} -- Pour d\'efinir le moment
47 o\`u un Job doit \^etre lanc\'e automatiquement par le {\it scheduler}
50 \ilink{FileSet}{FileSetResource} -- Pour d\'efinir l'ensemble des
51 fichiers \`a sauvegarder pour chaque client.
53 \ilink{Client}{ClientResource2} -- Pour d\'efinir quel Client est
56 \ilink{Storage}{StorageResource2} -- Pour d\'efinir sur quel
57 p\'eriph\'erique physique les volumes seront mont\'es.
59 \ilink{Pool}{PoolResource} -- Pour d\'efinir quel pool de volumes
60 peut \^etre utilis\'e pour un Job donn\'e
62 \ilink{Catalog}{CatalogResource} -- Pour d\'efinir la base de
63 donn\'ees o\`u conserver les listes des fichiers sauvegard\'es et des volumes
64 o\`u ils ont \'et\'e sauvegard\'es.
66 \ilink{Messages}{_ChapterStart15} -- Pour d\'efinir les
67 destinataires (ou les fichiers de logs) des messages d'erreur et
71 \section*{La ressource Director}
72 \label{DirectorResource4}
73 \index[general]{Director!La ressource }
74 \index[general]{La ressource Director }
75 \addcontentsline{toc}{section}{La ressource Director}
77 La ressource Director d\'efinit les attributs du Director ex\'ecut\'e sur le
78 r\'eseau. Dans l'impl\'ementation actuelle, il n'y a qu'une ressource
79 Director, mais la r\'ealisation finale contiendra plusieurs Directors pour
80 maintenir la redondance de la base des indexes et m\'edia.
85 \index[dir]{Director }
86 D\'ebut de la ressource Director. Une ressource Director et une seule doit
89 \item [Name = \lt{}name\gt{}]
91 Le nom du Director utilis\'e par l'administrateur syst\`eme. Cette directive
94 \item [Description = \lt{}text\gt{}]
95 \index[dir]{Description }
96 Le champ texte contient une description du Director qui sera affich\'ee dans
97 l'interface graphique. Cette directive est optionnelle.
99 \item [Password = \lt{}UA-password\gt{}]
100 \index[dir]{Password }
101 Sp\'ecifie le mot de passe qui doit \^etre fourni par la Console Bacula par
102 d\'efaut pour \^etre autoris\'ee. Le m\^eme mot de passe doit appara{\^\i}tre
103 dans la ressource {\bf Director} du fichier de configuration de la console.
104 Pour plus de s\'ecurit\'e, le mot de passe ne transite jamais sur le r\'eseau,
105 l'authentification se fait via un \'echange de type {\it challenge-response}
106 d'un {\it hash code} cr\'e\'e avec le mot de passe. Cette directive est
107 requise. Si vous disposez de {\bf /dev/random} ou {\bf bc} sur votre machine,
108 Bacula g\'en\`erera un mot de passe al\'eatoire lors du processus
109 d'installation, sinon il sera laiss\'e blanc et vous devrez en d\'efinir un
112 \item [Messages = \lt{}Messages-resource-name\gt{}]
113 \index[console]{Messages }
114 The messages resource specifies where to deliver Director messages that are
115 not associated with a specific Job. Most messages are specific to a job and
116 will be directed to the Messages resource specified by the job. However,
117 there are a few messages that can occur when no job is running. This
118 directive is required.
120 \item [Working Directory = \lt{}Directory\gt{}]
121 \index[console]{Working Directory }
122 This directive is mandatory and specifies a directory in which the Director
123 may put its status files. This directory should be used only by Bacula but
124 may be shared by other Bacula daemons. Standard shell expansion of the {\bf
125 Directory} is done when the configuration file is read so that values such
126 as {\bf \$HOME} will be properly expanded. This directive is required.
128 \item [Pid Directory = \lt{}Directory\gt{}]
129 \index[fd]{Pid Directory }
130 This directive is mandatory and specifies a directory in which the Director
131 may put its process Id file files. The process Id file is used to shutdown
132 Bacula and to prevent multiple copies of Bacula from running simultaneously.
133 Standard shell expansion of the {\bf Directory} is done when the
134 configuration file is read so that values such as {\bf \$HOME} will be
137 Typically on Linux systems, you will set this to: {\bf /var/run}. If you are
138 not installing Bacula in the system directories, you can use the {\bf Working
139 Directory} as defined above. This directive is required.
141 \item [QueryFile = \lt{}Path\gt{}]
142 \index[dir]{QueryFile }
143 This directive is mandatory and specifies a directory and file in which the
144 Director can find the canned SQL statements for the {\bf Query} command of
145 the Console. Standard shell expansion of the {\bf Path} is done when the
146 configuration file is read so that values such as {\bf \$HOME} will be
147 properly expanded. This directive is required.
148 \label{DirMaxConJobs}
150 \item [Maximum Concurrent Jobs = \lt{}number\gt{}]
151 \index[fd]{Maximum Concurrent Jobs }
152 where \lt{}number\gt{} is the maximum number of total Director Jobs that
153 should run concurrently. The default is set to 1, but you may set it to a
156 Please note that the Volume format becomes much more complicated with
157 multiple simultaneous jobs, consequently, restores can take much longer if
158 Bacula must sort through interleaved volume blocks from multiple simultaneous
159 jobs. This can be avoided by having each simultaneously running job write to
160 a different volume or by using data spooling, which will first spool the data
161 to disk simultaneously, then write each spool file to the volume in
164 There may also still be some cases where directives such as {\bf Maximum
165 Volume Jobs} are not properly synchronized with multiple simultaneous jobs
166 (subtle timing issues can arise), so careful testing is recommended.
168 At the current time, there is no configuration parameter set or limit the
169 number console connections. A maximum of five simultaneous console
170 connections are permitted.
172 For more details on getting concurrent jobs to run, please see
173 \ilink{Running Concurrent Jobs}{ConcurrentJobs} in the Tips chapter
176 \item [FD Connect Timeout = \lt{}time\gt{}]
177 \index[console]{FD Connect Timeout }
178 where {\bf time} is the time that the Director should continue attempting to
179 contact the File daemon to start a job, and after which the Director will
180 cancel the job. The default is 30 minutes.
182 \item [SD Connect Timeout = \lt{}time\gt{}]
183 \index[console]{SD Connect Timeout }
184 where {\bf time} is the time that the Director should continue attempting to
185 contact the Storage daemon to start a job, and after which the Director will
186 cancel the job. The default is 30 minutes.
188 \item [DirAddresses = \lt{}IP-address-specification\gt{}]
189 \index[console]{DirAddresses }
190 Specify the ports and addresses on which the Director daemon will listen for
191 Bacula Console connections. Probably the simplest way to explain is to show
196 DirAddresses = { ip = {
197 addr = 1.2.3.4; port = 1205; }
199 addr = 1.2.3.4; port = http; }
212 addr = 201:220:222::2
215 addr = bluedot.thun.net
221 where ip, ip4, ip6, addr, and port are all keywords. Note, that the address
222 can be specified as either a dotted quadruple, or IPv6 colon notation, or as
223 a symbolic name (only in the ip specification). Also, port can be specified
224 as a number or as the mnemonic value from the /etc/services file. If a port
225 is not specified, the default will be used. If an ip section is specified,
226 the resolution can be made either by IPv4 or IPv6. If ip4 is specified, then
227 only IPv4 resolutions will be permitted, and likewise with ip6.
229 \item [DIRport = \lt{}port-number\gt{}]
230 \index[console]{DIRport }
231 Specify the port (a positive integer) on which the Director daemon will
232 listen for Bacula Console connections. This same port number must be
233 specified in the Director resource of the Console configuration file. The
234 default is 9101, so normally this directive need not be specified. This
235 directive is not needed if you specify DirAddresses.
237 \item [DirAddress = \lt{}IP-Address\gt{}]
238 \index[console]{DirAddress }
239 This directive is optional, but if it is specified, it will cause the
240 Director server (for the Console program) to bind to the specified {\bf
241 IP-Address}, which is either a domain name or an IP address specified as a
242 dotted quadruple in string or quoted string format. If this directive is not
243 specified, the Director will bind to any available address (the default).
244 Note, unlike the DirAddresses specification noted above, this directive only
245 permits a single address to be specified. This directive is not needed if you
246 specify a DirAddresses (not plural).
249 The following is an example of a valid Director resource definition:
255 WorkingDirectory = "$HOME/bacula/bin/working"
256 Password = UA_password
257 PidDirectory = "$HOME/bacula/bin/working"
258 QueryFile = "$HOME/bacula/bin/query.sql"
264 \section*{The Job Resource}
266 \index[general]{Resource!Job }
267 \index[general]{Job Resource }
268 \addcontentsline{toc}{section}{Job Resource}
270 The Job resource defines a Job (Backup, Restore, ...) that Bacula must
271 perform. Each Job resource definition contains the names of the Clients and
272 their FileSets to backup or restore, the Schedule for the Job, where the data
273 are to be stored, and what media Pool can be used. In effect, each Job
274 resource must specify What, Where, How, and When or FileSet, Storage,
275 Backup/Restore/Level, and Schedule respectively.
277 Only a single type ({\bf Backup}, {\bf Restore}, ...) can be specified for any
278 job. If you want to backup multiple FileSets on the same Client or multiple
279 Clients, you must define a Job for each one.
284 \index[console]{Job }
285 Start of the Job resource. At least one Job resource is required.
287 \item [Name = \lt{}name\gt{}]
288 \index[console]{Name }
289 The Job name. This name can be specified on the {\bf Run} command in the
290 console program to start a job. If the name contains spaces, it must be
291 specified between quotes. It is generally a good idea to give your job the
292 same name as the Client that it will backup. This permits easy identification
295 When the job actually runs, the unique Job Name will consist of the name you
296 specify here followed by the date and time the job was scheduled for
297 execution. This directive is required.
299 \item [Type = \lt{}job-type\gt{}]
300 \index[console]{Type }
301 The {\bf Type} directive specifies the Job type, which may be one of the
302 following: {\bf Backup}, {\bf Restore}, {\bf Verify}, or {\bf Admin}. This
303 directive is required. Within a particular Job Type, there are also Levels
304 as discussed in the next item.
309 \index[console]{Backup }
310 Run a backup Job. Normally you will have at least one Backup job for each
311 client you want to save. Normally, unless you turn off cataloging, most all
312 the important statistics and data concerning files backed up will be placed
316 \index[console]{Restore }
317 Run a restore Job. Normally, you will specify only one Restore job which acts
318 as a sort of prototype that you will modify using the console program in
319 order to perform restores. Although certain basic information from a Restore
320 job is saved in the catalog, it is very minimal compared to the information
321 stored for a Backup job -- for example, no File database entries are
322 generated since no Files are saved.
325 \index[console]{Verify }
326 Run a verify Job. In general, {\bf verify} jobs permit you to compare the
327 contents of the catalog to the file system, or to what was backed up. In
328 addition, to verifying that a tape that was written can be read, you can
329 also use {\bf verify} as a sort of tripwire intrusion detection.
333 Run a admin Job. An {\bf Admin} job can be used to periodically run catalog
334 pruning, if you do not want to do it at the end of each {\bf Backup} Job.
335 Although an Admin job is recorded in the catalog, very little data is saved.
340 \item {\bf Level = \lt{}job-level\gt{}}
342 The Level directive specifies the default Job level to be run. Each different
343 Job Type (Backup, Restore, ...) has a different set of Levels that can be
344 specified. The Level is normally overridden by a different value that is
345 specified in the {\bf Schedule} resource. This directive is not required, but
346 must be specified either by a {\bf Level} directive or as a override
347 specified in the {\bf Schedule} resource.
349 For a {\bf Backup} Job, the Level may be one of the following:
355 is all files in the FileSet whether or not they have changed.
358 \index[fd]{Incremental }
359 is all files that have changed since the last successful backup of the
360 specified FileSet. If the Director cannot find a previous Full backup then
361 the job will be upgraded into a Full backup. When the Director looks for a
362 ``suitable'' backup record in the catalog database, it looks for a previous
366 \item The same Job name.
367 \item The same Client name.
368 \item The same FileSet (any change to the definition of the FileSet such as
369 adding or deleting a file in the Include or Exclude sections constitutes a
371 \item The Job was a Full, Differential, or Incremental backup.
372 \item The Job terminated normally (i.e. did not fail or was not canceled).
375 If all the above conditions do not hold, the Director will upgrade the
376 Incremental to a Full save. Otherwise, the Incremental backup will be
377 performed as requested.
379 The File daemon (Client) decides which files to backup for an Incremental
380 backup by comparing start time of the prior Job (Full, Differential, or
381 Incremental) against the time each file was last ``modified'' (st\_mtime) and
382 the time its attributes were last ``changed''(st\_ctime). If the file was
383 modified or its attributes changed on or after this start time, it will then
386 Please note that some virus scanning software may change st\_ctime while
387 doing the scan. For exaple, if the the virus scanning program attempts to
388 reset the access time (st\_atime), which Bacula does not use, it will cause
389 st\_ctime to change and hence Bacula will backup the file during an
390 Incremental or Differential backup. In the case of Sophos virus scanning, you
391 can prevent it from resetting the access time (st\_atime) and hence changing
392 st\_ctime by using the {\bf \verb{--{no-reset-atime} option. For other software,
393 please see their manual.
395 When Bacula does an Incremental backup, all modified files that are still on
396 the system are backed up. However, any file that has been deleted since the
397 last Full backup remains in the Bacula catalog, which means that if between
398 a Full save and the time you do a restore, some files are deleted, those
399 deleted files will also be restored. The deleted files will no longer appear
400 in the catalog after doing another Full save. However, to remove deleted
401 files from the catalog during a Incremental backup is quite a time consuming
402 process and not currently implemented in Bacula.
405 \index[fd]{Differential }
406 is all files that have changed since the last successful Full backup of the
407 specified FileSet. If the Director cannot find a previous Full backup or a
408 suitable Full backup, then the Differential job will be upgraded into a Full
409 backup. When the Director looks for a ``suitable'' Full backup record in the
410 catalog database, it looks for a previous Job with:
413 \item The same Job name.
414 \item The same Client name.
415 \item The same FileSet (any change to the definition of the FileSet such as
416 adding or deleting a file in the Include or Exclude sections constitutes a
418 \item The Job was a FULL backup.
419 \item The Job terminated normally (i.e. did not fail or was not canceled).
422 If all the above conditions do not hold, the Director will upgrade the
423 Differential to a Full save. Otherwise, the Differential backup will be
424 performed as requested.
426 The File daemon (Client) decides which files to backup for a differential
427 backup by comparing the start time of the prior Full backup Job against the
428 time each file was last ``modified'' (st\_mtime) and the time its attributes
429 were last ``changed''(st\_ctime). If the file was modified or its attributs
430 were changed on or after this start time, it will then be backed up. The
431 start time used is displayed after the {\bf Since} on the Job report. In rare
432 cases, using the start time of the prior backup may cause some files to be
433 backed up twice, but it ensures that no change is missed. As with the
434 Incremental option, you shouldensure that the clocks on your server and
435 client are synchronized or as close as possible to avoid the possibility of a
436 file being skipped. Note, on versions 1.33 or greater Bacula automatically
437 makes the necessary adjstments to the time between the server and the client
438 so that the times Bacula uses are synchronized.
440 When Bacula does an Differential backup, all modified files that are still on
441 the system are backed up. However, any file that has been deleted since the
442 last Full backup remains in the Bacula catalog, which means that if between
443 a Full save and the time you do a restore, some files are deleted, those
444 deleted files will also be restored. The deleted files will no longer appear
445 in the catalog after doing another Full save. However, to remove deleted
446 files from the catalog during a Differential backup is quite a time consuming
447 process and not currently implemented in Bacula.
450 For a {\bf Restore} Job, no level need be specified.
452 For a {\bf Verify} Job, the Level may be one of the following:
457 \index[fd]{InitCatalog }
458 does a scan of the specified {\bf FileSet} and stores the file attributes in
459 the Catalog database. Since no file data is saved, you might ask why you
460 would want to do this. It turns out to be a very simple and easy way to have
461 a {\bf Tripwire} like feature using {\bf Bacula}. In other words, it allows
462 you to save the state of a set of files defined by the {\bf FileSet} and
463 later check to see if those files have been modified or deleted and if any
464 new files have been added. This can be used to detect system intrusion.
465 Typically you would specify a {\bf FileSet} that contains the set of system
466 files that should not change (e.g. /sbin, /boot, /lib, /bin, ...). Normally,
467 you run the {\bf InitCatalog} level verify one time when your system is first
468 setup, and then once again after each modification (upgrade) to your system.
469 Thereafter, when your want to check the state of your system files, you use
470 a {\bf Verify} {\bf level = Catalog}. This compares the results of your {\bf
471 InitCatalog} with the current state of the files.
475 Compares the current state of the files against the state previously saved
476 during an {\bf InitCatalog}. Any discrepancies are reported. The items
477 reported are determined by the {\bf verify} options specified on the {\bf
478 Include} directive in the specified {\bf FileSet} (see the {\bf FileSet}
479 resource below for more details). Typically this command will be run once a
480 day (or night) to check for any changes to your system files.
482 Please note! If you run two Verify Catalog jobs on the same client at the
483 same time, the results will certainly be incorrect. This is because Verify
484 Catalog modifies the Catalog database while running in order to track new
487 \item [VolumeToCatalog]
488 \index[fd]{VolumeToCatalog }
489 This level causes Bacula to read the file attribute data written to the
490 Volume from the last Job. The file attribute data are compared to the values
491 saved in the Catalog database and any differences are reported. This is
492 similar to the {\bf Catalog} level except that instead of comparing the disk
493 file attributes to the catalog database, the attribute data written to the
494 Volume is read and compared to the catalog database. Although the attribute
495 data including the signatures (MD5 or SHA1) are compared the actual file data
496 is not compared (it is not in the catalog).
498 Please note! If you run two Verify VolumeToCatalog jobs on the same client at
499 the same time, the results will certainly be incorrect. This is because the
500 Verify VolumeToCatalog modifies the Catalog database while running.
502 \item [DiskToCatalog]
503 \index[fd]{DiskToCatalog }
504 This level causes Bacula to read the files as they currently are on disk, and
505 to compare the current file attributes with the attributes saved in the
506 catalog from the last backup for the job specified on the {\bf VerifyJob}
507 directive. This level differs from the {\bf Catalog} level described above by
508 the fact that it compare not against a previous Verify job but against a
509 previous backup. When you run this level, you must supply the verify options
510 on your Include statements. Those options determine what attribute fields are
513 This command can be very useful if you have disk problems because it will
514 compare the current state of your disk against the last successful backup,
515 which may be several jobs.
517 Note, the current implementation (1.32c) does not identify files that have
521 \item {\bf Verify Job = \lt{}Job-Resource-Name\gt{}}
522 \index[fd]{Verify Job }
523 If you run a verify job without this directive, the last job run will be
524 compared with the catalog, which means that you must immediately follow a
525 backup by a verify command. If you specify a {\bf Verify Job} Bacula will
526 find the last job with that name that ran. This permits you to run all your
527 backups, then run Verify jobs on those that you wish to be verified (most
528 often a {\bf VolumeToCatalog}) so that the tape just written is re-read.
530 \item {\bf JobDefs = \lt{}JobDefs-Resource-Name\gt{}}
532 If a JobDefs-Resource-Name is specified, all the values contained in the
533 named JobDefs resource will be used as the defaults for the current Job. Any
534 value that you explicitly define in the current Job resource, will override
535 any defaults specified in the JobDefs resource. The use of this directive
536 permits writing much more compact Job resources where the bulk of the
537 directives are defined in one or more JobDefs. This is particularly useful if
538 you have many similar Jobs but with minor variations such as different
539 Clients. A simple example of the use of JobDefs is provided in the default
540 bacula-dir.conf file.
542 \item {\bf Bootstrap = \lt{}bootstrap-file\gt{}}
543 \index[dir]{Bootstrap }
544 The Bootstrap directive specifies a bootstrap file that, if provided, will
545 be used during {\bf Restore} Jobs and is ignored in other Job types. The {\bf
546 bootstrap} file contains the list of tapes to be used in a restore Job as
547 well as which files are to be restored. Specification of this directive is
548 optional, and if specified, it is used only for a restore job. In addition,
549 when running a Restore job from the console, this value can be changed.
551 If you use the {\bf Restore} command in the Console program, to start a
552 restore job, the {\bf bootstrap} file will be created automatically from the
553 files you select to be restored.
555 For additional details of the {\bf bootstrap} file, please see
556 \ilink{Restoring Files with the Bootstrap File}{_ChapterStart43}
557 chapter of this manual.
560 \label{writebootstrap}
561 Write Bootstrap = \lt{}bootstrap-file-specification\gt{}}
563 The {\bf writebootstrap} directive specifies a file name where Bacula will
564 write a {\bf bootstrap} file for each Backup job run. Thus this directive
565 applies only to Backup Jobs. If the Backup job is a Full save, Bacula will
566 erase any current contents of the specified file before writing the bootstrap
567 records. If the Job is an Incremental save, Bacula will append the current
568 bootstrap record to the end of the file.
570 Using this feature, permits you to constantly have a bootstrap file that can
571 recover the current state of your system. Normally, the file specified should
572 be a mounted drive on another machine, so that if your hard disk is lost,
573 you will immediately have a bootstrap record available. Alternatively, you
574 should copy the bootstrap file to another machine after it is updated.
576 If the {\bf bootstrap-file-specification} begins with a vertical bar (|),
577 Bacula will use the specification as the name of a program to which it will
578 pipe the bootstrap record. It could for example be a shell script that emails
579 you the bootstrap record.
581 For more details on using this file, please see the chapter entitled
582 \ilink{The Bootstrap File}{_ChapterStart43} of this manual.
584 \item {\bf Client = \lt{}client-resource-name\gt{}}
586 The Client directive specifies the Client (File daemon) that will be used in
587 the current Job. Only a single Client may be specified in any one Job. The
588 Client runs on the machine to be backed up, and sends the requested files to
589 the Storage daemon for backup, or receives them when restoring. For
590 additional details, see the
591 \ilink{Client Resource section}{ClientResource2} of this chapter.
592 This directive is required.
594 \item {\bf FileSet = \lt{}FileSet-resource-name\gt{}}
596 The FileSet directive specifies the FileSet that will be used in the current
597 Job. The FileSet specifies which directories (or files) are to be backed up,
598 and what options to use (e.g. compression, ...). Only a single FileSet
599 resource may be specified in any one Job. For additional details, see the
600 \ilink{FileSet Resource section}{FileSetResource} of this
601 chapter. This directive is required.
603 \item {\bf Messages = \lt{}messages-resource-name\gt{}}
604 \index[dir]{Messages }
605 The Messages directive defines what Messages resource should be used for this
606 job, and thus how and where the various messages are to be delivered. For
607 example, you can direct some messages to a log file, and others can be sent
608 by email. For additional details, see the
609 \ilink{Messages Resource}{_ChapterStart15} Chapter of this
610 manual. This directive is required.
612 \item {\bf Pool = \lt{}pool-resource-name\gt{}}
614 The Pool directive defines the pool of Volumes where your data can be backed
615 up. Many Bacula installations will use only the {\bf Default} pool. However,
616 if you want to specify a different set of Volumes for different Clients or
617 different Jobs, you will probably want to use Pools. For additional details,
619 \ilink{Pool Resource section}{PoolResource} of this chapter. This
620 resource is required.
622 \item {\bf Full Backup Pool = \lt{}pool-resource-name\gt{} }
623 \index[dir]{Full Backup Pool }
624 The {\it Full Backup Pool} specifies a Pool to be used for Full backups. It
625 will override any Pool specification during a Full backup. This resource is
628 \item {\bf Differential Backup Pool = \lt{}pool-resource-name\gt{} }
629 \index[dir]{Differential Backup Pool }
630 The {\it Differential Backup Pool} specifies a Pool to be used for
631 Differential backups. It will override any Pool specification during a
632 Differentia backup. This resource is optional.
634 \item {\bf Incremental Backup Pool = \lt{}pool-resource-name\gt{} }
635 \index[dir]{Incremental Backup Pool }
636 The {\it Incremental Backup Pool} specifies a Pool to be used for Incremental
637 backups. It will override any Pool specification during a Incremental backup.
638 This resource is optional.
640 \item {\bf Schedule = \lt{}schedule-name\gt{}}
641 \index[dir]{Schedule }
642 The Schedule directive defines what schedule is to be used for the Job. The
643 schedule determines when the Job will be automatically started and what Job
644 level (i.e. Full, Incremental, ...) is to be run. This directive is optional,
645 and if left out, the Job can only be started manually. For additional
647 \ilink{Schedule Resource Chapter}{ScheduleResource} of this
648 manual. If a Schedule resource is specified, the job will be run according to
649 the schedule specified. If no Schedule resource is specified for the Job,
650 the job must be manually started using the Console program. Although you may
651 specify only a single Schedule resource for any one job, the Schedule
652 resource may contain multiple {\bf Run} directives, which allow you to run
653 the Job at many different times, and each {\bf run} directive permits
654 overriding the default Job Level Pool, Storage, and Messages resources. This
655 gives considerable flexibility in what can be done with a single Job.
657 \item {\bf Storage = \lt{}storage-resource-name\gt{}}
658 \index[dir]{Storage }
659 The Storage directive defines the name of the storage services where you want
660 to backup the FileSet data. For additional details, see the
661 \ilink{Storage Resource Chapter}{StorageResource2} of this manual.
662 This directive is required.
664 \item {\bf Max Start Delay = \lt{}time\gt{}}
665 \index[sd]{Max Start Delay }
666 The time specifies maximum delay between the scheduled time and the actual
667 start time for the Job. For example, a job can be scheduled to run at
668 1:00am, but because other jobs are running, it may wait to run. If the delay
669 is set to 3600 (one hour) and the job has not begun to run by 2:00am, the job
670 will be canceled. This can be useful, for example, to prevent jobs from
671 running during day time hours. The default is 0 which indicates no limit.
673 \item {\bf Max Run Time = \lt{}time\gt{}}
674 \index[sd]{Max Run Time }
675 The time specifies maximum allowed time that a job may run, counted from the
676 when the job starts ({\bf not} necessarily the same as when the job was
677 scheduled). This directive is implemented only in version 1.33 and later.
679 \item {\bf Max Wait Time = \lt{}time\gt{}}
680 \index[sd]{Max Wait Time }
681 The time specifies maximum allowed time that a job may block waiting for a
682 resource (such as waiting for a tape to be mounted, or waiting for the
683 storage or file daemons to perform their duties), counted from the when the
684 job starts ({\bf not} necessarily the same as when the job was scheduled).
685 This directive is implemented only in version 1.33 and later. Note, the
686 implementation is not yet complete, so this directive does not yet work
689 \item {\bf Prune Jobs = \lt{}yes|no\gt{}}
690 \index[fd]{Prune Jobs }
691 Normally, pruning of Jobs from the Catalog is specified on a Client by Client
692 basis in the Client resource with the {\bf AutoPrune} directive. If this
693 directive is specified (not normally) and the value is {\bf yes}, it will
694 override the value specified in the Client resource. The default is {\bf no}.
697 \item {\bf Prune Files = \lt{}yes|no\gt{}}
698 \index[fd]{Prune Files }
699 Normally, pruning of Files from the Catalog is specified on a Client by
700 Client basis in the Client resource with the {\bf AutoPrune} directive. If
701 this directive is specified (not normally) and the value is {\bf yes}, it
702 will override the value specified in the Client resource. The default is {\bf
705 \item {\bf Prune Volumes = \lt{}yes|no\gt{}}
706 \index[fd]{Prune Volumes }
707 Normally, pruning of Volumes from the Catalog is specified on a Client by
708 Client basis in the Client resource with the {\bf AutoPrune} directive. If
709 this directive is specified (not normally) and the value is {\bf yes}, it
710 will override the value specified in the Client resource. The default is {\bf
713 \item {\bf Run Before Job = \lt{}command\gt{}}
714 \index[fd]{Run Before Job }
715 The specified {\bf command} is run as an external program prior to running
716 the current Job. Any output sent by the job to standard output will be
717 included in the Bacula job report. The command string must be a valid program
718 name or name of a shell script. This directive is not required, but if it is
719 defined, and if the exit code of the program run is non-zero, the current
720 Bacula job will be canceled. In addition, the command string is parsed then
721 feed to the execvp() function, which means that the path will be searched to
722 execute your specified command, but there is no shell interpretation, as a
723 consequence, if you complicated commands or want any shell features such as
724 redirection or piping, you must call a shell script and do it inside that
727 Before submitting the specified command to the operating system, Bacula
728 performs character substitution of the following characters:
746 As of version 1.30, Bacula checks the exit status of the RunBeforeJob
747 program. If it is non-zero, the job will be error terminated. Lutz Kittler
748 has pointed out that this can be a simple way to modify your schedules during
749 a holiday. For example, suppose that you normally do Full backups on Fridays,
750 but Thursday and Friday are holidays. To avoid having to change tapes between
751 Thursday and Friday when no one is in the office, you can create a
752 RunBeforeJob that returns a non-zero status on Thursday and zero on all other
753 days. That way, the Thursday job will not run, and on Friday the tape you
754 insert on Wednesday before leaving will be used.
756 \item {\bf Run After Job = \lt{}command\gt{}}
757 \index[fd]{Run After Job }
758 The specified {\bf command} is run as an external program after the current
759 job terminates. This directive is not required. The command string must be a
760 valid program name or name of a shell script. If the exit code of the program
761 run is non-zero, the current Bacula job will terminate in error. Before
762 submitting the specified command to the operating system, Bacula performs
763 character substitution as described above for the {\bf Run Before Job}
766 An example of the use of this command is given in the
767 \ilink{Tips Chapter}{JobNotification} of this manual. As of version
768 1.30, Bacula checks the exit status of the RunAfter program. If it is
769 non-zero, the job will be terminated in error.
771 \item {\bf Client Run Before Job = \lt{}command\gt{}}
772 \index[fd]{Client Run Before Job }
773 This command is the same as {\bf Run Before Job} except that it is run on
774 the client machine. The same restrictions apply to Unix systems as noted
775 above for the {\bf Run Before Job}. In addition, for a Windows client on
776 version 1.33 and above, please take careful note that you must ensure a
777 correct path to your script, and the script or program can be a .com, .exe or
778 a .bat file. However, if you specify a path, you must also specify the full
779 extension. Unix like commands will not work unless you have installed and
780 properly configured Cygwin in addition to and separately from Bacula.
782 {\bf Special Windows Considerations}
783 The command can be anything that cmd.exe or command.com will recognize as a
784 executable file. Specifiying the executable's extention is optional, unless
785 there is an ambiguity. (i.e. ls.bat, ls.exe)
787 The System \%Path\% will be searched for the command. (under the envrionment
788 variable dialog you have have both System Environment and User Environment,
789 we believe that only the System environment will be available to bacual-fd,
790 if it is running as a service.)
792 System environment varaible can be called out using the \%var\% syntax and
793 used as either part of the command name or arguments.
795 When specifiying a full path to an executable if the path or executable name
796 contains whitespace or special characters they will need to be quoted.
797 Arguments containing whitespace or special characters will also have to be
802 ClientRunBeforeJob = "\"C:/Program Files/Software
803 Vendor/Executable\" /arg1 /arg2 \"foo bar\""
807 The special characters \&()[]\{\}\^{}=;!'+,`\~{} will need to be quoted if
808 part of a filename or argument.
810 If someone is logged in a blank ``command'' window running the commands will
811 be present during the execution of the command.
813 Some Suggestions from Phil Stracchino for running on Win32 machines with the
814 native Win32 File daemon:
817 \item You might want the ClientRunBeforeJob directive to specify a .bat file
818 which runs the actual client-side commands, rather than trying to run (for
819 example) regedit /e directly.
820 \item The batch file should explicitly 'exit 0' on successful completion.
821 \item The path to the batch file should be specified in Unix form:
823 ClientRunBeforeJob = ``c:/bacula/bin/systemstate.bat''
825 rather than DOS/Windows form:
828 ``c:\textbackslash{}bacula\textbackslash{}bin\textbackslash{}systemstate.bat''
832 \item {\bf Client Run After Job = \lt{}command\gt{}}
833 \index[fd]{Client Run After Job }
834 This command is the same as {\bf Run After Job} except that it is run on the
835 client machine. Note, please see the notes above in {\bf Client Run Before
836 Job} concerning Windows clients.
838 \item {\bf Rerun Failed Levels = \lt{}yes|no\gt{}}
839 \index[fd]{Rerun Failed Levels }
840 If this directive is set to {\bf yes} (default no), and Bacula detects that a
841 previous job at a higher level (i.e. Full or Differential) has failed, the
842 current job level will be upgraded to the higher level. This is particularly
843 useful for Laptops where they may often be unreachable, and if a prior Full
844 save has failed, you wish the very next backup to be a Full save rather than
845 whatever level it is started as.
847 \item {\bf Spool Data = \lt{}yes|no\gt{}}
848 \index[fd]{Spool Data }
849 If this directive is set to {\bf yes} (default no), the Storage daemon will
850 be requested to spool the data for this Job to disk rather than write it
851 directly to tape. Once all the data arrives or the spool file maximum sizes
852 are reached, the data will be despooled and written to tape. When this
853 directive is set to yes, the Spool Attributes is also automatically set to
854 yes. Spooling data prevents tape shoe-shine (start and stop) during
855 Incremental saves. This option should not be used if you are writing to a
858 \item {\bf Spool Attributes = \lt{}yes|no\gt{}}
859 \index[fd]{Spool Attributes }
860 The default is set to {\bf no}, which means that the File attributes are sent
861 by the Storage daemon to the Director as they are stored on tape. However,
862 if you want to avoid the possibility that database updates will slow down
863 writing to the tape, you may want to set the value to {\bf yes}, in which
864 case the Storage daemon will buffer the File attributes and Storage
865 coordinates to a temporary file in the Working Directory, then when writing
866 the Job data to the tape is completed, the attributes and storage coordinates
867 will be sent to the Director. The default is {\bf no}.
869 \item {\bf Where = \lt{}directory\gt{}}
871 This directive applies only to a Restore job and specifies a prefix to the
872 directory name of all files being restored. This permits files to be restored
873 in a different location from which they were saved. If {\bf Where} is not
874 specified or is set to backslash ({\bf /}), the files will be restored to
875 their original location. By default, we have set {\bf Where} in the example
876 configuration files to be {\bf /tmp/bacula-restores}. This is to prevent
877 accidental overwriting of your files.
879 \item {\bf Replace = \lt{}replace-option\gt{}}
880 \index[dir]{Replace }
881 This directive applies only to a Restore job and specifies what happens when
882 Bacula wants to restore a file or directory that already exists. You have the
883 following options for {\bf replace-option}:
889 when the file to be restored already exists, it is deleted then replaced by
894 if the backed up file (on tape) is newer than the existing file, the existing
895 file is deleted and replaced by the back up.
899 if the backed up file (on tape) is older than the existing file, the existing
900 file is deleted and replaced by the back up.
904 if the backed up file already exists, Bacula skips restoring this file.
907 \item {\bf Prefix Links=\lt{}yes|no\gt{}}
908 \index[fd]{Prefix Links }
909 If a {\bf Where} path prefix is specified for a recovery job, apply it to
910 absolute links as well. The default is {\bf No}. When set to {\bf Yes} then
911 while restoring files to an alternate directory, any absolute soft links
912 will also be modified to point to the new alternate directory. Normally this
913 is what is desired -- i.e. everything is self consistent. However, if you
914 wish to later move the files to their original locations, all files linked
915 with absolute names will be broken.
917 \item {\bf Maximum Concurrent Jobs = \lt{}number\gt{}}
918 \index[dir]{Maximum Concurrent Jobs }
919 where \lt{}number\gt{} is the maximum number of Jobs from the current Job
920 resource that can run concurrently. Note, this directive limits only Jobs
921 with the same name as the resource in which it appears. Any other
922 restrictions on the maximum concurrent jobs such as in the Director, Client,
923 or Storage resources will also apply in addition to the limit specified here.
924 The default is set to 1, but you may set it to a larger number. We strongly
925 recommend that you read the WARNING documented under
926 \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
929 \item {\bf Reschedule On Error = \lt{}yes|no\gt{}}
930 \index[dir]{Reschedule On Error }
931 If this directive is enabled, and the job terminates in error, the job will
932 be rescheduled as determined by the {\bf Reschedule Interval} and {\bf
933 Reschedule Times} directives. If you cancel the job, it will not be
934 rescheduled. The default is {\bf no} (i.e. the job will not be rescheduled).
937 This specification can be useful for portables, laptops, or other machines
938 that are not always connected to the network or switched on.
940 \item {\bf Reschedule Interval = \lt{}time-specification\gt{}}
941 \index[dir]{Reschedule Interval }
942 If you have specified {\bf Reschedule On Error = yes} and the job terminates
943 in error, it will be rescheduled after the interval of time specified by
944 {\bf time-specification}. See
945 \ilink{ the time specification formats}{Time} in the Configure
946 chapter for details of time specifications. If no interval is specified, the
947 job will not be rescheduled on error.
949 \item {\bf Reschedule Times = \lt{}count\gt{}}
950 \index[dir]{Reschedule Times }
951 This directive specifies the maximum number of times to reschedule the job.
952 If it is set to zero (the default) the job will be rescheduled an indefinite
956 \item {\bf Priority = \lt{}number\gt{}}
957 \index[dir]{Priority }
958 This directive permits you to control the order in which your jobs run by
959 specifying a positive non-zero number. The higher the number, the lower the
960 job priority. Assuming you are not running concurrent jobs, all queued jobs
961 of priority 1 will run before queued jobs of priority 2 and so on,
962 regardless of the original scheduling order.
964 The priority only affects waiting jobs that are queued to run, not jobs that
965 are already running. If one or more jobs of priority 2 are already running,
966 and a new job is scheduled with priority 1, the currently running priority 2
967 jobs must complete before the priority 1 job is run.
969 The default priority is 10.
971 If you want to run concurrent jobs, which is not recommended, you should keep
972 these points in mind:
975 \item To run concurrent jobs, you must set Maximum Concurrent Jobs = 2 in 5
976 or 6 distinct places: in bacula-dir.conf in the Director, the Job, the
977 Client, the Storage resources; in bacula-fd in the FileDaemon (or Client)
978 resource, and in bacula-sd.conf in the Storage resource. If any one is
979 missing, it will throttle the jobs to one at a time.
980 \item Bacula concurrently runs jobs of only one priority at a time. It will
981 not simultaneously run a priority 1 and a priority 2 job.
982 \item If Bacula is running a priority 2 job and a new priority 1 job is
983 scheduled, it will wait until the running priority 2 job terminates even if
984 the Maximum Concurrent Jobs settings would otherwise allow two jobs to run
986 \item Suppose that bacula is running a priority 2 job and new priority 1 job
987 is scheduled and queued waiting for the running priority 2 job to terminate.
988 If you then start a second priority 2 job, the waiting priority 1 job will
989 prevent the new priority 2 job from running concurrently with the running
990 priority 2 job. That is: as long as there is a higher priority job waiting to
991 run, no new lower priority jobs will start even if the Maximum Concurrent
992 Jobs settings would normally allow them to run. This ensures that higher
993 priority jobs will be run as soon as possible.
996 If you have several jobs of different priority, it is best not to start them
997 at exactly the same time, because Bacula must examine them one at a time. If
998 by chance Bacula treats a lower priority first, then it will run before your
999 high priority jobs. To avoid this, start any higher priority a few seconds
1000 before lower ones. This insures that Bacula will examine the jobs in the
1001 correct order, and that your priority scheme will be respected.
1002 \label{WritePartAfterJob}
1004 \item {\bf Write Part After Job = \lt{}yes|no\gt{}}
1005 \index[sd]{Write Part After Job }
1006 If this directive is set to {\bf yes} (default {\bf no}), a new part file
1007 will be created after the job is finished.
1009 It should be set to {\bf yes} when writing to devices that require mount (for
1010 example DVD), so you are sure that the current part, containing this job's
1011 data, is written to the device, and that no data is left in the temporary
1012 file on the hard disk. However, on some media, like DVD+R and DVD-R, a lot of
1013 space (about 10Mb) is lost everytime a part is written. So, if you run
1014 several jobs each after another, you could set this directive to {\bf no} for
1015 all jobs, except the last one, to avoid wasting too much space, but to ensure
1016 that the data is written to the medium when all jobs are finished.
1018 It is ignored with tape and FIFO devices.
1021 The following is an example of a valid Job resource definition:
1028 Level = Incremental # default
1030 FileSet="Minou Full Set"
1033 Schedule = "MinouWeeklyCycle"
1039 \section*{The JobDefs Resource}
1040 \label{JobDefsResource}
1041 \index[general]{JobDefs Resource }
1042 \index[general]{Resource!JobDefs }
1043 \addcontentsline{toc}{section}{JobDefs Resource}
1045 The JobDefs resource permits all the same directives that can appear in a Job
1046 resource. However, a JobDefs resource does not create a Job, rather it can be
1047 referenced within a Job to provide defaults for that Job. This permits you to
1048 concisely define several nearly identical Jobs, each one referencing a JobDefs
1049 resource which contains the defaults. Only the changes from the defaults need
1050 be mentioned in each Job.
1052 \section*{The Schedule Resource}
1053 \label{ScheduleResource}
1054 \index[general]{Resource!Schedule }
1055 \index[general]{Schedule Resource }
1056 \addcontentsline{toc}{section}{Schedule Resource}
1058 The Schedule resource provides a means of automatically scheduling a Job as
1059 well as the ability to override the default Level, Pool, Storage and Messages
1060 resources. If a Schedule resource is not referenced in a Job, the Job may only
1061 be run manually. In general, you specify an action to be taken and when.
1066 \index[sd]{Schedule }
1067 Start of the Schedule directives. No {\bf Schedule} resource is required, but
1068 you will need at least one if you want Jobs to be automatically started.
1070 \item [Name = \lt{}name\gt{}]
1072 The name of the schedule being defined. The Name directive is required.
1074 \item [Run = \lt{}Job-overrides\gt{} \lt{}Date-time-specification\gt{} ]
1076 The Run directive defines when a Job is to be run, and what overrides if any
1077 to apply. You may specify multiple {\bf run} directives within a {\bf
1078 Schedule} resource. If you do, they will all be applied (i.e. multiple
1079 schedules). If you have two {\bf Run} directives that start at the same time,
1080 two Jobs will start at the same time (well, within one second of each
1083 The {\bf Job-overrides} permit overriding the Level, the Storage, the
1084 Messages, and the Pool specifications provided in the Job resource. In
1085 addition, the FullPool, the IncrementalPool, and the DifferentialPool
1086 specifications permit overriding the Pool specification according to what
1087 backup Job Level is in effect.
1089 By the use of overrides, you may customize a particular Job. For example, you
1090 may specify a Messages override for your Incremental backups that outputs
1091 messages to a log file, but for your weekly or monthly Full backups, you may
1092 send the output by email by using a different Messages override.
1094 {\bf Job-overrides} are specified as: {\bf keyword=value} where the keyword
1095 is Level, Storage, Messages, Pool, FullPool, DifferentialPool, or
1096 IncrementalPool, and the {\bf value} is as defined on the respective
1097 directive formats for the Job resource. You may specify multiple {\bf
1098 Job-overrides} on one {\bf Run} directive by separating them with one or more
1099 spaces or by separating them with a trailing comma. For example:
1105 is all files in the FileSet whether or not they have changed.
1107 \item [Level=Incremental]
1109 is all files that have changed since the last backup.
1113 specifies to use the Pool named {\bf Weekly}.
1115 \item [Storage=DLT\_Drive]
1116 \index[sd]{Storage }
1117 specifies to use {\bf DLT\_Drive} for the storage device.
1119 \item [Messages=Verbose]
1120 \index[sd]{Messages }
1121 specifies to use the {\bf Verbose} message resource for the Job.
1123 \item [FullPool=Full]
1124 \index[sd]{FullPool }
1125 specifies to use the Pool named {\bf Full} if the job is a full backup, or is
1126 upgraded from another type to a full backup.
1128 \item [DifferentialPool=Differential]
1129 \index[sd]{DifferentialPool }
1130 specifies to use the Pool named {\bf Differential} if the job is a
1131 differential backup.
1133 \item [IncrementalPool=Incremental]
1134 \index[sd]{IncrementalPool }
1135 specifies to use the Pool named {\bf Incremental} if the job is an
1138 \item [SpoolData=yes|no]
1139 \index[sd]{SpoolData }
1140 tells Bacula to request the Storage daemon to spool data to a disk file
1141 before putting it on tape.
1143 \item [WritePartAfterJob=yes|no]
1144 \index[sd]{WritePartAfterJob }
1145 tells Bacula to request the Storage daemon to write the current part file to
1146 the device when the job is finished (see
1147 \ilink{Write Part After Job directive in the Job
1148 resource}{WritePartAfterJob}).
1151 {\bf Date-time-specification} determines when the Job is to be run. The
1152 specification is a repetition, and as a default Bacula is set to run a job at
1153 the beginning of the hour of every hour of every day of every week of every
1154 month of every year. This is not normally what you want, so you must specify
1155 or limit when you want the job to run. Any specification given is assumed to
1156 be repetitive in nature and will serve to override or limit the default
1157 repetition. This is done by specifing masks or times for the hour, day of the
1158 month, day of the week, week of the month, week of the year, and month when
1159 you want the job to run. By specifying one or more of the above, you can
1160 define a schedule to repeat at almost any frequency you want.
1162 Basically, you must supply a {\bf month}, {\bf day}, {\bf hour}, and {\bf
1163 minute} the Job is to be run. Of these four items to be specified, {\bf day}
1164 is special in that you may either specify a day of the month such as 1, 2,
1165 ... 31, or you may specify a day of the week such as Monday, Tuesday, ...
1166 Sunday. Finally, you may also specify a week qualifier to restrict the
1167 schedule to the first, second, third, fourth, or fifth week of the month.
1169 For example, if you specify only a day of the week, such as {\bf Tuesday} the
1170 Job will be run every hour of every Tuesday of every Month. That is the {\bf
1171 month} and {\bf hour} remain set to the defaults of every month and all
1174 Note, by default with no other specification, your job will run at the
1175 beginning of every hour. If you wish your job to run more than once in any
1176 given hour, you will need to specify multiple {\bf run} specifications each
1177 with a different minute.
1179 The date/time to run the Job can be specified in the following way in
1186 <week-keyword> = 1st | 2nd | 3rd | 4th | 5th | first |
1187 second | third | forth | fifth
1188 <wday-keyword> = sun | mon | tue | wed | thu | fri | sat |
1189 sunday | monday | tuesday | wednesday |
1191 <week-of-year-keyword> = w00 | w01 | ... w52 | w53
1192 <month-keyword> = jan | feb | mar | apr | may | jun | jul |
1193 aug | sep | oct | nov | dec | january |
1194 february | ... | december
1195 <daily-keyword> = daily
1196 <weekly-keyword> = weekly
1197 <monthly-keyword> = monthly
1198 <hourly-keyword> = hourly
1199 <digit> = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
1200 <number> = <digit> | <digit><number>
1201 <12hour> = 0 | 1 | 2 | ... 12
1202 <hour> = 0 | 1 | 2 | ... 23
1203 <minute> = 0 | 1 | 2 | ... 59
1204 <day> = 1 | 2 | ... 31
1205 <time> = <hour>:<minute> |
1206 <12hour>:<minute>am |
1208 <time-spec> = <at-keyword> <time> |
1210 <date-keyword> = <void-keyword> <weekly-keyword>
1211 <day-range> = <day>-<day>
1212 <month-range> = <month-keyword>-<month-keyword>
1213 <wday-range> = <wday-keyword>-<wday-keyword>
1214 <range> = <day-range> | <month-range> |
1216 <date> = <date-keyword> | <day> | <range>
1217 <date-spec> = <date> | <date-spec>
1218 <day-spec> = <day> | <wday-keyword> |
1219 <day-range> | <wday-range> |
1221 <day-spec> = <day> | <wday-keyword> |
1222 <week-keyword> <wday-keyword>
1223 <month-spec> = <month-keyword> | <month-range> |
1225 <date-time-spec> = <month-spec> <day-spec> <time-spec>
1231 Note, the Week of Year specification wnn follows the ISO standard definition
1232 of the week of the year, where Week 1 is the week in which the first Thursday
1233 of the year occurs, or alternatively, the week which contains the 4th of
1234 January. Weeks are numbered w01 to w53. w00 for Bacula is the week that
1235 precedes the first ISO week (i.e. has the first few days of the year if any
1236 occur before Thursday). w00 is not defined by the ISO specification. A week
1237 starts with Monday and ends with Sunday.
1239 An example schedule resource that is named {\bf WeeklyCycle} and runs a job
1240 with level full each Sunday at 1:05am and an incremental job Monday through
1241 Saturday at 1:05am is:
1246 Name = "WeeklyCycle"
1247 Run = Level=Full sun at 1:05
1248 Run = Level=Incremental mon-sat at 1:05
1253 An example of a possible monthly cycle is as follows:
1258 Name = "MonthlyCycle"
1259 Run = Level=Full Pool=Monthly 1st sun at 1:05
1260 Run = Level=Differential 2nd-5th sun at 1:05
1261 Run = Level=Incremental Pool=Daily mon-sat at 1:05
1266 The first of every month:
1272 Run = Level=Full on 1 at 1:05
1273 Run = Level=Incremental on 2-31 at 1:05
1284 Run = Level=Full hourly at 0:05
1285 Run = Level=Full hourly at 0:15
1286 Run = Level=Full hourly at 0:25
1287 Run = Level=Full hourly at 0:35
1288 Run = Level=Full hourly at 0:45
1289 Run = Level=Full hourly at 0:55
1294 \subsection*{Technical Notes on Schedules}
1295 \index[general]{Schedules!Technical Notes on }
1296 \index[general]{Technical Notes on Schedules }
1297 \addcontentsline{toc}{subsection}{Technical Notes on Schedules}
1299 Internally Bacula keeps a schedule as a bit mask. There are six masks and a
1300 minute field to each schedule. The masks are hour, day of the month (mday),
1301 month, day of the week (wday), week of the month (wom), and week of the year
1302 (woy). The schedule is initialized to have the bits of each of these masks
1303 set, which means that at the beginning of every hour, the job will run. When
1304 you specify a month for the first time, the mask will be cleared and the bit
1305 corresponding to your selected month will be selected. If you specify a second
1306 month, the bit corresponding to it will also be added to the mask. Thus when
1307 Bacula checks the masks to see if the bits are set corresponding to the
1308 current time, your job will run only in the two months you have set. Likewise,
1309 if you set a time (hour), the hour mask will be cleared, and the hour you
1310 specify will be set in the bit mask and the minutes will be stored in the
1313 For any schedule you have defined, you can see how these bits are set by doing
1314 a {\bf show schedules} command in the Console program. Please note that the
1315 bit mask is zero based, and Sunday is the first day of the week (bit zero).
1317 \section*{The FileSet Resource}
1318 \label{FileSetResource}
1319 \index[general]{Resource!FileSet }
1320 \index[general]{FileSet Resource }
1321 \addcontentsline{toc}{section}{FileSet Resource}
1323 The FileSet resource defines what files are to be included in a backup job. At
1324 least one {\bf FileSet} resource is required for each backup Job. It consists
1325 of a list of files or directories to be included, a list of files or
1326 directories to be excluded and the various backup options such as compression,
1327 encryption, and signatures that are to be applied to each file.
1329 Any change to the list of the included files will cause Bacula to
1330 automatically create a new FileSet (defined by the name and an MD5 checksum of
1331 the Include contents). Each time a new FileSet is created, Bacula will ensure
1332 that the first backup is always a Full save.
1337 \index[dir]{FileSet }
1338 Start of the FileSet resource. At least one {\bf FileSet} resource must be
1341 \item [Name = \lt{}name\gt{}]
1343 The name of the FileSet resource. This directive is required.
1345 \item [Ignore FileSet Changes = \lt{}yes|no\gt{}
1347 \index[dir]{Ignore FileSet Changes }
1348 If this directive is set to {\bf yes}, any changes you make to the FileSet
1349 Include or Exclude lists will be ignored and not cause Bacula to immediately
1350 perform a Full backup. The default is {\bf no}, in which case, if you change
1351 the Include or Exclude, Bacula will force a Full backup to ensure that
1352 everything is properly backed up. It is not recommended to set this directive
1353 to yes. This directive is available in Bacula version 1.35.4 or later.
1355 \item [{Include \ \{ [ Options \{\lt{}file-options\gt{}\} ...]
1356 \lt{}file-list\gt{} \}
1358 \index[dir]{Include \ \{ [ Options \{\lt{}file-options\gt{}\} ...]
1359 \lt{}file-list\gt{} \} }
1361 \item [Options \ \{ \lt{}file-options\gt{} \}
1363 \index[dir]{Options \ \{ \lt{}file-options\gt{} \} }
1365 \item [Exclude \ \{ \lt{}file-list\gt{} \}]
1366 \index[dir]{Exclude \ \{ \lt{}file-list\gt{} \} }
1368 The Include resource must contain a list of directories and/or files to be
1369 processed in the backup job. Normally, all files found in all subdirectories
1370 of any directory in the Include File list will be backed up. The Include
1371 resource may also oner more Options resources that specify options such as
1372 compression to be applied to all or any subset of the files found for backup.
1374 There can be any number of {\bf Include} resources within the FileSet, each
1375 having its own list of directories or files to be backed up and the backup
1376 options defined by one or more Options resources. The {\bf file-list} consists
1377 of one file or directory name per line. Directory names should be specified
1378 without a trailing slash.
1380 You should always specify a full path for every directory and file that you
1381 list in the FileSet. In addition, on Windows machines, you should {\bf always}
1382 prefix the directory or filename with the drive specification (e.g. {\bf
1383 c:/xxx}) using Unix directory name separators (forward slash).
1385 Bacula's default for processing directories is to recursively descend in the
1386 directory saving all files and subdirectories. Bacula will not by default
1387 cross filesystems (or mount points in Unix parlance). This means that if you
1388 specify the root partition (e.g. {\bf /}), Bacula will save only the root
1389 partition and not any of the other mounted filesystems. Similarly on Windows
1390 systems, you must explicitly specify each of the drives you want saved (e.g.
1391 {\bf c:/} and {\bf d:/} ...). In addition, at least for Windows systems, you
1392 will most likely want to enclose each specification within double quotes
1393 particularly if the directory (or file) name contains spaces. The {\bf df}
1394 command on Unix systems will show you which mount points you must specify to
1395 save everything. See below for an example.
1397 Take special care not to include a directory twice or Bacula will backup the
1398 same files two times wasting a lot of space on your archive device. Including
1399 a directory twice is very easy to do. For example:
1406 Options { compression=GZIP }
1411 on a Unix system where /usr is a subdirectory (rather than a mounted
1412 filesystem) will cause /usr to be backed up twice. In this case, on Bacula
1413 versions prior to 1.32f-5-09Mar04 due to a bug, you will not be able to
1414 restore hard linked files that were backed up twice.
1416 If you have used Bacula prior to version 1.34.3, you will note three things in
1417 the new FileSet syntax:
1420 \item There is no equal sign (=) after the include and before the opening
1422 \item Each directory (or filename) to be backed up is preceded by a {\bf File
1423 =}. Previously they were simply listed on separate lines.
1424 \item The options that previously appeared on the Include line now must be
1425 specified within their own Options resource.
1428 The Options resource is optional, but when specified, it will contain a list
1429 of {\bf keyword=value} options to be applied to the file-list. Multiple
1430 Options resources may be specified one after another. As the files are found
1431 in the specified directories, the Options will applied to the filenames to
1432 determine if and how the file should be backed up. The Options resources are
1433 applied in the order they are specified in the FileSet until the first one
1434 that matches. An Options resource that does not contain a {\bf wild} directive
1435 (wild-card specification, see below) is assumed to match any filename. This is
1436 important to understand, because once Bacula determine that the Options
1437 matches the file under consideration, that file will be saved without looking
1438 at any other Options resources that may be present. This means that any wild
1439 cards must appear before an Option resource without wild cards.
1441 If for some reason, Bacula applies all the Options resources to a file under
1442 consideration for backup, but there are no matches (generally because of wild
1443 cards that don't match), Bacula as a default will then backup the file. This
1444 is quite logical if you consider the case of no Options, where you want
1445 everything to be backed up. However, one additional point is that in the case
1446 that no match was found, Bacula will use the options found in the last Options
1447 resource. As a consequence, if you want a particular set of ``default''
1448 options, you should put them in an Options resource after any other Options.
1450 The directives within an Options resource may be one of the following:
1454 \item [compression=GZIP]
1455 \index[fd]{compression }
1456 All files saved will be software compressed using the GNU ZIP compression
1457 format. The compression is done on a file by file basis by the File daemon.
1458 If there is a problem reading the tape in a single record of a file, it will
1459 at most affect that file and none of the other files on the tape. Normally
1460 this option is {\bf not} needed if you have a modern tape drive as the drive
1461 will do its own compression. In fact, if you specify software compression at
1462 the same time you have hardware compression turned on, your files may
1463 actually take more space on the volume.
1465 Software compression is very important if you are writing your Volumes to a
1466 file, and it can also be helpful if you have a fast computer but a slow
1469 Specifying {\bf GZIP} uses the default compression level six (i.e. {\bf GZIP}
1470 is identical to {\bf GZIP6}). If you want a different compression level (1
1471 through 9), you can specify it by appending the level number with no
1472 intervening spaces to {\bf GZIP}. Thus {\bf compression=GZIP1} would give
1473 minimum compression but the fastest algorithm, and {\bf compression=GZIP9}
1474 would give the highest level of compression, but requires more computation.
1475 According to the GZIP documentation, compression levels greater than 6
1476 generally give very little extra compression and are rather CPU intensive.
1478 \item [signature=SHA1]
1479 \index[fd]{signature }
1480 An SHA1 signature will be computed for all The SHA1 algorithm is purported to
1481 be some what slower than the MD5 algorithm, but at the same time is
1482 significantly better from a cryptographic point of view (i.e. much fewer
1483 collisions, much lower probability of being hacked.) It adds four more bytes
1484 than the MD5 signature. We strongly recommend that either this option or MD5
1485 be specified as a default for all files. Note, only one of the two options
1486 MD5 or SHA1 can be computed for any file.
1488 \item [signature=MD5]
1489 \index[fd]{signature }
1490 An MD5 signature will be computed for all files saved. Adding this option
1491 generates about 5\% extra overhead for each file saved. In addition to the
1492 additional CPU time, the MD5 signature adds 16 more bytes per file to your
1493 catalog. We strongly recommend that this option or the SHA1 option be
1494 specified as a default for all files.
1496 \item [verify=\lt{}options\gt{}]
1498 The options letters specified are used when running a {\bf Verify
1499 Level=Catalog} as well as the {\bf DiskToCatalog} level job. The options
1500 letters may be any combination of the following:
1508 compare the permission bits
1511 compare the number of links
1517 compare the group id
1523 compare the access time
1526 compare the modification time (st\_mtime)
1529 compare the change time (st\_ctime)
1532 report file size decreases
1535 compare the MD5 signature
1538 compare the SHA1 signature
1541 A useful set of general options on the {\bf Level=Catalog} or {\bf
1542 Level=DiskToCatalog} verify is {\bf pins5} i.e. compare permission bits,
1543 inodes, number of links, size, and MD5 changes.
1545 \item {\bf onefs=yes|no}
1547 If set to {\bf yes} (the default), {\bf Bacula} will remain on a single file
1548 system. That is it will not backup file systems that are mounted on a
1549 subdirectory. If you wish to backup multiple filesystems, you can explicitly
1550 list each file system you want saved. Otherwise, if you set the onefs option
1551 to {\bf no}, Bacula will backup all mounted file systems (i.e. traverse mount
1552 points) that are found within the {\bf FileSet}. Thus if you have NFS or
1553 Samba file systems mounted on a directory listed in your FileSet, they will
1554 also be backed up. Normally, it is preferable to set {\bf onefs=yes} and to
1555 explicitly name each filesystem you want backed up. Explicitly naming the
1556 filesystems you want backed up avoids the possibility of getting into a
1557 infinite loop recursing filesystems. See the example below for more details.
1560 \item {\bf portable=yes|no}
1561 \index[dir]{portable }
1562 If set to {\bf yes} (default is {\bf no}), the Bacula File daemon will backup
1563 Win32 files in a portable format, but not all Win32 file attributes will be
1564 saved and restored. By default, this option is set to {\bf no}, which means
1565 that on Win32 systems, the data will be backed up using Windows API calls and
1566 on WinNT/2K/XP, all the security and ownership attributes will be properly
1567 backed up (and restored). However this format is not portable to other
1568 systems -- e.g. Unix, Win95/98/Me. When backing up Unix systems, this option
1569 is ignored, and unless you have a specific need to have portable backups, we
1570 recommend accept the default ({\bf no}) so that the maximum information
1571 concerning your files is saved.
1573 \item {\bf recurse=yes|no}
1574 \index[fd]{recurse }
1575 If set to {\bf yes} (the default), Bacula will recurse (or descend) into all
1576 subdirectories found unless the directory is explicitly excluded using an
1577 {\bf exclude} definition. If you set {\bf recurse=no}, Bacula will save the
1578 subdirectory entries, but not descend into the subdirectories, and thus will
1579 not save the files or directories contained in the subdirectories. Normally,
1580 you will want the default ({\bf yes}).
1582 \item {\bf sparse=yes|no}
1583 \index[dir]{sparse }
1584 Enable special code that checks for sparse files such as created by ndbm. The
1585 default is {\bf no}, so no checks are made for sparse files. You may specify
1586 {\bf sparse=yes} even on files that are not sparse file. No harm will be
1587 done, but there will be a small additional overhead to check for buffers of
1588 all zero, and a small additional amount of space on the output archive will
1589 be used to save the seek address of each non-zero record read.
1591 {\bf Restrictions:} Bacula reads files in 32K buffers. If the whole buffer is
1592 zero, it will be treated as a sparse block and not written to tape. However,
1593 if any part of the buffer is non-zero, the whole buffer will be written to
1594 tape, possibly including some disk sectors (generally 4098 bytes) that are
1595 all zero. As a consequence, Bacula's detection of sparse blocks is in 32K
1596 increments rather than the system block size. If anyone considers this to be
1597 a real problem, please send in a request for change with the reason. The
1598 sparse code was first implemented in version 1.27.
1600 If you are not familiar with sparse files, an example is say a file where you
1601 wrote 512 bytes at address zero, then 512 bytes at address 1 million. The
1602 operating system will allocate only two blocks, and the empty space or hole
1603 will have nothing allocated. However, when you read the sparse file and read
1604 the addresses where nothing was written, the OS will return all zeros as if
1605 the space were allocated, and if you backup such a file, a lot of space will
1606 be used to write zeros to the volume. Worse yet, when you restore the file,
1607 all the previously empty space will now be allocated using much more disk
1608 space. By turning on the {\bf sparse} option, Bacula will specifically look
1609 for empty space in the file, and any empty space will not be written to the
1610 Volume, nor will it be restored. The price to pay for this is that Bacula
1611 must search each block it reads before writing it. On a slow system, this may
1612 be important. If you suspect you have sparse files, you should benchmark the
1613 difference or set sparse for only those files that are really sparse.
1616 \item {\bf readfifo=yes|no}
1617 \index[fd]{readfifo }
1618 If enabled, tells the Client to read the data on a backup and write the data
1619 on a restore to any FIFO (pipe) that is explicitly mentioned in the FileSet.
1620 In this case, you must have a program already running that writes into the
1621 FIFO for a backup or reads from the FIFO on a restore. This can be
1622 accomplished with the {\bf RunBeforeJob} directive. If this is not the case,
1623 Bacula will hang indefinitely on reading/writing the FIFO. When this is not
1624 enabled (default), the Client simply saves the directory entry for the FIFO.
1626 \item {\bf mtimeonly=yes|no}
1627 \index[dir]{mtimeonly }
1628 If enabled, tells the Client that the selection of files during Incremental
1629 and Differential backups should based only on the st\_mtime value in the
1630 stat() packet. The default is {\bf no} which means that the selection of
1631 files to be backed up will be based on both the st\_mtime and the st\_ctime
1632 values. In general, it is not recommended to use this option.
1634 \item {\bf keepatime=yes|no}
1635 \index[dir]{keepatime }
1636 The default is {\bf no}. When enabled, Bacula will reset the st\_atime
1637 (access time) field of files that it backs up to their value prior to the
1638 backup. This option is not generally recommended as there are very few
1639 programs that use st\_atime, and the backup overhead is increased because of
1640 the additional system call necessary to reset the times. (I'm not sure this
1643 \item {\bf wild=\lt{}string\gt{}}
1645 Specifies a wild-card string to be applied to the Files. Note, if {\bf
1646 Exclude} is not enabled, the wild-card will select which files are to be
1647 included. If {\bf Exclude=yes} is specified, the wild-card will select which
1648 files are to be excluded. Multiple wild-card directives may be specified, and
1649 they will be applied in turn until the first one that matches.
1651 \item {\bf regex=\lt{}string\gt{}}
1653 Specifies a POSIX extended regular expression to be applied to the Files.
1654 This directive is available in version 1.35 and later. If {\bf Exclude} is
1655 not enabled, the regex will select which files are to be included. If {\bf
1656 Exclude=yes} is specified, the regex will select which files are to be
1657 excluded. Multiple regex directives may be specified within an Options
1658 resource, and they will be applied in turn until the first one that matches.
1661 \item {\bf exclude=yes|no}
1662 \index[dir]{exclude }
1663 The default is {\bf no}. When enabled, any files matched within the Options
1664 will be excluded from the backup.
1667 \item {\bf aclsupport=yes|no}
1668 \index[dir]{aclsupport }
1669 The default is {\bf no}. If this option is set to yes, and you have the POSIX
1670 {\bf libacl} installed on your system, Bacula will backup the file and
1671 directory UNIX Access Control Lists (ACL) as defined in IEEE Std 1003.1e
1672 draft 17 and ``POSIX.1e'' (abandoned). This feature is available on UNIX only
1673 and depends on the ACL library. Bacula is automatically compiled with ACL
1674 support if the {\bf libacl} library is installed on your system (shown in
1675 config.out). While restoring the files Bacula will try to restore the ACLs,
1676 if there is no ACL support available on the system, Bacula restores the files
1677 and directories but not the ACL information. Please note, if you backup an
1678 EXT3 or XFS filesystem with ACLs, then you restore them to a different
1679 filesystem (perhaps reiserfs) that does not have ACLs, the ACLs will be
1683 {\bf \lt{}file-list\gt{}} is a list of directory and/or filename names
1684 specified with a {\bf File =} directive. To include names containing spaces,
1685 enclose the name between double-quotes.
1687 There are a number of special cases when specifying directories and files in a
1688 {\bf file-list}. They are:
1691 \item Any name preceded by an at-sign (@) is assumed to be the name of a
1692 file, which contains a list of files each preceded by a ``File =''. The named
1693 file is read once when the configuration file is parsed during the Director
1694 startup. Note, that the file is read on the Director's machine and not on
1695 the Client's. In fact, the @filename can appear anywhere within the conf file
1696 where a token would be read, and the contents of the named file will be
1697 logically inserted in the place of the @filename. What must be in the file
1698 depends on the location the @filename is specified in the conf file.
1699 \item Any name beginning with a vertical bar (|) is assumed to be the name of
1700 a program. This program will be executed on the Director's machine at the
1701 time the Job starts (not when the Director reads the configuration file), and
1702 any output from that program will be assumed to be a list of files or
1703 directories, one per line, to be included. This allows you to have a job that
1704 for example includes all the local partitions even if you change the
1705 partitioning by adding a disk. In general, you will need to prefix your
1706 command or commands with a {\bf sh -c} so that they are invoked by a shell.
1707 This will not be the case if you are invoking a script as in the second
1708 example below. Also, you must take care to escape (precede with a
1709 \textbackslash{}) wild-cards, shell character, and to ensure that any spaces
1710 in your command are escaped as well. If you use a single quotes (') within a
1711 double quote (``), Bacula will treat everything between the single quotes as
1712 one field so it will not be necessary to escape the spaces. In general,
1713 getting all the quotes and escapes correct is a real pain as you can see by
1714 the next example. As a consequence, it is often easier to put everything in a
1715 file and simply use the file name within Bacula. In that case the {\bf sh
1716 -c} will not be necessary providing the first line of the file is {\bf
1725 Options { signature = SHA1 }
1726 File = "|sh -c 'df -l | grep \"^/dev/hd[ab]\" | grep -v \".*/tmp\" \
1727 | awk \"{print \\$6}\"'"
1732 will produce a list of all the local partitions on a RedHat Linux system.
1733 Note, the above line was split, but should normally be written on one line.
1734 Quoting is a real problem because you must quote for Bacula which consists of
1735 preceding every \textbackslash{} and every '' with a \textbackslash{}, and
1736 you must also quote for the shell command. In the end, it is probably easier
1737 just to execute a small file with:
1745 File = "|my_partitions"
1750 where my\_partitions has:
1755 df -l | grep "^/dev/hd[ab]" | grep -v ".*/tmp" \
1760 If the vertical bar (|) in front of my\_partitions is preceded by a backslash
1761 as in \textbackslash{}|, the program will be executed on the Client's machine
1762 instead of on the Director's machine -- (this is implemented but not
1763 thoroughly tested, and is reported to work on Windows). Please note that if
1764 the filename is given within quotes, you will need to use two slashes. An
1765 example, provided by John Donagher, that backs up all the local UFS
1766 partitions on a remote system is:
1771 Name = "All local partitions"
1773 Options { signature=SHA1; onefs=yes; }
1774 File = "\\|bash -c \"df -klF ufs | tail +2 | awk '{print \$6}'\""
1780 Note, it requires two backslash characters after the double quote (one
1781 preserves the next one). If you are a Linux user, just change the {\bf ufs}
1782 to {\bf ext3} (or your preferred filesystem type) and you will be in
1784 \item Any file-list item preceded by a less-than sign (\lt{}) will be taken
1785 to be a file. This file will be read on the Director's machine at the time
1786 the Job starts, and the data will be assumed to be a list of directories or
1787 files, one per line, to be included. The names should not be quoted even if
1788 they contain spaces. This feature allows you to modify the external file and
1789 change what will be saved without stopping and restarting Bacula as would be
1790 necessary if using the @ modifier noted above.
1792 If you precede the less-than sign (\lt{}) with a backslash as in
1793 \textbackslash{}\lt{}, the file-list will be read on the Client machine
1794 instead of on the Director's machine. Please note that if the filename is
1795 given within quotes, you will need to use two slashes.
1796 \item If you explicitly specify a block device such as {\bf /dev/hda1}, then
1797 Bacula (starting with version 1.28) will assume that this is a raw partition
1798 to be backed up. In this case, you are strongly urged to specify a {\bf
1799 sparse=yes} include option, otherwise, you will save the whole partition
1800 rather than just the actual data that the partition contains. For example:
1805 Options { signature=MD5; sparse=yes }
1811 will backup the data in device /dev/hd6.
1813 Ludovic Strappazon has pointed out that this feature can be used to backup a
1814 full Microsoft Windows disk. Simply boot into the system using a Linux Rescue
1815 disk, then load a statically linked Bacula as described in the
1816 \ilink{ Disaster Recovery Using Bacula}{_ChapterStart38} chapter of
1817 this manual. Then save the whole disk partition. In the case of a disaster,
1818 you can then restore the desired partition by again booting with the rescue
1819 disk and doing a restore of the partition.
1820 \item If you explicitly specify a FIFO device name (created with mkfifo), and
1821 you add the option {\bf readfifo=yes} as an option, Bacula will read the FIFO
1822 and back its data up to the Volume. For example:
1831 File = /home/abc/fifo
1836 if {\bf /home/abc/fifo} is a fifo device, Bacula will open the fifo, read it,
1837 and store all data thus obtained on the Volume. Please note, you must have a
1838 process on the system that is writing into the fifo, or Bacula will hang,
1839 and after one minute of waiting, Bacula will give up and go on to the next
1840 file. The data read can be anything since Bacula treats it as a stream.
1842 This feature can be an excellent way to do a ``hot'' backup of a very large
1843 database. You can use the {\bf RunBeforeJob} to create the fifo and to start
1844 a program that dynamically reads your database and writes it to the fifo.
1845 Bacula will then write it to the Volume.
1847 During the restore operation, the inverse is true, after Bacula creates the
1848 fifo if there was any data stored with it (no need to explicitly list it or
1849 add any options), that data will be written back to the fifo. As a
1850 consequence, if any such FIFOs exist in the fileset to be restored, you must
1851 ensure that there is a reader program or Bacula will block, and after one
1852 minute, Bacula will time out the write to the fifo and move on to the next
1858 The following is an example of a valid FileSet resource definition. Note, the
1859 first Include pulls in the contents of the file {\bf /etc/backup.list} when
1860 Bacula is started (i.e. the @).
1872 File = @/etc/backup.list
1880 File = /usr/lib/another_file
1886 Note, in the above example, all the files contained in /etc/backup.list will
1887 be compressed with GZIP compression, an SHA1 signature will be computed on the
1888 file's contents (its data), and sparse file handling will apply.
1890 The two directories /root/myfile and /usr/lib/another\_file will also be saved
1891 without any options, but all files in those directories with the extension
1892 {\bf .o} will be excluded.
1894 Suppose you want to save everything except {\bf /tmp} on your system. Doing a
1895 {\bf df} command, you get the following output:
1900 Filesystem 1k-blocks Used Available Use% Mounted on
1901 /dev/hda5 5044156 439232 4348692 10% /
1902 /dev/hda1 62193 4935 54047 9% /boot
1903 /dev/hda9 20161172 5524660 13612372 29% /home
1904 /dev/hda2 62217 6843 52161 12% /rescue
1905 /dev/hda8 5044156 42548 4745376 1% /tmp
1906 /dev/hda6 5044156 2613132 2174792 55% /usr
1907 none 127708 0 127708 0% /dev/shm
1908 //minimatou/c$ 14099200 9895424 4203776 71% /mnt/mmatou
1909 lmatou:/ 1554264 215884 1258056 15% /mnt/matou
1910 lmatou:/home 2478140 1589952 760072 68% /mnt/matou/home
1911 lmatou:/usr 1981000 1199960 678628 64% /mnt/matou/usr
1912 lpmatou:/ 995116 484112 459596 52% /mnt/pmatou
1913 lpmatou:/home 19222656 2787880 15458228 16% /mnt/pmatou/home
1914 lpmatou:/usr 2478140 2038764 311260 87% /mnt/pmatou/usr
1915 deuter:/ 4806936 97684 4465064 3% /mnt/deuter
1916 deuter:/home 4806904 280100 4282620 7% /mnt/deuter/home
1917 deuter:/files 44133352 27652876 14238608 67% /mnt/deuter/files
1921 If you specify only {\bf /} in your Include list, Bacula will only save the
1922 Filesystem {\bf /dev/hda5}. To save all file systems except {\bf /tmp} with
1923 out including any of the Samba or NFS mounted systems, and explicitly
1924 excluding a /tmp, /proc, .journal, and .autofsck, which you will not want to
1925 be saved and restored, you can use the following:
1930 Name = Include_example
1949 Since /tmp is on its own filesystem and it was not explicitly named in the
1950 Include list, it is not really needed in the exclude list. It is better to
1951 list it in the Exclude list for clarity, and in case the disks are changed so
1952 that it is no longer in its own partition.
1954 Please be aware that allowing Bacula to traverse or change file systems can be
1955 {\bf very} dangerous. For example, with the following:
1960 Name = "Bad example"
1962 Options { onefs=no }
1969 you will be backing up an NFS mounted partition ({\bf /mnt/matou}), and since
1970 {\bf onefs} is set to {\bf no}, Bacula will traverse file systems. Now if {\bf
1971 /mnt/matou} has the current machine's file systems mounted, as is often the
1972 case, you will get yourself into a recursive loop and the backup will never
1975 The following FileSet definition will backup a raw partition:
1980 Name = "RawPartition"
1982 Options { sparse=yes }
1989 While backing up and restoring a raw partition, you should ensure that no
1990 other process including the system is writing to that partition. As a
1991 precaution, you are strongly urged to ensure that the raw partition is not
1992 mounted or is mounted read-only. If necessary, this can be done using the {\bf
1993 RunBeforeJob} directive.
1996 \subsection*{Windows Considerations for FileSets}
1997 \index[general]{FileSets!Windows Considerations for }
1998 \index[general]{Windows Considerations for FileSets }
1999 \addcontentsline{toc}{subsection}{Windows Considerations for FileSets}
2001 If you are entering Windows file names, the directory path may be preceded by
2002 the drive and a colon (as in c:). However, the path separators must be
2003 specified in Unix convention (i.e. forward slash (/)). If you wish to include
2004 a quote in a file name, precede the quote with a backslash
2005 (\textbackslash{}\textbackslash{}). For example you might use the following
2006 for a Windows machine to backup the ``My Documents'' directory:
2011 Name = "Windows Set"
2018 File = "c:/My Documents"
2024 For exclude lists to work correctly on Windows, you must observe the following
2028 \item Filenames are case sensitive, so you must use the correct case.
2029 \item To exclude a directory, you must not have a trailing slash on the
2031 \item If you have spaces in your filename, you must enclose the entire name
2032 in double-quote characters (``). Trying to use a backslash before the space
2034 \item If you are using the old Exclude syntax (noted below), you may not
2035 specify a drive letter in the exclude. The new syntax noted above should work
2036 fine including driver letters.
2039 Thanks to Thiago Lima for summarizing the above items for us. If you are
2040 having difficulties getting includes or excludes to work, you might want to
2041 try using the {\bf estimate job=xxx listing} command documented in the
2042 \ilink{Console chapter}{estimate} of this manual.
2044 On Win32 systems, if you move a directory or file or rename a file into the
2045 set of files being backed up, and a Full backup has already been made, Bacula
2046 will not know there are new files to be saved during an Incremental or
2047 Differential backup (blame Microsoft, not me). To avoid this problem, please
2048 {\bf copy} any new directory or files into the backup area. If you do not have
2049 enough disk to copy the directory or files, move them, but then initiate a
2052 \subsubsection*{Excluding Files and Directories}
2053 \index[general]{Directories!Excluding Files and }
2054 \index[general]{Excluding Files and Directories }
2055 \addcontentsline{toc}{subsubsection}{Excluding Files and Directories}
2057 You may also include full filenames or directory names in addition to using
2058 wild-cards and {\bf Exclude=yes} in the Options resource as specified above by
2059 simply including the files to be excluded in an Exclude resource within the
2060 FileSet. For example:
2065 Name = Exclusion_example
2086 \subsection*{A Windows Example FileSet}
2087 \index[general]{FileSet!Windows Example }
2088 \index[general]{Windows Example FileSet }
2089 \addcontentsline{toc}{subsection}{Windows Example FileSet}
2091 The following example was contributed by Phil Stracchino:
2095 This is my Windows 2000 fileset:
2097 Name = "Windows 2000 Full Set"
2105 # Most of these files are excluded not because we don't want
2106 # them, but because Win2K won't allow them to be backed up
2107 # except via proprietary Win32 API calls.
2108 File = "/Documents and Settings/*/Application Data/*/Profiles/
2110 File = "/Documents and Settings/*/Local Settings/Application Data/
2111 Microsoft/Windows/[Uu][Ss][Rr][Cc][Ll][Aa][Ss][Ss].*"
2112 File = "/Documents and Settings/*/[Nn][Tt][Uu][Ss][Ee][Rr].*"
2113 File = "/Documents and Settings/*/Cookies/*"
2114 File = "/Documents and Settings/*/Local Settings/History/*"
2115 File = "/Documents and Settings/*/Local Settings/
2116 Temporary Internet Files/*"
2117 File = "/Documents and Settings/*/Local Settings/Temp/*"
2119 File = "/WINNT/security/logs/scepol.log"
2120 File = "/WINNT/system32/config/*"
2121 File = "/WINNT/msdownld.tmp/*"
2122 File = "/WINNT/Internet Logs/*"
2123 File = "/WINNT/$Nt*Uninstall*"
2124 File = "/WINNT/Temp/*"
2127 File = "/pagefile.sys"
2133 Note, the three line of the above Exclude were split to fit on the document
2134 page, they should be written on a single line in real use.
2136 \subsection*{The Old FileSet Resource}
2137 \index[general]{Resource!Old FileSet }
2138 \index[general]{Old FileSet Resource }
2139 \addcontentsline{toc}{subsection}{Old FileSet Resource}
2141 The old pre-version 1.34.3 FileSet Resource has been deprecated but will still
2142 work. You are encouraged to convert to using the new form since the old code
2143 will be removed in version 1.37.
2145 \subsection*{Testing Your FileSet}
2146 \index[general]{FileSet!Testing Your }
2147 \index[general]{Testing Your FileSet }
2148 \addcontentsline{toc}{subsection}{Testing Your FileSet}
2150 If you wish to get an idea of what your FileSet will really backup or if your
2151 exclusion rules will work correctly, you can test it by using the {\bf
2152 estimate} command in the Console program. See the
2153 \ilink{estimate command}{estimate} in the Console chapter of this
2156 \subsection*{Windows NTFS Naming Considerations}
2157 \index[general]{Windows NTFS Naming Considerations }
2158 \index[general]{Considerations!Windows NTFS Naming }
2159 \addcontentsline{toc}{subsection}{Windows NTFS Naming Considerations}
2161 NTFS filenames containing Unicode characters (i.e. \gt{} 0xFF) cannot be
2162 explicitly named at the moment. You must include such names by naming a higher
2163 level directory or a drive letter that does not contain Unicode characters.
2165 \section*{The Client Resource}
2166 \label{ClientResource2}
2167 \index[general]{Resource!Client }
2168 \index[general]{Client Resource }
2169 \addcontentsline{toc}{section}{Client Resource}
2171 The Client resource defines the attributes of the Clients that are served by
2172 this Director; that is the machines that are to be backed up. You will need
2173 one Client resource definition for each machine to be backed up.
2177 \item [Client (or FileDaemon)]
2178 \index[dir]{Client (or FileDaemon) }
2179 Start of the Client directives.
2181 \item [Name = \lt{}name\gt{}]
2183 The client name which will be used in the Job resource directive or in the
2184 console run command. This directive is required.
2186 \item [Address = \lt{}address\gt{}]
2187 \index[console]{Address }
2188 Where the address is a host name, a fully qualified domain name, or a network
2189 address in dotted quad notation for a Bacula File server daemon. This
2190 directive is required.
2192 \item [FD Port = \lt{}port-number\gt{}]
2193 \index[console]{FD Port }
2194 Where the port is a port number at which the Bacula File server daemon can be
2195 contacted. The default is 9102.
2197 \item [Catalog = \lt{}Catalog-resource-name\gt{}]
2198 \index[console]{Catalog }
2199 This specifies the name of the catalog resource to be used for this Client.
2200 This directive is required.
2202 \item [Password = \lt{}password\gt{}]
2203 \index[console]{Password }
2204 This is the password to be used when establishing a connection with the File
2205 services, so the Client configuration file on the machine to be backed up
2206 must have the same password defined for this Director. This directive is
2207 required. If you have either {\bf /dev/random} {\bf bc} on your machine,
2208 Bacula will generate a random password during the configuration process,
2209 otherwise it will be left blank.
2210 \label{FileRetention}
2212 \item [File Retention = \lt{}time-period-specification\gt{} ]
2213 \index[fd]{File Retention }
2214 The File Retention directive defines the length of time that Bacula will keep
2215 File records in the Catalog database. When this time period expires, and if
2216 {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) File records
2217 that are older than the specified File Retention period. Note, this affects
2218 only records in the catalog database. It does not effect your archive
2221 File records may actually be retained for a shorter period than you specify
2222 on this directive if you specify either a shorter {\bf Job Retention} or
2223 shorter {\bf Volume Retention} period. The shortest retention period of the
2224 three takes precedence. The time may be expressed in seconds, minutes,
2225 hours, days, weeks, months, quarters, or years. See the
2226 \ilink{ Configuration chapter}{Time} of this manual for
2227 additional details of time specification.
2229 The default is 60 days.
2230 \label{JobRetention}
2232 \item [Job Retention = \lt{}time-period-specification\gt{} ]
2233 \index[fd]{Job Retention }
2234 The Job Retention directive defines the length of time that Bacula will keep
2235 Job records in the Catalog database. When this time period expires, and if
2236 {\bf AutoPrune} is set to {\bf yes} Bacula will prune (remove) Job records
2237 that are older than the specified File Retention period. As with the other
2238 retention periods, this affects only records in the catalog and not data in
2239 your archive backup.
2241 If a Job record is selected for pruning, all associated File and JobMedia
2242 records will also be pruned regardless of the File Retention period set. As a
2243 consequence, you normally will set the File retention period to be less than
2244 the Job retention period. The Job retention period can actually be less than
2245 the value you specify here if you set the {\bf Volume Retention} directive in
2246 the Pool resource to a smaller duration. This is because the Job retention
2247 period and the Volume retention period are independently applied, so the
2248 smaller of the two takes precedence.
2250 The Job retention period is specified as seconds, minutes, hours, days,
2251 weeks, months, quarters, or years. See the
2252 \ilink{ Configuration chapter}{Time} of this manual for
2253 additional details of time specification.
2255 The default is 180 days.
2258 \item [AutoPrune = \lt{}yes|no\gt{}]
2259 \index[fd]{AutoPrune }
2260 If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
2261 will automatically apply the File retention period and the Job retention
2262 period for the Client at the end of the Job. If you set {\bf AutoPrune = no},
2263 pruning will not be done, and your Catalog will grow in size each time you
2264 run a Job. Pruning affects only information in the catalog and not data
2265 stored in the backup archives (on Volumes).
2267 \item [Maximum Concurrent Jobs = \lt{}number\gt{}]
2268 \index[fd]{Maximum Concurrent Jobs }
2269 where \lt{}number\gt{} is the maximum number of Jobs with the current Client
2270 that can run concurrently. Note, this directive limits only Jobs for Clients
2271 with the same name as the resource in which it appears. Any other
2272 restrictions on the maximum concurrent jobs such as in the Director, Job, or
2273 Storage resources will also apply in addition to any limit specified here.
2274 The default is set to 1, but you may set it to a larger number. We strongly
2275 recommend that you read the WARNING documented under
2276 \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
2279 \item [*Priority = \lt{}number\gt{}]
2280 \index[fd]{*Priority }
2281 The number specifies the priority of this client relative to other clients
2282 that the Director is processing simultaneously. The priority can range from
2283 1 to 1000. The clients are ordered such that the smaller number priorities
2284 are performed first (not currently implemented).
2287 The following is an example of a valid Client resource definition:
2295 Password = very_good
2300 \section*{The Storage Resource}
2301 \label{StorageResource2}
2302 \index[general]{Resource!Storage }
2303 \index[general]{Storage Resource }
2304 \addcontentsline{toc}{section}{Storage Resource}
2306 The Storage resource defines which Storage daemons are available for use by
2312 \index[fd]{Storage }
2313 Start of the Storage resources. At least one storage resource must be
2316 \item [Name = \lt{}name\gt{}]
2318 The name of the storage resource. This name appears on the Storage directive
2319 specified in the Job directive and is required.
2321 \item [Address = \lt{}address\gt{}]
2322 \index[sd]{Address }
2323 Where the address is a host name, a {\bf fully qualified domain name}, or an
2324 {\bf IP address}. Please note that the \lt{}address\gt{} as specified here
2325 will be transmitted to the File daemon who will then use it to contact the
2326 Storage daemon. Hence, it is {\bf not}, a good idea to use {\bf localhost} as
2327 the name but rather a fully qualified machine name or an IP address. This
2328 directive is required.
2330 \item [SD Port = \lt{}port\gt{}]
2331 \index[sd]{SD Port }
2332 Where port is the port to use to contact the storage daemon for information
2333 and to start jobs. This same port number must appear in the Storage resource
2334 of the Storage daemon's configuration file. The default is 9103.
2336 \item [Password = \lt{}password\gt{}]
2337 \index[sd]{Password }
2338 This is the password to be used when establishing a connection with the
2339 Storage services. This same password also must appear in the Director
2340 resource of the Storage daemon's configuration file. This directive is
2341 required. If you have either {\bf /dev/random} {\bf bc} on your machine,
2342 Bacula will generate a random password during the configuration process,
2343 otherwise it will be left blank.
2345 \item [Device = \lt{}device-name\gt{}]
2347 This directive specifies the name of the device to be used to for the
2348 storage. This name is not the physical device name, but the logical device
2349 name as defined on the {\bf Name} directive contained in the {\bf Device}
2350 resource definition of the {\bf Storage daemon} configuration file. You can
2351 specify any name you would like (even the device name if you prefer) up to a
2352 maximum of 127 characters in length. The physical device name associated with
2353 this device is specified in the {\bf Storage daemon} configuration file (as
2354 {\bf Archive Device}). Please take care not to define two different Storage
2355 resource directives in the Director that point to the same Device in the
2356 Storage daemon. Doing so may cause the Storage daemon to block (or hang)
2357 attempting to open the same device that is already open. This directive is
2360 \item [Media Type = \lt{}MediaType\gt{}]
2361 \index[fd]{Media Type }
2362 This directive specifies the Media Type to be used to store the data. This is
2363 an arbitrary string of characters up to 127 maximum that you define. It can
2364 be anything you want. However, it is best to make it descriptive of the
2365 storage media (e.g. File, DAT, ''HP DLT8000``, 8mm, ...). In addition, it is
2366 essential that you make the {\bf Media Type} specification unique for each
2367 storage media type. If you have two DDS-4 drives that have incompatible
2368 formats, or if you have a DDS-4 drive and a DDS-4 autochanger, you almost
2369 certainly should specify different {\bf Media Types}. During a restore,
2370 assuming a {\bf DDS-4} Media Type is associated with the Job, Bacula can
2371 decide to use any Storage daemon that support Media Type {\bf DDS-4} and on
2372 any drive supports it. If you want to tie Bacula to using a single Storage
2373 daemon or drive, you must specify a unique Media Type for that drive. This is
2374 an important point that should be carefully understood. You can find more on
2376 \ilink{Basic Volume Management}{_ChapterStart39} chapter of this
2379 The {\bf MediaType} specified here, {\bf must} correspond to the {\bf Media
2380 Type} specified in the {\bf Device} resource of the {\bf Storage daemon}
2381 configuration file. This directive is required, and it is used by the
2382 Director and the Storage daemon to ensure that a Volume automatically
2383 selected from the Pool corresponds to the physical device. If a Storage
2384 daemon handles multiple devices (e.g. will write to various file Volumes on
2385 different partitions), this directive allows you to specify exactly which
2388 As mentioned above, the value specified in the Director's Storage resource
2389 must agree with the value specified in the Device resource in the {\bf
2390 Storage daemon's} configuration file. It is also an additional check so that
2391 you don't try to write data for a DLT onto an 8mm device.
2392 \label{Autochanger1}
2394 \item [Autochanger = \lt{}yes|no\gt{} ]
2395 \index[fd]{Autochanger }
2396 If you specify {\bf yes} for this command (the default is {\bf no}), when you
2397 use the {\bf label} command or the {\bf add} command to create a new Volume,
2398 {\bf Bacula} will also request the Autochanger Slot number. This simplifies
2399 creating database entries for Volumes in an autochanger. If you forget to
2400 specify the Slot, the autochanger will not be used. However, you may modify
2401 the Slot associated with a Volume at any time by using the {\bf update
2402 volume} command in the console program. When {\bf autochanger} is enabled,
2403 the algorithm used by Bacula to search for available volumes will be modified
2404 to consider only Volumes that are known to be in the autochanger's magazine.
2405 If no {\bf in changer} volume is found, Bacula will attempt recycling,
2406 pruning, ..., and if still no volume is found, Bacula will search for any
2407 volume whether or not in the magazine. By privileging in changer volumes,
2408 this procedure minimizes operator intervention. The default is {\bf no}.
2410 For the autochanger to be used, you must also specify {\bf Autochanger = yes}
2412 \ilink{Device Resource}{Autochanger} in the Storage daemon's
2413 configuration file as well as other important Storage daemon configuration
2414 information. Please consult the
2415 \ilink{ Using Autochangers}{_ChapterStart18} manual of this
2416 chapter for the details of using autochangers.
2418 \item [Maximum Concurrent Jobs = \lt{}number\gt{}]
2419 \index[fd]{Maximum Concurrent Jobs }
2420 where \lt{}number\gt{} is the maximum number of Jobs with the current Storage
2421 resource that can run concurrently. Note, this directive limits only Jobs
2422 for Jobs using this Storage daemon. Any other restrictions on the maximum
2423 concurrent jobs such as in the Director, Job, or Client resources will also
2424 apply in addition to any limit specified here. The default is set to 1, but
2425 you may set it to a larger number. We strongly recommend that you read the
2426 WARNING documented under
2427 \ilink{ Maximum Concurrent Jobs}{DirMaxConJobs} in the Director's
2430 While it is possible to set the Director's, Job's, or Client's maximum
2431 concurrent jobs greater than one, you should take great care in setting the
2432 Storage daemon's greater than one. By keeping this directive set to one, you
2433 will avoid having two jobs simultaneously write to the same Volume. Although
2434 this is supported, it is not currently recommended.
2437 The following is an example of a valid Storage resource definition:
2441 # Definition of tape storage device
2445 Password = storage_password # password for Storage daemon
2446 Device = "HP DLT 80" # same as Device in Storage daemon
2447 Media Type = DLT8000 # same as MediaType in Storage daemon
2452 \section*{The Pool Resource}
2453 \label{PoolResource}
2454 \index[general]{Resource!Pool }
2455 \index[general]{Pool Resource }
2456 \addcontentsline{toc}{section}{Pool Resource}
2458 The Pool resource defines the set of storage Volumes (tapes or files) to be
2459 used by Bacula to write the data. By configuring different Pools, you can
2460 determine which set of Volumes (media) receives the backup data. This permits,
2461 for example, to store all full backup data on one set of Volumes and all
2462 incremental backups on another set of Volumes. Alternatively, you could assign
2463 a different set of Volumes to each machine that you backup. This is most
2464 easily done by defining multiple Pools.
2466 Another important aspect of a Pool is that it contains the default attributes
2467 (Maximum Jobs, Retention Period, Recycle flag, ...) that will be given to a
2468 Volume when it is created. This avoids the need for you to answer a large
2469 number of questions when labeling a new Volume. Each of these attributes can
2470 later be changed on a Volume by Volume basis using the {\bf update} command in
2471 the console program. Note that you must explicitly specify which Pool Bacula
2472 is to use with each Job. Bacula will not automatically search for the correct
2475 Most often in Bacula installations all backups for all machines (Clients) go
2476 to a single set of Volumes. In this case, you will probably only use the {\bf
2477 Default} Pool. If your backup strategy calls for you to mount a different tape
2478 each day, you will probably want to define a separate Pool for each day. For
2479 more information on this subject, please see the
2480 \ilink{Backup Strategies}{_ChapterStart3} chapter of this
2483 To use a Pool, there are three distinct steps. First the Pool must be defined
2484 in the Director's configuration file. Then the Pool must be written to the
2485 Catalog database. This is done automatically by the Director each time that it
2486 starts, or alternatively can be done using the {\bf create} command in the
2487 console program. Finally, if you change the Pool definition in the Director's
2488 configuration file and restart Bacula, the pool will be updated alternatively
2489 you can use the {\bf update pool} console command to refresh the database
2490 image. It is this database image rather than the Director's resource image
2491 that is used for the default Volume attributes. Note, for the pool to be
2492 automatically created or updated, it must be explicitly referenced by a Job
2495 Next the physical media must be labeled. The labeling can either be done with
2496 the {\bf label} command in the {\bf console} program or using the {\bf btape}
2497 program. The preferred method is to use the {\bf label} command in the {\bf
2500 Finally, you must add Volume names (and their attributes) to the Pool. For
2501 Volumes to be used by Bacula they must be of the same {\bf Media Type} as the
2502 archive device specified for the job (i.e. if you are going to back up to a
2503 DLT device, the Pool must have DLT volumes defined since 8mm volumes cannot be
2504 mounted on a DLT drive). The {\bf Media Type} has particular importance if you
2505 are backing up to files. When running a Job, you must explicitly specify which
2506 Pool to use. Bacula will then automatically select the next Volume to use from
2507 the Pool, but it will ensure that the {\bf Media Type} of any Volume selected
2508 from the Pool is identical to that required by the Storage resource you have
2509 specified for the Job.
2511 If you use the {\bf label} command in the console program to label the
2512 Volumes, they will automatically be added to the Pool, so this last step is
2513 not normally required.
2515 It is also possible to add Volumes to the database without explicitly labeling
2516 the physical volume. This is done with the {\bf add} console command.
2518 As previously mentioned, each time Bacula starts, it scans all the Pools
2519 associated with each Catalog, and if the database record does not already
2520 exist, it will be created from the Pool Resource definition. {\bf Bacula}
2521 probably should do an {\bf update pool} if you change the Pool definition, but
2522 currently, you must do this manually using the {\bf update pool} command in
2523 the Console program.
2525 The Pool Resource defined in the Director's configuration file
2526 (bacula-dir.conf) may contain the following directives:
2532 Start of the Pool resource. There must be at least one Pool resource defined.
2535 \item [Name = \lt{}name\gt{}]
2537 The name of the pool. For most applications, you will use the default pool
2538 name {\bf Default}. This directive is required.
2540 \item [Number of Volumes = \lt{}number\gt{}]
2541 \index[dir]{Number of Volumes }
2542 This directive specifies the number of volumes (tapes or files) contained in
2543 the pool. Normally, it is defined and updated automatically by the Bacula
2544 catalog handling routines.
2547 \item [Maximum Volumes = \lt{}number\gt{}]
2548 \index[dir]{Maximum Volumes }
2549 This directive specifies the maximum number of volumes (tapes or files)
2550 contained in the pool. This directive is optional, if omitted or set to zero,
2551 any number of volumes will be permitted. In general, this directive is useful
2552 for Autochangers where there is a fixed number of Volumes, or for File
2553 storage where you wish to ensure that the backups made to disk files do not
2554 become too numerous or consume too much space.
2556 \item [Pool Type = \lt{}type\gt{}]
2557 \index[dir]{Pool Type }
2558 This directive defines the pool type, which corresponds to the type of Job
2559 being run. It is required and may be one of the following:
2570 \item [Use Volume Once = \lt{}yes|no\gt{}]
2571 \index[dir]{Use Volume Once }
2572 This directive if set to {\bf yes} specifies that each volume is to be used
2573 only once. This is most useful when the Media is a file and you want a new
2574 file for each backup that is done. The default is {\bf no} (i.e. use volume
2575 any number of times). This directive will most likely be phased out
2576 (deprecated), so you are recommended to use {\bf Maximum Volume Jobs = 1}
2579 Please note that the value defined by this directive in the bacula-dir.conf
2580 file is the default value used when a Volume is created. Once the volume is
2581 created, changing the value in the bacula-dir.conf file will not change what
2582 is stored for the Volume. To change the value for an existing Volume you
2583 must use the {\bf update} command in the Console.
2585 \item [Maximum Volume Jobs = \lt{}positive-integer\gt{}]
2586 \index[fd]{Maximum Volume Jobs }
2587 This directive specifies the maximum number of Jobs that can be written to
2588 the Volume. If you specify zero (the default), there is no limit. Otherwise,
2589 when the number of Jobs backed up to the Volume equals {\bf positive-integer}
2590 the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
2591 can no longer be used for appending Jobs, much like the {\bf Full} status but
2592 it can be recycled if recycling is enabled. By setting {\bf
2593 MaximumVolumeJobs} to one, you get the same effect as setting {\bf
2594 UseVolumeOnce = yes}.
2596 Please note that the value defined by this directive in the bacula-dir.conf
2597 file is the default value used when a Volume is created. Once the volume is
2598 created, changing the value in the bacula-dir.conf file will not change what
2599 is stored for the Volume. To change the value for an existing Volume you
2600 must use the {\bf update} command in the Console.
2602 \item [Maximum Volume Files = \lt{}positive-integer\gt{}]
2603 \index[fd]{Maximum Volume Files }
2604 This directive specifies the maximum number of files that can be written to
2605 the Volume. If you specify zero (the default), there is no limit. Otherwise,
2606 when the number of files written to the Volume equals {\bf positive-integer}
2607 the Volume will be marked {\bf Used}. When the Volume is marked {\bf Used} it
2608 can no longer be used for appending Jobs, much like the {\bf Full} status but
2609 it can be recycled if recycling is enabled. This value is checked and the
2610 {\bf Used} status is set only at the end of a job that writes to the
2613 Please note that the value defined by this directive in the bacula-dir.conf
2614 file is the default value used when a Volume is created. Once the volume is
2615 created, changing the value in the bacula-dir.conf file will not change what
2616 is stored for the Volume. To change the value for an existing Volume you
2617 must use the {\bf update} command in the Console.
2619 \item [Maximum Volume Bytes = \lt{}size\gt{}]
2620 \index[fd]{Maximum Volume Bytes }
2621 This directive specifies the maximum number of bytes that can be written to
2622 the Volume. If you specify zero (the default), there is no limit except the
2623 physical size of the Volume. Otherwise, when the number of bytes written to
2624 the Volume equals {\bf size} the Volume will be marked {\bf Used}. When the
2625 Volume is marked {\bf Used} it can no longer be used for appending Jobs, much
2626 like the {\bf Full} status but it can be recycled if recycling is enabled.
2627 This value is checked and the {\bf Used} status set while the job is writing
2628 to the particular volume.
2630 Please note that the value defined by this directive in the bacula-dir.conf
2631 file is the default value used when a Volume is created. Once the volume is
2632 created, changing the value in the bacula-dir.conf file will not change what
2633 is stored for the Volume. To change the value for an existing Volume you
2634 must use the {\bf update} command in the Console.
2636 \item [Volume Use Duration = \lt{}time-period-specification\gt{}]
2637 \index[fd]{Volume Use Duration }
2638 The Volume Use Duration directive defines the time period that the Volume can
2639 be written beginning from the time of first data write to the Volume. If the
2640 time-period specified is zero (the default), the Volume can be written
2641 indefinitely. Otherwise, when the time period from the first write to the
2642 volume (the first Job written) exceeds the time-period-specification, the
2643 Volume will be marked {\bf Used}, which means that no more Jobs can be
2644 appended to the Volume, but it may be recycled if recycling is enabled.
2646 You might use this directive, for example, if you have a Volume used for
2647 Incremental backups, and Volumes used for Weekly Full backups. Once the Full
2648 backup is done, you will want to use a different Incremental Volume. This can
2649 be accomplished by setting the Volume Use Duration for the Incremental Volume
2650 to six days. I.e. it will be used for the 6 days following a Full save, then
2651 a different Incremental volume will be used.
2653 This value is checked and the {\bf Used} status is set only at the end of a
2654 job that writes to the particular volume, which means that even though the
2655 use duration may have expired, the catalog entry will not be updated until
2656 the next job that uses this volume is run.
2658 Please note that the value defined by this directive in the bacula-dir.conf
2659 file is the default value used when a Volume is created. Once the volume is
2660 created, changing the value in the bacula-dir.conf file will not change what
2661 is stored for the Volume. To change the value for an existing Volume you
2662 must use the {\bf update} command in the Console.
2664 \item [Catalog Files = \lt{}yes|no\gt{}]
2665 \index[fd]{Catalog Files }
2666 This directive defines whether or not you want the names of the files that
2667 were saved to be put into the catalog. The default is {\bf yes}. The
2668 advantage of specifying {\bf Catalog Files = No} is that you will have a
2669 significantly smaller Catalog database. The disadvantage is that you will not
2670 be able to produce a Catalog listing of the files backed up for each Job
2671 (this is often called Browsing). Also, without the File entries in the
2672 catalog, you will not be able to use the Console {\bf restore} command nor
2673 any other command that references File entries.
2674 \label{PoolAutoPrune}
2676 \item [AutoPrune = \lt{}yes|no\gt{}]
2677 \index[fd]{AutoPrune }
2678 If AutoPrune is set to {\bf yes} (default), Bacula (version 1.20 or greater)
2679 will automatically apply the Volume Retention period when new Volume is
2680 needed and no appendable Volumes exist in the Pool. Volume pruning causes
2681 expired Jobs (older than the {\bf Volume Retention} period) to be deleted
2682 from the Catalog and permits possible recycling of the Volume.
2683 \label{VolRetention}
2685 \item [Volume Retention = \lt{}time-period-specification\gt{}]
2686 \index[fd]{Volume Retention }
2687 The Volume Retention directive defines the length of time that {\bf Bacula}
2688 will keep Job records associated with the Volume in the Catalog database.
2689 When this time period expires, and if {\bf AutoPrune} is set to {\bf yes}
2690 Bacula will prune (remove) Job records that are older than the specified
2691 Volume Retention period. All File records associated with pruned Jobs are
2692 also pruned. The time may be specified as seconds, minutes, hours, days,
2693 weeks, months, quarters, or years. The {\bf Volume Retention} applied
2694 independently to the {\bf Job Retention} and the {\bf File Retention} periods
2695 defined in the Client resource. This means that the shorter period is the
2696 one that applies. Note, that when the {\bf Volume Retention} period has been
2697 reached, it will prune both the Job and the File records.
2699 The default is 365 days. Note, this directive sets the default value for each
2700 Volume entry in the Catalog when the Volume is created. The value in the
2701 catalog may be later individually changed for each Volume using the Console
2704 By defining multiple Pools with different Volume Retention periods, you may
2705 effectively have a set of tapes that is recycled weekly, another Pool of
2706 tapes that is recycled monthly and so on. However, one must keep in mind that
2707 if your {\bf Volume Retention} period is too short, it may prune the last
2708 valid Full backup, and hence until the next Full backup is done, you will not
2709 have a complete backup of your system, and in addition, the next Incremental
2710 or Differential backup will be promoted to a Full backup. As a consequence,
2711 the minimum {\bf Volume Retention} period should be at twice the interval of
2712 your Full backups. This means that if you do a Full backup once a month, the
2713 minimum Volume retention period should be two months.
2715 Please note that the value defined by this directive in the bacula-dir.conf
2716 file is the default value used when a Volume is created. Once the volume is
2717 created, changing the value in the bacula-dir.conf file will not change what
2718 is stored for the Volume. To change the value for an existing Volume you
2719 must use the {\bf update} command in the Console.
2722 \item [Recycle = \lt{}yes|no\gt{}]
2723 \index[fd]{Recycle }
2724 This directive specifies the default for recycling Purged Volumes. If it is
2725 set to {\bf yes} and Bacula needs a volume but finds none that are
2726 appendable, it will search for Purged Volumes (i.e. volumes with all the Jobs
2727 and Files expired and thus deleted from the Catalog). If the Volume is
2728 recycled, all previous data written to that Volume will be overwritten.
2730 Please note that the value defined by this directive in the bacula-dir.conf
2731 file is the default value used when a Volume is created. Once the volume is
2732 created, changing the value in the bacula-dir.conf file will not change what
2733 is stored for the Volume. To change the value for an existing Volume you
2734 must use the {\bf update} command in the Console.
2735 \label{RecycleOldest}
2737 \item [Recycle Oldest Volume = \lt{}yes|no\gt{}]
2738 \index[fd]{Recycle Oldest Volume }
2739 This directive instructs the Director to search for the oldest used Volume
2740 in the Pool when another Volume is requested by the Storage daemon and none
2741 are available. The catalog is then {\bf pruned} respecting the retention
2742 periods of all Files and Jobs written to this Volume. If all Jobs are pruned
2743 (i.e. the volume is Purged), then the Volume is recycled and will be used as
2744 the next Volume to be written. This directive respects any Job, File, or
2745 Volume retention periods that you may have specified, and as such it is {\bf
2746 much} better to use this directive than the Purge Oldest Volume.
2748 This directive can be useful if you have a fixed number of Volumes in the
2749 Pool and you want to cycle through them and you have specified the correct
2751 \label{RecycleCurrent}
2753 \item [Recycle Current Volume = \lt{}yes|no\gt{}]
2754 \index[fd]{Recycle Current Volume }
2755 If Bacula needs a new Volume, this directive instructs Bacula to Prune the
2756 volume respecting the Job and File retention periods. If all Jobs are pruned
2757 (i.e. the volume is Purged), then the Volume is recycled and will be used as
2758 the next Volume to be written. This directive respects any Job, File, or
2759 Volume retention periods that you may have specified, and thus it is {\bf
2760 much} better to use it rather than the Purge Oldest Volume directive.
2762 This directive can be useful if you have: a fixed number of Volumes in the
2763 Pool, you want to cycle through them, and you have specified retention
2764 periods that prune Volumes before you have cycled through the Volume in the
2768 \item [Purge Oldest Volume = \lt{}yes|no\gt{}]
2769 \index[fd]{Purge Oldest Volume }
2770 This directive instructs the Director to search for the oldest used Volume
2771 in the Pool when another Volume is requested by the Storage daemon and none
2772 are available. The catalog is then {\bf purged} irrespective of retention
2773 periods of all Files and Jobs written to this Volume. The Volume is then
2774 recycled and will be used as the next Volume to be written. This directive
2775 overrides any Job, File, or Volume retention periods that you may have
2778 This directive can be useful if you have a fixed number of Volumes in the
2779 Pool and you want to cycle through them and when all Volumes are full, but
2780 you don't want to worry about setting proper retention periods. However, by
2781 using this option you risk losing valuable data.
2783 {\bf Please be aware that {\bf Purge Oldest Volume} disregards all retention
2784 periods.} If you have only a single Volume defined and you turn this variable
2785 on, that Volume will always be immediately overwritten when it fills! So at a
2786 minimum, ensure that you have a decent number of Volumes in your Pool before
2787 running any jobs. If you want retention periods to apply do not use this
2788 directive. To specify a retention period, use the {\bf Volume Retention}
2789 directive (see above).
2791 I highly recommend against using this directive, because it is sure that some
2792 day, Bacula will recycle a Volume that contains current data.
2794 \item [Accept Any Volume = \lt{}yes|no\gt{}]
2795 \index[fd]{Accept Any Volume }
2796 This directive specifies whether or not any volume from the Pool may be used
2797 for backup. The default is {\bf yes} as of version 1.27 and later. If it is
2798 {\bf no} then only the first writable volume in the Pool will be accepted for
2799 writing backup data, thus Bacula will fill each Volume sequentially in turn
2800 before using any other appendable volume in the Pool. If this is {\bf no} and
2801 you mount a volume out of order, Bacula will not accept it. If this is {\bf
2802 yes} any appendable volume from the pool mounted will be accepted.
2804 If your tape backup procedure dictates that you manually mount the next
2805 volume, you will almost certainly want to be sure this directive is turned
2808 If you are going on vacation and you think the current volume may not have
2809 enough room on it, you can simply label a new tape and leave it in the drive,
2810 and assuming that {\bf Accept Any Volume} is {\bf yes} Bacula will begin
2811 writing on it. When you return from vacation, simply remount the last tape,
2812 and Bacula will continue writing on it until it is full. Then you can remount
2813 your vacation tape and Bacula will fill it in turn.
2815 \item [Cleaning Prefix = \lt{}string\gt{}]
2816 \index[fd]{Cleaning Prefix }
2817 This directive defines a prefix string, which if it matches the beginning of
2818 a Volume name during labeling of a Volume, the Volume will be defined with
2819 the VolStatus set to {\bf Cleaning} and thus Bacula will never attempt to use
2820 this tape. This is primarily for use with autochangers that accept barcodes
2821 where the convention is that barcodes beginning with {\bf CLN} are treated as
2825 \item [Label Format = \lt{}format\gt{}]
2826 \index[fd]{Label Format }
2827 This directive specifies the format of the labels contained in this pool. The
2828 format directive is used as a sort of template to create new Volume names
2829 during automatic Volume labeling.
2831 The {\bf format} should be specified in double quotes, and consists of
2832 letters, numbers and the special characters hyphen ({\bf -}), underscore
2833 ({\bf \_}), colon ({\bf :}), and period ({\bf .}), which are the legal
2834 characters for a Volume name. The {\bf format} should be enclosed in double
2837 In addition, the format may contain a number of variable expansion characters
2838 which will be expanded by a complex algorithm allowing you to create Volume
2839 names of many different formats. In all cases, the expansion process must
2840 resolve to the set of characters noted above that are legal Volume names.
2841 Generally, these variable expansion characters begin with a dollar sign ({\bf
2842 \$}) or a left bracket ({\bf [}). If you specify variable expansion
2843 characters, you should always enclose the format with double quote characters
2844 ({\bf ``}). For more details on variable expansion, please see the
2845 \ilink{Variable Expansion}{_ChapterStart50} Chapter of this manual.
2847 If no variable expansion characters are found in the string, the Volume name
2848 will be formed from the {\bf format} string appended with the number of
2849 volumes in the pool plus one, which will be edited as four digits with
2850 leading zeros. For example, with a {\bf Label Format = ''File-``}, the first
2851 volumes will be named {\bf File-0001}, {\bf File-0002}, ...
2853 With the exception of Job specific variables, you can test your {\bf
2854 LabelFormat} by using the
2855 \ilink{ var command}{var} the Console Chapter of this manual.
2857 In almost all cases, you should enclose the format specification (part after
2858 the equal sign) in double quotes.
2861 In order for a Pool to be used during a Backup Job, the Pool must have at
2862 least one Volume associated with it. Volumes are created for a Pool using the
2863 {\bf label} or the {\bf add} commands in the {\bf Bacula Console}, program. In
2864 addition to adding Volumes to the Pool (i.e. putting the Volume names in the
2865 Catalog database), the physical Volume must be labeled with valid Bacula
2866 software volume label before {\bf Bacula} will accept the Volume. This will be
2867 automatically done if you use the {\bf label} command. Bacula can
2868 automatically label Volumes if instructed to do so, but this feature is not
2869 yet fully implemented.
2871 The following is an example of a valid Pool resource definition:
2883 \section*{The Catalog Resource}
2884 \label{CatalogResource}
2885 \index[general]{Resource!Catalog }
2886 \index[general]{Catalog Resource }
2887 \addcontentsline{toc}{section}{Catalog Resource}
2889 The Catalog Resource defines what catalog to use for the current job.
2890 Currently, Bacula can only handle a single database server (SQLite, MySQL,
2891 built-in) that is defined when configuring {\bf Bacula}. However, there may be
2892 as many Catalogs (databases) defined as you wish. For example, you may want
2893 each Client to have its own Catalog database, or you may want backup jobs to
2894 use one database and verify or restore jobs to use another database.
2899 \index[console]{Catalog }
2900 Start of the Catalog resource. At least one Catalog resource must be defined.
2903 \item [Name = \lt{}name\gt{}]
2904 \index[console]{Name }
2905 The name of the Catalog. No necessary relation to the database server name.
2906 This name will be specified in the Client resource directive indicating that
2907 all catalog data for that Client is maintained in this Catalog. This
2908 directive is required.
2910 \item [password = \lt{}password\gt{}]
2911 \index[console]{password }
2912 This specifies the password to use when logging into the database. This
2913 directive is required.
2915 \item [DB Name = \lt{}name\gt{}]
2916 \index[console]{DB Name }
2917 This specifies the name of the database. If you use multiple catalogs
2918 (databases), you specify which one here. If you are using an external
2919 database server rather than the internal one, you must specify a name that
2920 is known to the server (i.e. you explicitly created the Bacula tables using
2921 this name. This directive is required.
2923 \item [user = \lt{}user\gt{}]
2924 \index[console]{user }
2925 This specifies what user name to use to log into the database. This directive
2928 \item [DB Socket = \lt{}socket-name\gt{}]
2929 \index[console]{DB Socket }
2930 This is the name of a socket to use on the local host to connect to the
2931 database. This directive is used only by MySQL and is ignored by SQLite.
2932 Normally, if neither {\bf DB Socket} or {\bf DB Address} are specified, MySQL
2933 will use the default socket.
2935 \item [DB Address = \lt{}address\gt{}]
2936 \index[console]{DB Address }
2937 This is the host address of the database server. Normally, you would specify
2938 this instead of {\bf DB Socket} if the database server is on another machine.
2939 In that case, you will also specify {\bf DB Port}. This directive is used
2940 only by MySQL and is ignored by SQLite if provided. This directive is
2943 \item [DB Port = \lt{}port\gt{}]
2944 \index[console]{DB Port }
2945 This defines the port to be used in conjunction with {\bf DB Address} to
2946 access the database if it is on another machine. This directive is used only
2947 by MySQL and is ignored by SQLite if provided. This directive is optional.
2949 \item [Multiple Connections = \lt{}yes|no\gt{}]
2950 \index[console]{Multiple Connections }
2951 By default, this directive is set to no. In that case, each job that uses the
2952 same Catalog will use a single connection to the catalog. It will be shared,
2953 and Bacula will allow only one Job at a time to communicate. If you set this
2954 directive to yes, Bacula will permit multiple connections to the database,
2955 and the database must be multi-thread capable. For SQLite and PostgreSQL,
2956 this is no problem. For MySQL, you must be *very* careful to have the
2957 multi-thread version of the client library loaded on your system. When this
2958 directive is set yes, each Job will have a separate connection to the
2959 database, and the database will control the interaction between the different
2960 Jobs. This can significantly speed up the database operations if you are
2961 running multiple simultaneous jobs. In addition, for SQLite and PostgreSQL,
2962 Bacula will automatically enable transactions. This can significantly speed
2963 up insertion of attributes in the database either for a single Job or
2964 multiple simultaneous Jobs.
2966 This directive has not been tested. Please test carefully before running it
2967 in production and report back your results.
2970 The following is an example of a valid Catalog resource definition:
2979 password = "" # no password = no security
2984 or for a Catalog on another machine:
2994 DB Address = remote.acme.com
3000 \section*{The Messages Resource}
3001 \label{MessagesResource2}
3002 \index[general]{Resource!Messages }
3003 \index[general]{Messages Resource }
3004 \addcontentsline{toc}{section}{Messages Resource}
3006 For the details of the Messages Resource, please see the
3007 \ilink{Messages Resource Chapter}{_ChapterStart15} of this
3010 \section*{The Console Resource}
3011 \label{ConsoleResource1}
3012 \index[general]{Console Resource }
3013 \index[general]{Resource!Console }
3014 \addcontentsline{toc}{section}{Console Resource}
3016 As of Bacula version 1.33 and higher, there are three different kinds of
3017 consoles, which the administrator or user can use to interact with the
3018 Director. These three kinds of consoles comprise three different security
3022 \item The first console type is an {\bf anonymous} or {\bf default} console,
3023 which has full privileges. There is no console resource necessary for this
3024 type since the password is specified in the Director's resource and
3025 consequently such consoles do not have an name as defined on a {\bf Name =}
3026 directive. This is the kind of console that was initially implemented in
3027 versions prior to 1.33 and remains valid. Typically you would use it only for
3029 \item The second type of console, and new to version 1.33 and higher is a
3030 ''named`` console defined within a Console resource in both the Director's
3031 configuration file and in the Console's configuration file. Both the names
3032 and the passwords in these two entries must match much as is the case for
3035 This second type of console begins with absolutely no privileges except those
3036 explicitly specified in the Director's Console resource. Thus you can have
3037 multiple Consoles with different names and passwords, sort of like multiple
3038 users, each with different privileges. As a default, these consoles can do
3039 absolutely nothing -- no commands what so ever. You give them privileges or
3040 rather access to commands and resources by specifying access control lists
3041 in the Director's Console resource. The ACLs are specified by a directive
3042 followed by a list of access names. Examples of this are shown below.
3043 \item The third type of console is similar to the above mentioned one in that
3044 it requires a Console resource definition in both the Director and the
3045 Console. In addition, if the console name, provided on the {\bf Name =}
3046 directive, is the same as a Client name, that console is permitted to use the
3047 {\bf SetIP} command to change the Address directive in the Director's client
3048 resource to the IP address of the Console. This permits portables or other
3049 machines using DHCP (non-fixed IP addresses) to ''notify`` the Director of
3050 their current IP address.
3053 The Console resource is optional and need not be specified. The following
3054 directives are permited within the Director's configuration resource:
3058 \item [Name = \lt{}name\gt{}]
3059 \index[console]{Name }
3060 The name of the console. This name must match the name specified in the
3061 Console's configuration resource (much as is the case with Client
3064 \item [Password = \lt{}password\gt{}]
3065 \index[console]{Password }
3066 Specifies the password that must be supplied for a named Bacula Console to be
3067 authorized. The same password must appear in the {\bf Console} resource of
3068 the Console configuration file. For added security, the password is never
3069 actually passed across the network but rather a challenge response hash code
3070 created with the password. This directive is required. If you have either
3071 {\bf /dev/random} {\bf bc} on your machine, Bacula will generate a random
3072 password during the configuration process, otherwise it will be left blank.
3074 \item [JobACL = \lt{}name-list\gt{}]
3075 \index[console]{JobACL }
3076 This directive is used to specify a list of Job resource names that can be
3077 accessed by the console. Without this directive, the console cannot access
3078 any of the Director's Job resources. Multiple Job resource names may be
3079 specified by separating them with commas, and/or by specifying multiple
3080 JobACL directives. For example, the directive may be specified as:
3084 JobACL = kernsave, "Backup client 1", "Backup client 2"
3085 JobACL = "RestoreFiles"
3090 With the above specification, the console can access the Director's resources
3091 for the four jobs named on the JobACL directives, but for no others.
3093 \item [ClientACL = \lt{}name-list\gt{}]
3094 \index[console]{ClientACL }
3095 This directive is used to specify a list of Client resource names that can be
3096 accessed by the console.
3098 \item [StorageACL = \lt{}name-list\gt{}]
3099 \index[console]{StorageACL }
3100 This directive is used to specify a list of Storage resource names that can
3101 be accessed by the console.
3103 \item [ScheduleACL = \lt{}name-list\gt{}]
3104 \index[console]{ScheduleACL }
3105 This directive is used to specify a list of Schedule resource names that can
3106 be accessed by the console.
3108 \item [PoolACL = \lt{}name-list\gt{}]
3109 \index[console]{PoolACL }
3110 This directive is used to specify a list of Pool resource names that can be
3111 accessed by the console.
3113 \item [FileSetACL = \lt{}name-list\gt{}]
3114 \index[console]{FileSetACL }
3115 This directive is used to specify a list of FileSet resource names that can
3116 be accessed by the console.
3118 \item [CatalogACL = \lt{}name-list\gt{}]
3119 \index[console]{CatalogACL }
3120 This directive is used to specify a list of Catalog resource names that can
3121 be accessed by the console.
3123 \item [CommandACL = \lt{}name-list\gt{}]
3124 \index[console]{CommandACL }
3125 This directive is used to specify a list of of console commands that can be
3126 executed by the console.
3129 Aside from Director resource names and console command names, the special
3130 keyword {\bf *all*} can be specified in any of the above access control lists.
3131 When this keyword is present, any resource or command name (which ever is
3132 appropriate) will be accepted. For an example configuration file, please see
3134 \ilink{Console Configuration}{_ChapterStart36} chapter of this
3137 \section*{The Counter Resource}
3138 \label{CounterResource}
3139 \index[general]{Resource!Counter }
3140 \index[general]{Counter Resource }
3141 \addcontentsline{toc}{section}{Counter Resource}
3143 The Counter Resource defines a counter variable that can be accessed by
3144 variable expansion used for creating Volume labels with the {\bf LabelFormat}
3146 \ilink{LabelFormat}{Label} directive in this chapter for more
3152 \index[console]{Counter }
3153 Start of the Counter resource. Counter directives are optional.
3155 \item [Name = \lt{}name\gt{}]
3156 \index[console]{Name }
3157 The name of the Counter. This is the name you will use in the variable
3158 expansion to reference the counter value.
3160 \item [Minimum = \lt{}integer\gt{}]
3161 \index[console]{Minimum }
3162 This specifies the minimum value that the counter can have. It also becomes
3163 the default. If not supplied, zero is assumed.
3165 \item [Maximum = \lt{}integer\gt{}]
3166 \index[console]{Maximum }
3167 This is the maximum value value that the counter can have. If not specified
3168 or set to zero, the counter can have a maximum value of 2,147,483,648 (2 to
3169 the 31 power). When the counter is incremented past this value, it is reset
3172 \item [*WrapCounter = \lt{}counter-name\gt{}]
3173 \index[console]{*WrapCounter }
3174 If this value is specified, when the counter is incremented past the maximum
3175 and thus reset to the minimum, the counter specified on the {\bf WrapCounter}
3176 is incremented. (This is not currently implemented).
3178 \item [Catalog = \lt{}catalog-name\gt{}]
3179 \index[console]{Catalog }
3180 If this directive is specified, the counter and its values will be saved in
3181 the specified catalog. If this directive is not present, the counter will be
3182 redefined each time that Bacula is started.
3185 \section*{ A Complete Example Director Configuration File}
3186 \label{SampleDirectorConfiguration}
3187 \index[general]{File!Complete Example Director Configuration }
3188 \index[general]{Complete Example Director Configuration File }
3189 \addcontentsline{toc}{section}{Complete Example Director Configuration File}
3191 An example Director configuration file might be the following:
3196 # Default Bacula Director Configuration file
3198 # The only thing that MUST be changed is to add one or more
3199 # file or directory names in the Include directive of the
3202 # For Bacula release 1.15 (5 March 2002) -- redhat
3204 # You might also want to change the default email address
3205 # from root to your address. See the "mail" and "operator"
3206 # directives in the Messages resource.
3208 Director { # define myself
3210 QueryFile = "/home/kern/bacula/bin/query.sql"
3211 WorkingDirectory = "/home/kern/bacula/bin/working"
3212 PidDirectory = "/home/kern/bacula/bin/working"
3213 Password = "XkSfzu/Cf/wX4L8Zh4G4/yhCbpLcz3YVdmVoQvU3EyF/"
3215 # Define the backup Job
3217 Name = "NightlySave"
3219 Level = Incremental # default
3222 Schedule = "WeeklyCycle"
3232 Where = /tmp/bacula-restores
3238 # List of files to be backed up
3242 Options { signature=SHA1 }
3244 # Put your list of files here, one per line or include an
3245 # external list with:
3249 # Note: / backs up everything
3254 # When to do the backups
3256 Name = "WeeklyCycle"
3257 Run = Full sun at 1:05
3258 Run = Incremental mon-sat at 1:05
3260 # Client (File Services) to backup
3265 Password = "MQk6lVinz4GG2hdIZk1dsKE/LxMZGo6znMHiD7t7vzF+"
3266 File Retention = 60d # sixty day file retention
3267 Job Retention = 1y # 1 year Job retention
3268 AutoPrune = yes # Auto apply retention periods
3270 # Definition of DLT tape storage device
3274 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
3275 Device = "HP DLT 80" # same as Device in Storage daemon
3276 Media Type = DLT8000 # same as MediaType in Storage daemon
3278 # Definition of DDS tape storage device
3282 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
3283 Device = SDT-10000 # same as Device in Storage daemon
3284 Media Type = DDS-4 # same as MediaType in Storage daemon
3286 # Definition of 8mm tape storage device
3290 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
3291 Device = "Exabyte 8mm"
3294 # Definition of file storage device
3298 Password = "jMeWZvfikUHvt3kzKVVPpQ0ccmV6emPnF2cPYFdhLApQ"
3299 Device = FileStorage
3302 # Generic catalog service
3305 dbname = bacula; user = bacula; password = ""
3307 # Reasonable message delivery -- send most everything to
3308 # the email address and to the console
3311 mail = root@localhost = all, !skipped, !terminate
3312 operator = root@localhost = mount
3313 console = all, !skipped, !saved
3316 # Default pool definition
3324 # Restricted console used by tray-monitor to get the status of the director
3328 Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR"
3329 CommandACL = status, .status