1 \chapter{Tips and Suggestions}
3 \index[general]{Tips and Suggestions}
4 \index[general]{Suggestions!Tips and}
6 \index[general]{Examples}
8 There are a number of example scripts for various things that can be found in
9 the {\bf example} subdirectory and its subdirectories of the Bacula source
12 For additional tips, please see the \elink{Bacula
13 wiki}{http://wiki.bacula.org}.
15 \section{Upgrading Bacula Versions}
17 \index[general]{Upgrading Bacula Versions}
18 \index[general]{Versions!Upgrading Bacula}
19 \index[general]{Upgrading}
21 The first thing to do before upgrading from one version to another is to
22 ensure that you don't overwrite or delete your production (current) version
23 of Bacula until you have tested that the new version works.
25 If you have installed Bacula into a single directory, this is simple: simply
26 make a copy of your Bacula directory.
28 If you have done a more typical Unix installation where the binaries are
29 placed in one directory and the configuration files are placed in another,
30 then the simplest way is to configure your new Bacula to go into a single
31 file. Alternatively, make copies of all your binaries and especially your
34 Whatever your situation may be (one of the two just described), you should
35 probably start with the {\bf defaultconf} script that can be found in the {\bf
36 examples} subdirectory. Copy this script to the main Bacula directory, modify
37 it as necessary (there should not need to be many modifications), configure
38 Bacula, build it, install it, then stop your production Bacula, copy all the
39 {\bf *.conf} files from your production Bacula directory to the test Bacula
40 directory, start the test version, and run a few test backups. If all seems
41 good, then you can proceed to install the new Bacula in place of or possibly
44 When installing a new Bacula you need not worry about losing the changes you
45 made to your configuration files as the installation process will not
46 overwrite them providing that you do not do a {\bf make uninstall}.
48 If the new version of Bacula requires an upgrade to the database,
49 you can upgrade it with the script {\bf update\_bacula\_tables}, which
50 will be installed in your scripts directory (default {\bf /etc/bacula}),
51 or alternatively, you can find it in the
52 {\bf \lt{}bacula-source\gt{}/src/cats} directory.
54 \section{Getting Notified of Job Completion}
56 \index[general]{Getting Notified of Job Completion}
57 \index[general]{Completion!Getting Notified of Job}
59 One of the first things you should do is to ensure that you are being properly
60 notified of the status of each Job run by Bacula, or at a minimum of each Job
61 that terminates with an error.
63 Until you are completely comfortable with {\bf Bacula}, we recommend that you
64 send an email to yourself for each Job that is run. This is most easily
65 accomplished by adding an email notification address in the {\bf Messages}
66 resource of your Director's configuration file. An email is automatically
67 configured in the default configuration files, but you must ensure that the
68 default {\bf root} address is replaced by your email address.
70 For additional examples of how to configure a Bacula, please take a look at the
71 {\bf .conf} files found in the {\bf examples} sub-directory. We recommend the
72 following configuration (where you change the paths and email address to
73 correspond to your setup). Note, the {\bf mailcommand} and {\bf
74 operatorcommand} should be on a single line. They were split here for
81 mailcommand = "/home/bacula/bin/bsmtp -h localhost
83 -s \"Bacula: %t %e of %c %l\" %r"
84 operatorcommand = "/home/bacula/bin/bsmtp -h localhost
86 -s \"Bacula: Intervention needed for %j\" %r"
87 Mail = your-email-address = all, !skipped, !terminate
88 append = "/home/bacula/bin/log" = all, !skipped, !terminate
89 operator = your-email-address = mount
90 console = all, !skipped, !saved
95 You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
96 mailcommand} and the {\bf operatorcommand} lines point to your {\bf Bacula}
97 binary directory where the {\bf bsmtp} program will be installed. You will
98 also want to ensure that the {\bf your-email-address} is replaced by your
99 email address, and finally, you will also need to ensure that the {\bf
100 /home/bacula/bin/log} points to the file where you want to log all messages.
102 With the above Messages resource, you will be notified by email of every Job
103 that ran, all the output will be appended to the {\bf log} file you specify,
104 all output will be directed to the console program, and all mount messages
105 will be emailed to you. Note, some messages will be sent to multiple
108 The form of the mailcommand is a bit complicated, but it allows you to
109 distinguish whether the Job terminated in error or terminated normally. Please
111 \bsysxrlink{Mail}{mailcommand}{main}{command} in the \mainman{} for the
112 details of the substitution characters used above.
114 Once you are totally comfortable with Bacula as I am, or if you have a large
115 number of nightly Jobs as I do (eight), you will probably want to change the
116 {\bf Mail} command to {\bf Mail On Error} which will generate an email message
117 only if the Job terminates in error. If the Job terminates normally, no email
118 message will be sent, but the output will still be appended to the log file as
119 well as sent to the Console program.
121 \section{Getting Email Notification to Work}
123 \index[general]{Work!Getting Email Notification to}
124 \index[general]{Getting Email Notification to Work}
126 The section above describes how to get email notification of job status.
127 Occasionally, however, users have problems receiving any email at all. In that
128 case, the things to check are the following:
131 \item Ensure that you have a valid email address specified on your {\bf Mail}
132 record in the Director's Messages resource. The email address should be fully
133 qualified. Simply using {\bf root} generally will not work, rather you should
134 use {\bf root@localhost} or better yet your full domain.
135 \item Ensure that you do not have a {\bf Mail} record in the Storage daemon's
136 or File daemon's configuration files. The only record you should have is {\bf
141 director = director-name = all
146 \item If all else fails, try replacing the {\bf mailcommand} with
150 mailcommand = "mail -s test your@domain.com"
154 \item Once the above is working, assuming you want to use {\bf bsmtp}, submit
155 the desired bsmtp command by hand and ensure that the email is delivered,
156 then put that command into {\bf Bacula}. Small differences in things such as
157 the parenthesis around the word Bacula can make a big difference to some
158 bsmtp programs. For example, you might start simply by using:
162 mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r"
168 \section{Getting Notified that Bacula is Running}
169 \label{JobNotification}
170 \index[general]{Running!Getting Notified that Bacula is}
171 \index[general]{Getting Notified that Bacula is Running}
173 If like me, you have setup Bacula so that email is sent only when a Job has
174 errors, as described in the previous section of this chapter, inevitably, one
175 day, something will go wrong and {\bf Bacula} can stall. This could be because
176 Bacula crashes, which is vary rare, or more likely the network has caused {\bf
177 Bacula} to {\bf hang} for some unknown reason.
179 To avoid this, you can use the {\bf RunAfterJob} command in the Job resource
180 to schedule a Job nightly, or weekly that simply emails you a message saying
181 that Bacula is still running. For example, I have setup the following Job in
182 my Director's configuration file:
188 Run = Level=Full sun-sat at 6:05
198 Schedule = "Watchdog"
199 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
207 File Retention = 1day
208 Job Retention = 1 month
214 Where I established a schedule to run the Job nightly. The Job itself is type
215 {\bf Admin} which means that it doesn't actually do anything, and I've defined
216 a FileSet, Pool, Storage, and Client, all of which are not really used (and
217 probably don't need to be specified). The key aspect of this Job is the
222 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
226 which runs my "watchdog" script. As an example, I have added the Job codes
227 \%c and \%d which will cause the Client name and the Director's name to be
228 passed to the script. For example, if the Client's name is {\bf Watchdog} and
229 the Director's name is {\bf main-dir} then referencing \$1 in the script would
230 get {\bf Watchdog} and referencing \$2 would get {\bf main-dir}. In this case,
231 having the script know the Client and Director's name is not really useful,
232 but in other situations it may be.
234 You can put anything in the watchdog script. In my case, I like to monitor the
235 size of my catalog to be sure that {\bf Bacula} is really pruning it. The
236 following is my watchdog script:
241 cd /home/kern/mysql/var/bacula
243 /home/kern/bacula/bin/bsmtp \
244 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
245 -s "Bacula running" abuse@whitehouse.com
249 If you just wish to send yourself a message, you can do it with:
254 cd /home/kern/mysql/var/bacula
255 /home/kern/bacula/bin/bsmtp \
256 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
257 -s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
258 Bacula is still running!!!
263 \section{Maintaining a Valid Bootstrap File}
265 \index[general]{Maintaining a Valid Bootstrap File}
266 \index[general]{File!Maintaining a Valid Bootstrap}
268 By using a \bsysxrlinkdocument{WriteBootstrap}{writebootstrap}{main}{chapter} record in each of your
269 Director's Job resources (\mainman{}), you can constantly maintain a
270 \bsysxrlinkdocument{bootstrap}{BootstrapChapter}{main}{chapter} file that will enable you to
271 recover the state of your system as of the last backup without having the
272 Bacula catalog. This permits you to more easily recover from a disaster that
273 destroys your Bacula catalog.
275 When a Job resource has a {\bf WriteBootstrap} record, Bacula will maintain
276 the designated file (normally on another system but mounted by NFS) with up to
277 date information necessary to restore your system. For example, in my
278 Director's configuration file, I have the following record:
282 Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
286 where I replace {\bf client-name} by the actual name of the client that is
287 being backed up. Thus, Bacula automatically maintains one file for each of my
288 clients. The necessary bootstrap information is appended to this file during
289 each {\bf Incremental} backup, and the file is totally rewritten during each
292 Note, one disadvantage of writing to an NFS mounted volume as I do is
293 that if the other machine goes down, the OS will wait forever on the fopen()
294 call that Bacula makes. As a consequence, Bacula will completely stall until
295 the machine exporting the NFS mounts comes back up. A possible solution to this
296 problem was provided by Andrew Hilborne, and consists of using the {\bf soft}
297 option instead of the {\bf hard} option when mounting the NFS volume, which is
298 typically done in {\bf /etc/fstab}/. The NFS documentation explains these
299 options in detail. However, I found that with the {\bf soft} option
300 NFS disconnected frequently causing even more problems.
302 If you are starting off in the middle of a cycle (i.e. with Incremental
303 backups) rather than at the beginning (with a Full backup), the {\bf
304 bootstrap} file will not be immediately valid as it must always have the
305 information from a Full backup as the first record. If you wish to synchronize
306 your bootstrap file immediately, you can do so by running a {\bf restore}
307 command for the client and selecting a full restore, but when the restore
308 command asks for confirmation to run the restore Job, you simply reply no,
309 then copy the bootstrap file that was written to the location specified on the
310 {\bf Write Bootstrap} record. The restore bootstrap file can be found in {\bf
311 restore.bsr} in the working directory that you defined. In the example given
312 below for the client {\bf rufus}, my input is shown in bold. Note, the JobId
313 output has been partially truncated to fit on the page here:
317 (in the Console program)
319 First you select one or more JobIds that contain files
320 to be restored. You will then be presented several methods
321 of specifying the JobIds. Then you will be allowed to
322 select which files from those JobIds are to be restored.
323 To select the JobIds, you have the following choices:
324 1: List last 20 Jobs run
325 2: List Jobs where a given File is saved
326 3: Enter list of JobIds to select
327 4: Enter SQL list command
328 5: Select the most recent backup for a client
330 Select item: (1-6): 5
331 The defined Client resources are:
335 Select Client (File daemon) resource (1-3): 2
336 The defined FileSet resources are:
338 Item 1 selected automatically.
339 +-------+------+-------+---------+---------+------+-------+------------+
340 | JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime |
341 +-------+------+-------+---------+---------+------+-------+------------+
342 | 2 | F | 84 | ... | test1 | 0 | 1 | 1035645259 |
343 +-------+------+-------+---------+---------+------+-------+------------+
344 You have selected the following JobId: 2
345 Building directory tree for JobId 2 ...
346 The defined Storage resources are:
348 Item 1 selected automatically.
349 You are now entering file selection mode where you add and
350 remove files to be restored. All files are initially added.
351 Enter "done" to leave this mode.
354 84 files selected to restore.
356 JobName: kernsrestore
357 Bootstrap: /home/kern/bacula/working/restore.bsr
358 Where: /tmp/bacula-restores
363 OK to run? (yes/mod/no): no
366 cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr
370 \section{Rejected Volumes After a Crash}
371 \label{RejectedVolumes}
372 \index[general]{Crash!Rejected Volumes After a}
373 \index[general]{Rejected Volumes After a Crash}
375 Bacula keeps a count of the number of files on each Volume in its Catalog
376 database so that before appending to a tape, it can verify that the number of
377 files are correct, and thus prevent overwriting valid data. If the Director or
378 the Storage daemon crashes before the job has completed, the tape will contain
379 one more file than is noted in the Catalog, and the next time you attempt to
380 use the same Volume, Bacula will reject it due to a mismatch between the
381 physical tape (Volume) and the catalog.
383 The easiest solution to this problem is to label a new tape and start fresh.
384 If you wish to continue appending to the current tape, you can do so by using
385 the {\bf update} command in the console program to change the {\bf Volume
386 Files} entry in the catalog. A typical sequence of events would go like the
400 17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
401 Job=kernsave.2003-01-17_16.45.46
402 17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
403 moving to end of data.
404 17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error:
405 I cannot write on this volume because:
406 The number of files mismatch! Volume=11 Catalog=10
407 17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting.
408 Cannot find any appendable volumes.
409 Please use the "label" command to create a new Volume for:
416 (note, lines wrapped for presentation)
417 The key here is the line that reads:
421 The number of files mismatch! Volume=11 Catalog=10
425 It says that Bacula found eleven files on the volume, but that the catalog
426 says there should be ten. When you see this, you can be reasonably sure that
427 the SD was interrupted while writing before it had a chance to update the
428 catalog. As a consequence, you can just modify the catalog count to eleven,
429 and even if the catalog contains references to files saved in file 11,
430 everything will be OK and nothing will be lost. Note that if the SD had
431 written several file marks to the volume, the difference between the Volume
432 count and the Catalog count could be larger than one, but this is unusual.
434 If on the other hand the catalog is marked as having more files than Bacula
435 found on the tape, you need to consider the possible negative consequences of
436 modifying the catalog. Please see below for a more complete discussion of
439 Continuing with the example of {\bf Volume = 11 Catalog = 10}, to enable to
440 Bacula to append to the tape, you do the following:
447 2: Pool from resource
448 3: Slots from autochanger
449 Choose catalog item to update (1-3): 1
453 Select the Pool (1-2):
454 +-------+---------+--------+---------+-----------+------+----------+------+-----+
455 | MedId | VolName | MedTyp | VolStat | VolBytes | Last | VolReten | Recy | Slt |
456 +-------+---------+--------+---------+-----------+------+----------+------+-----+
457 | 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 |
458 +-------+---------+--------+---------+-----------+------+----------+------+-----+
459 Enter MediaId or Volume name: 1
463 (note table output truncated for presentation) First, you chose to update the
464 Volume parameters by entering a {\bf 1}. In the volume listing that follows,
465 notice how the VolStatus is {\bf Error}. We will correct that after changing
466 the Volume Files. Continuing, you respond 1,
470 Updating Volume "test01"
471 Parameters to modify:
473 2: Volume Retention Period
474 3: Volume Use Duration
475 4: Maximum Volume Jobs
476 5: Maximum Volume Files
477 6: Maximum Volume Bytes
483 Select parameter to modify (1-11): 9
484 Warning changing Volume Files can result
485 in loss of data on your Volume
486 Current Volume Files is: 10
487 Enter new number of Files for Volume: 11
488 New Volume Files is: 11
489 Updating Volume "test01"
490 Parameters to modify:
492 2: Volume Retention Period
493 3: Volume Use Duration
494 4: Maximum Volume Jobs
495 5: Maximum Volume Files
496 6: Maximum Volume Bytes
502 Select parameter to modify (1-10): 1
506 Here, you have selected {\bf 9} in order to update the Volume Files, then you
507 changed it from {\bf 10} to {\bf 11}, and you now answer {\bf 1} to change the
512 Current Volume status is: Error
520 Choose new Volume Status (1-6): 1
521 New Volume status is: Append
522 Updating Volume "test01"
523 Parameters to modify:
525 2: Volume Retention Period
526 3: Volume Use Duration
527 4: Maximum Volume Jobs
528 5: Maximum Volume Files
529 6: Maximum Volume Bytes
535 Select parameter to modify (1-11): 11
540 At this point, you have changed the Volume Files from {\bf 10} to {\bf 11} to
541 account for the last file that was written but not updated in the database,
542 and you changed the Volume Status back to {\bf Append}.
544 This was a lot of words to describe something quite simple.
546 The {\bf Volume Files} option exists only in version 1.29 and later, and you
547 should be careful using it. Generally, if you set the value to that which
548 Bacula said is on the tape, you will be OK, especially if the value is one
549 more than what is in the catalog.
551 Now lets consider the case:
555 The number of files mismatch! Volume=10 Catalog=12
559 Here the Bacula found fewer files on the volume than what is marked in the
560 catalog. Now, in this case, you should hesitate a lot before modifying the count
561 in the catalog, because if you force the catalog from 12 to 10, Bacula will
562 start writing after the file 10 on the tape, possibly overwriting valid data,
563 and if you ever try to restore any of the files that the catalog has marked as
564 saved on Files 11 and 12, all chaos will break out. In this case, you will
565 probably be better off using a new tape. In fact, you might want to see what
566 files the catalog claims are actually stored on that Volume, and back them up
567 to another tape and recycle this tape.
569 \section{Security Considerations}
571 \index[general]{Considerations!Security}
572 \index[general]{Security Considerations}
574 Only the File daemon needs to run with root permission (so that it can access
575 all files). As a consequence, you may run your Director, Storage daemon, and
576 MySQL or PostgreSQL database server as non-root processes. Version 1.30 has
577 the {\bf -u} and the {\bf -g} options that allow you to specify a userid and
578 groupid on the command line to be used after Bacula starts.
580 As of version 1.33, thanks to Dan Langille, it is easier to configure the
581 Bacula Director and Storage daemon to run as non-root.
583 You should protect the Bacula port addresses (normally 9101, 9102, and 9103)
584 from outside access by a firewall or other means of protection to prevent
585 unauthorized use of your daemons.
587 You should ensure that the configuration files are not world readable since
588 they contain passwords that allow access to the daemons. Anyone who can access
589 the Director using a console program can restore any file from a backup
592 You should protect your Catalog database. If you are using SQLite, make sure
593 that the working directory is readable only by root (or your Bacula userid),
594 and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb:--:r\verb:--:} (i.e. 640) or
595 more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
596 setup procedure leaves the database open to anyone. At a minimum, you should
597 assign the user {\bf bacula} a userid and add it to your Director's
598 configuration file in the appropriate Catalog resource.
600 If you use the make\_catalog\_backup script provided by Bacula, remember that
601 you should take care when supplying passwords on the command line. Read the
602 \ilink{Backing Up Your Bacula
603 Database - Security Considerations}{BackingUpBaculaSecurityConsiderations}
604 section for more information.
606 \section{Creating Holiday Schedules}
608 \index[general]{Schedules!Creating Holiday}
609 \index[general]{Creating Holiday Schedules}
611 If you normally change tapes every day or at least every Friday, but Thursday
612 is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no
613 job runs on Thursday so that you can insert Friday's tape and be sure it will
614 be used on Friday. To do so, define a {\bf RunJobBefore} script that normally
615 returns zero, so that the Bacula job will normally continue. You can then
616 modify the script to return non-zero on any day when you do not want Bacula to
619 \section{Automatic Labeling Using Your Autochanger}
621 \index[general]{Automatic Labeling Using Your Autochanger}
622 \index[general]{Autochanger!Automatic Labeling Using Your}
624 If you have an autochanger but it does not support barcodes, using a "trick"
625 you can make Bacula automatically label all the volumes in your autochanger's
628 First create a file containing one line for each slot in your autochanger that
629 has a tape to be labeled. The line will contain the slot number a colon (:)
630 then the Volume name you want to use. For example, create a file named {\bf
631 volume-list}, which contains:
641 The records do not need to be in any order and you don't need to mention all
642 the slots. Normally, you will have a consistent set of Volume names and a
643 sequential set of numbers for each slot you want labeled. In the example
644 above, I've left out slots 3 and 4 just as an example. Now, modify your {\bf
645 mtx-changer} script and comment out all the lines in the {\bf list)} case by
646 putting a \# in column 1. Then add the following two lines:
650 cat <absolute-path>/volume-list
655 so that the whole case looks like:
661 # commented out lines
662 cat <absolute-path>/volume-list
668 where you replace \lt{}absolute-path\gt{} with the full path to the
669 volume-list file. Then using the console, you enter the following command:
677 and Bacula will proceed to mount the autochanger Volumes in the list and label
678 them with the Volume names you have supplied. Bacula will think that the list
679 was provided by the autochanger barcodes, but in reality, it was you who
680 supplied the \lt{}barcodes\gt{}.
682 If it seems to work, when it finishes, enter:
690 and you should see all the volumes nicely created.
692 \section{Backing Up Portables Using DHCP}
694 \index[general]{DHCP!Backing Up Portables Using}
695 \index[general]{Backing Up Portables Using DHCP}
697 You may want to backup laptops or portables that are not always connected to
698 the network. If you are using DHCP to assign an IP address to those machines
699 when they connect, you will need to use the Dynamic Update capability of DNS
700 to assign a name to those machines that can be used in the Address field of
701 the Client resource in the Director's conf file.
703 \section{Going on Vacation}
705 \index[general]{Vacation!Going on}
706 \index[general]{Going on Vacation}
708 At some point, you may want to be absent for a week or two and you want to
709 make sure Bacula has enough tape left so that the backups will complete. You
710 start by doing a {\bf list volumes} in the Console program:
716 Using default Catalog name=BackupDB DB=bacula
718 +---------+---------------+-----------+-----------+----------------+-
719 | MediaId | VolumeName | MediaType | VolStatus | VolBytes |
720 +---------+---------------+-----------+-----------+----------------+-
721 | 23 | DLT-30Nov02 | DLT8000 | Full | 54,739,278,128 |
722 | 24 | DLT-21Dec02 | DLT8000 | Full | 56,331,524,629 |
723 | 25 | DLT-11Jan03 | DLT8000 | Full | 67,863,514,895 |
724 | 26 | DLT-02Feb03 | DLT8000 | Full | 63,439,314,216 |
725 | 27 | DLT-03Mar03 | DLT8000 | Full | 66,022,754,598 |
726 | 28 | DLT-04Apr03 | DLT8000 | Full | 60,792,559,924 |
727 | 29 | DLT-28Apr03 | DLT8000 | Full | 62,072,494,063 |
728 | 30 | DLT-17May03 | DLT8000 | Full | 65,901,767,839 |
729 | 31 | DLT-07Jun03 | DLT8000 | Used | 56,558,490,015 |
730 | 32 | DLT-28Jun03 | DLT8000 | Full | 64,274,871,265 |
731 | 33 | DLT-19Jul03 | DLT8000 | Full | 64,648,749,480 |
732 | 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 |
733 | 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 |
734 +---------+---------------+-----------+-----------+----------------+
738 Note, I have truncated the output for presentation purposes. What is
739 significant, is that I can see that my current tape has almost 10 Gbytes of
740 data, and that the average amount of data I get on my tapes is about 60
741 Gbytes. So if I go on vacation now, I don't need to worry about tape capacity
742 (at least not for short absences).
744 Equally significant is the fact that I did go on vacation the 28th of June
745 2003, and when I did the {\bf list volumes} command, my current tape at that
746 time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the
747 tape would fill shortly. Consequently, I manually marked it as {\bf Used} and
748 replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring
749 myself that the backups would all complete without my intervention.
751 \section{Exclude Files on Windows Regardless of Case}
753 \index[general]{Exclude Files on Windows Regardless of Case}
754 % TODO: should this be put in the win32 chapter?
755 % TODO: should all these tips be placed in other chapters?
757 This tip was submitted by Marc Brueckner who wasn't sure of the case of some
758 of his files on Win32, which is case insensitive. The problem is that Bacula
759 thinks that {\bf /UNIMPORTANT FILES} is different from {\bf /Unimportant
760 Files}. Marc was aware that the file exclusion permits wild-cards. So, he
765 "/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
769 As a consequence, the above exclude works for files of any case.
771 Please note that this works only in Bacula Exclude statement and not in
774 \section{Executing Scripts on a Remote Machine}
775 \label{RemoteExecution}
776 \index[general]{Machine!Executing Scripts on a Remote}
777 \index[general]{Executing Scripts on a Remote Machine}
779 This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
780 by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
781 records, but the technique still could be useful.) First I thought the "Run
782 Before Job" statement in the Job-resource is for executing a script on the
783 remote machine (the machine to be backed up). (Note, this is possible as mentioned
784 above by using {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob}).
785 It could be useful to execute
786 scripts on the remote machine e.g. for stopping databases or other services
787 while doing the backup. (Of course I have to start the services again when the
788 backup has finished) I found the following solution: Bacula could execute
789 scripts on the remote machine by using ssh. The authentication is done
790 automatically using a private key. First you have to generate a keypair. I've
795 ssh-keygen -b 4096 -t dsa -f Bacula_key
799 This statement may take a little time to run. It creates a public/private key
800 pair with no passphrase. You could save the keys in /etc/bacula. Now you have
801 two new files : Bacula\_key which contains the private key and Bacula\_key.pub
802 which contains the public key.
804 Now you have to append the Bacula\_key.pub file to the file authorized\_keys
805 in the \textbackslash{}root\textbackslash{}.ssh directory of the remote
806 machine. Then you have to add (or uncomment) the line
810 AuthorizedKeysFile %h/.ssh/authorized_keys
814 to the sshd\_config file on the remote machine. Where the \%h stands for the
815 home-directory of the user (root in this case).
817 Assuming that your sshd is already running on the remote machine, you can now
818 enter the following on the machine where Bacula runs:
822 ssh -i Bacula_key -l root <machine-name-or-ip-address> "ls -la"
826 This should execute the "ls -la" command on the remote machine.
828 Now you could add lines like the following to your Director's conf file:
833 Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
834 "/etc/init.d/database stop"
835 Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
836 "/etc/init.d/database start"
841 Even though Bacula version 1.32 and later has a ClientRunBeforeJob, the ssh method still
842 could be useful for updating all the Bacula clients on several remote machines
845 \section{Recycling All Your Volumes}
847 \index[general]{Recycling All Your Volumes}
848 \index[general]{Volumes!Recycling All Your}
850 This tip comes from Phil Stracchino.
852 If you decide to blow away your catalog and start over, the simplest way to
853 re-add all your prelabeled tapes with a minimum of fuss (provided you don't
854 care about the data on the tapes) is to add the tape labels using the console
855 {\bf add} command, then go into the catalog and manually set the VolStatus of
856 every tape to {\bf Recycle}.
858 The SQL command to do this is very simple, either use your vendor's
859 command line interface (mysql, postgres, sqlite, ...) or use the sql
860 command in the Bacula console:
864 update Media set VolStatus='Recycle';
868 Bacula will then ignore the data already stored on the tapes and just re-use
869 each tape without further objection.
871 \section{Backing up ACLs on ext3 or XFS filesystems}
873 \index[general]{Filesystems!Backing up ACLs on ext3 or XFS}
874 \index[general]{Backing up ACLs on ext3 or XFS filesystems}
876 This tip comes from Volker Sauer.
878 Note, this tip was given prior to implementation of ACLs in Bacula (version
879 1.34.5). It is left here because dumping/displaying ACLs can still be useful
880 in testing/verifying that Bacula is backing up and restoring your ACLs
881 properly. Please see the
882 \ilink{aclsupport}{ACLSupport} FileSet option in the
883 configuration chapter of this manual.
885 For example, you could dump the ACLs to a file with a script similar to the
891 BACKUP_DIRS="/foo /bar"
892 STORE_ACL=/root/acl-backup
894 for i in $BACKUP_DIRS; do
895 cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_}
900 Then use Bacula to backup {\bf /root/acl-backup}.
902 The ACLs could be restored using Bacula to the {\bf /root/acl-backup} file,
903 then restored to your system using:
907 setfacl --restore/root/acl-backup
911 \section{Total Automation of Bacula Tape Handling}
913 \index[general]{Handling!Total Automation of Bacula Tape}
914 \index[general]{Total Automation of Bacula Tape Handling}
916 This tip was provided by Alexander Kuehn.
918 \elink{Bacula}{http://www.bacula.org/} is a really nice backup program except
919 that the manual tape changing requires user interaction with the bacula
922 Fortunately I can fix this.
923 NOTE!!! This suggestion applies for people who do *NOT* have tape autochangers
924 and must change tapes manually.!!!!!
926 Bacula supports a variety of tape changers through the use of mtx-changer
927 scripts/programs. This highly flexible approach allowed me to create
928 \elink{this shell script}{http://www.bacula.org/en/rel-manual/mtx-changer.txt} which does the following:
929 % TODO: We need to include this in book appendix and point to it.
931 Whenever a new tape is required it sends a mail to the operator to insert the
932 new tape. Then it waits until a tape has been inserted, sends a mail again to
933 say thank you and let's bacula continue its backup.
934 So you can schedule and run backups without ever having to log on or see the
936 To make the whole thing work you need to create a Device resource which looks
937 something like this ("Archive Device", "Maximum Changer Wait", "Media
938 Type" and "Label media" may have different values):
944 Archive Device = # use yours not mine! ;)/dev/nsa0
945 Changer Device = # not really required/dev/nsa0
946 Changer Command = "# use this (maybe change the path)!
947 /usr/local/bin/mtx-changer %o %a %S"
948 Maximum Changer Wait = 3d # 3 days in seconds
949 AutomaticMount = yes; # mount on start
950 AlwaysOpen = yes; # keep device locked
951 Media Type = DDS3 # it's just a name
952 RemovableMedia = yes; #
953 Offline On Unmount = Yes; # keep this too
959 As the script has to emulate the complete wisdom of a mtx-changer it has an
960 internal "database" containing where which tape is stored, you can see this on
965 labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006
966 VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012"
970 The above should be all on one line, and it effectively tells Bacula that
971 volume "VOL-0001" is located in slot 1 (which is our lowest slot), that
972 volume "VOL-0002" is located in slot 2 and so on..
973 The script also maintains a logfile (/var/log/mtx.log) where you can monitor
976 \section{Running Concurrent Jobs}
977 \label{ConcurrentJobs}
978 \index[general]{Jobs!Running Concurrent}
979 \index[general]{Running Concurrent Jobs}
980 \index[general]{Concurrent Jobs}
982 Bacula can run multiple concurrent jobs, but the default configuration files
983 do not enable it. Using the {\bf Maximum Concurrent Jobs} directive, you
984 can configure how many and which jobs can be run simultaneously.
985 The Director's default value for {\bf Maximum Concurrent Jobs} is "1".
987 To initially setup concurrent jobs you need to define {\bf Maximum Concurrent Jobs} in
988 the Director's configuration file (bacula-dir.conf) in the
989 Director, Job, Client, and Storage resources.
991 Additionally the File daemon, and the Storage daemon each have their own
992 {\bf Maximum Concurrent Jobs} directive that sets the overall maximum
993 number of concurrent jobs the daemon will run. The default for both the
994 File daemon and the Storage daemon is "20".
996 For example, if you want two different jobs to run simultaneously backing up
997 the same Client to the same Storage device, they will run concurrently only if
998 you have set {\bf Maximum Concurrent Jobs} greater than one in the Director
999 resource, the Client resource, and the Storage resource in bacula-dir.conf.
1001 We recommend that you read the \ilink{Data
1002 Spooling}{SpoolingChapter} of this manual first, then test your multiple
1003 concurrent backup including restore testing before you put it into
1006 Below is a super stripped down bacula-dir.conf file showing you the four
1007 places where the the file must be modified to allow the same job {\bf
1008 NightlySave} to run up to four times concurrently. The change to the Job
1009 resource is not necessary if you want different Jobs to run at the same time,
1010 which is the normal case.
1015 # Bacula Director Configuration file -- bacula-dir.conf
1019 Maximum Concurrent Jobs = 4
1023 Name = "NightlySave"
1024 Maximum Concurrent Jobs = 4
1031 Maximum Concurrent Jobs = 4
1036 Maximum Concurrent Jobs = 4