4 \section*{Tips and Suggestions}
6 \index[general]{Tips and Suggestions }
7 \index[general]{Suggestions!Tips and }
8 \addcontentsline{toc}{section}{Tips and Suggestions}
10 \subsection*{Examples}
12 \index[general]{Examples }
13 \addcontentsline{toc}{subsection}{Examples}
15 There are a number of example scripts for various things that can be found in
16 the {\bf example} subdirectory and its subdirectories of the Bacula source
19 \subsection*{Upgrading Bacula Versions}
21 \index[general]{Upgrading Bacula Versions }
22 \index[general]{Versions!Upgrading Bacula }
23 \addcontentsline{toc}{subsection}{Upgrading Bacula Versions}
25 The first thing to do before upgrading from one version to another is to
26 ensure that don't overwrite or delete your production (current) version of Bacula until
27 you have tested that the new version works.
29 If you have installed Bacula into a single directory, this is simple: simply
30 make a copy of your Bacula directory.
32 If you have done a more typical Unix installation where the binaries are
33 placed in one directory and the configuration files are placed in another,
34 then the simplest way is to configure your new Bacula to go into a single
35 file. Alternatively, make copies of all your binaries and especially your
38 Whatever your situation may be (one of the two just described), you should
39 probably start with the {\bf defaultconf} script that can be found in the {\bf
40 examples} subdirectory. Copy this script to the main Bacula directory, modify
41 it as necessary (there should not need to be many modifications), configure
42 Bacula, build it, install it, then stop your production Bacula, copy all the
43 {\bf *.conf} files from your production Bacula directory to the test Bacula
44 directory, start the test version, and run a few test backups. If all seems
45 good, then you can proceed to install the new Bacula in place of or possibly
48 When installing a new Bacula you need not worry about losing the changes you
49 made to your configuration files as the installation process will not
50 overwrite them providing that you do not do a {\bf make uninstall}.
52 \subsection*{Getting Notified of Job Completion}
54 \index[general]{Getting Notified of Job Completion }
55 \index[general]{Completion!Getting Notified of Job }
56 \addcontentsline{toc}{subsection}{Getting Notified of Job Completion}
58 One of the first things you should do is to ensure that you are being properly
59 notified of the status of each Job run by Bacula, or at a minimum of each Job
60 that terminates with an error.
62 Until you are completely comfortable with {\bf Bacula}, we recommend that you
63 send an email to yourself for each Job that is run. This is most easily
64 accomplished by adding an email notification address in the {\bf Messages}
65 resource of your Director's configuration file. An email is automatically
66 configured in the default configuration files, but you must ensure that the
67 default {\bf root} address is replaced by your email address.
69 For examples of how I (Kern) configure my system, please take a look at the
70 {\bf .conf} files found in the {\bf examples} sub-directory. We recommend the
71 following configuration (where you change the paths and email address to
72 correspond to your setup). Note, the {\bf mailcommand} and {\bf
73 operatorcommand} should be on a single line. They were split here for
80 mailcommand = "/home/bacula/bin/bsmtp -h localhost
82 -s \"Bacula: %t %e of %c %l\" %r"
83 operatorcommand = "/home/bacula/bin/bsmtp -h localhost
85 -s \"Bacula: Intervention needed for %j\" %r"
86 Mail = your-email-address = all, !skipped, !terminate
87 append = "/home/bacula/bin/log" = all, !skipped, !terminate
88 operator = your-email-address = mount
89 console = all, !skipped, !saved
94 You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
95 mailcommand} and the {\bf operatorcommand} lines points to your {\bf Bacula}
96 binary directory where the {\bf bsmtp} program will be installed. You will
97 also want to ensure that the {\bf your-email-address} is replaced by your
98 email address, and finally, you will also need to ensure that the {\bf
99 /home/bacula/bin/log} points to the file where you want to log all messages.
101 With the above Messages resource, you will be notified by email of every Job
102 that ran, all the output will be appended to the {\bf log} file you specify,
103 all output will be directed to the console program, and all mount messages
104 will be emailed to you. Note, some messages will be sent to multiple
107 The form of the mailcommand is a bit complicated, but it allows you to
108 distinguish whether the Job terminated in error or terminated normally. Please
110 \ilink{Mail Command}{mailcommand} section of the Messages
111 Resource chapter of this manual for the details of the substitution characters
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 \subsection*{Getting Email Notification to Work}
123 \index[general]{Work!Getting Email Notification to }
124 \index[general]{Getting Email Notification to Work }
125 \addcontentsline{toc}{subsection}{Getting Email Notification to Work}
127 The section above describes how to get email notification of job status.
128 Occasionally, however, users have problems receiving any email at all. In that
129 case, the things to check are the following:
132 \item Ensure that you have a valid email address specified on your {\bf Mail}
133 record in the Director's Messages resource. The email address should be fully
134 qualified. Simply using {\bf root} generally will not work, rather you should
135 use {\bf root@localhost} or better yet your full domain.
136 \item Ensure that you do not have a {\bf Mail} record in the Storage daemon's
137 or File daemon's configuration files. The only record you should have is {\bf
142 director = director-name = all
147 \item If all else fails, try replacing the {\bf mailcommand} with
151 mailcommand = "mail -s test your@domain.com"
155 \item Once the above is working, assuming you want to use {\bf bsmtp}, submit
156 the desired bsmtp command by hand and ensure that the email is delivered,
157 then put that command into {\bf Bacula}. Small differences in things such as
158 the parenthesis around the word Bacula can make a big difference to some
159 bsmtp programs. For example, you might start simply by using:
163 mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r"
169 \subsection*{Getting Notified that Bacula is Running}
170 \label{JobNotification}
171 \index[general]{Running!Getting Notified that Bacula is }
172 \index[general]{Getting Notified that Bacula is Running }
173 \addcontentsline{toc}{subsection}{Getting Notified that Bacula is Running}
175 If like me, you have setup Bacula so that email is sent only when a Job has
176 errors, as described in the previous section of this chapter, inevitably, one
177 day, something will go wrong and {\bf Bacula} can stall. This could be because
178 Bacula crashes, which is vary rare, or more likely the network has caused {\bf
179 Bacula} to {\bf hang} for some unknown reason.
181 To avoid this, you can use the {\bf RunAfterJob} command in the Job resource
182 to schedule a Job nightly, or weekly that simply emails you a message saying
183 that Bacula is still running. For example, I have setup the following Job in
184 my Director's configuration file:
190 Run = Level=Full sun-sat at 6:05
200 Schedule = "Watchdog"
201 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
209 File Retention = 1day
210 Job Retention = 1 month
216 Where I established a schedule to run the Job nightly. The Job itself is type
217 {\bf Admin} which means that it doesn't actually do anything, and I've defined
218 a FileSet, Pool, Storage, and Client, all of which are not really used (and
219 probably don't need to be specified). The key aspect of this Job is the
224 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
228 which runs my ``watchdog'' script. As an example, I have added the Job codes
229 \%c and \%d which will cause the Client name and the Director's name to be
230 passed to the script. For example, if the Client's name is {\bf Watchdog} and
231 the Director's name is {\bf main-dir} then referencing \$1 in the script would
232 get {\bf Watchdog} and referencing \$2 would get {\bf main-dir}. In this case,
233 having the script know the Client and Director's name is not really useful,
234 but in other situations it may be.
236 You can put anything in the watchdog scrip. In my case, I like to monitor the
237 size of my catalog to be sure that {\bf Bacula} is really pruning it. The
238 following is my watchdog script:
243 cd /home/kern/mysql/var/bacula
245 /home/kern/bacula/bin/bsmtp \
246 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
247 -s "Bacula running" abuse@whitehouse.com
251 If you just wish to send yourself a message, you can do it with:
256 cd /home/kern/mysql/var/bacula
257 /home/kern/bacula/bin/bsmtp \
258 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
259 -s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
260 Bacula is still running!!!
265 \subsection*{Maintaining a Valid Bootstrap File}
267 \index[general]{Maintaining a Valid Bootstrap File }
268 \index[general]{File!Maintaining a Valid Bootstrap }
269 \addcontentsline{toc}{subsection}{Maintaining a Valid Bootstrap File}
272 \ilink{ WriteBootstrap}{writebootstrap} record in each of your
273 Director's Job resources, you can constantly maintain a
274 \ilink{bootstrap}{_ChapterStart43} file that will enable you to
275 recover the state of your system as of the last backup without having the
276 Bacula catalog. This permits you to more easily recover from a disaster that
277 destroys your Bacula catalog.
279 When a Job resource has a {\bf WriteBootstrap} record, Bacula will maintain
280 the designated file (normally on another system but mounted by NSF) with up to
281 date information necessary to restore your system. For example, in my
282 Director's configuration file, I have the following record:
286 Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
290 where I replace {\bf client-name} by the actual name of the client that is
291 being backed up. Thus, Bacula automatically maintains one file for each of my
292 clients. The necessary bootstrap information is appended to this file during
293 each {\bf Incremental} backup, and the file is totally rewritten during each
296 Note, one disadvantage of writing to an NFS mounted volume as I do is
297 that if the other machine goes down, the OS will wait forever on the fopen()
298 call that Bacula makes. As a consequence, Bacula will completely stall until
299 the machine exporting the NSF mounts comes back up. A possible solution to this
300 problem was provided by Andrew Hilborne, and consists of using the {\bf soft}
301 option instead of the {\bf hard} option when mounting the NFS volume, which is
302 typically done in {\bf /etc/fstab}/. The NFS documentation explains these
303 options in detail. However, I found that with the {\bf soft} option
304 NFS disconnected frequently causing even more problems.
306 If you are starting off in the middle of a cycle (i.e. with Incremental
307 backups) rather than at the beginning (with a Full backup), the {\bf
308 bootstrap} file will not be immediately valid as it must always have the
309 information from a Full backup as the first record. If you wish to synchronize
310 your bootstrap file immediately, you can do so by running a {\bf restore}
311 command for the client and selecting a full restore, but when the restore
312 command asks for confirmation to run the restore Job, you simply reply no,
313 then copy the bootstrap file that was written to the location specified on the
314 {\bf Write Bootstrap} record. The restore bootstrap file can be found in {\bf
315 restore.bsr} in the working directory that you defined. In the example given
316 below for the client {\bf rufus}, my input is shown in bold. Note, the JobId
317 output has been partially truncated to fit on the page here:
321 (in the Console program)
323 First you select one or more JobIds that contain files
324 to be restored. You will then be presented several methods
325 of specifying the JobIds. Then you will be allowed to
326 select which files from those JobIds are to be restored.
327 To select the JobIds, you have the following choices:
328 1: List last 20 Jobs run
329 2: List Jobs where a given File is saved
330 3: Enter list of JobIds to select
331 4: Enter SQL list command
332 5: Select the most recent backup for a client
334 Select item: (1-6): {\bf 5}
335 The defined Client resources are:
339 Select Client (File daemon) resource (1-3): {\bf 2}
340 The defined FileSet resources are:
342 Item 1 selected automatically.
343 +-------+------+-------+---------+---------+------+-------+------------+
344 | JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime |
345 +-------+------+-------+---------+---------+------+-------+------------+
346 | 2 | F | 84 | ... | test1 | 0 | 1 | 1035645259 |
347 +-------+------+-------+---------+---------+------+-------+------------+
348 You have selected the following JobId: 2
349 Building directory tree for JobId 2 ...
350 The defined Storage resources are:
352 Item 1 selected automatically.
353 You are now entering file selection mode where you add and
354 remove files to be restored. All files are initially added.
355 Enter "done" to leave this mode.
358 84 files selected to restore.
360 JobName: kernsrestore
361 Bootstrap: /home/kern/bacula/working/restore.bsr
362 Where: /tmp/bacula-restores
367 OK to run? (yes/mod/no): {\bf no}
370 {\bf cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr}
374 \subsection*{Rejected Volumes After a Crash}
375 \label{RejectedVolumes}
376 \index[general]{Crash!Rejected Volumes After a }
377 \index[general]{Rejected Volumes After a Crash }
378 \addcontentsline{toc}{subsection}{Rejected Volumes After a Crash}
380 Bacula keeps a count of the number of files on each Volume in its Catalog
381 database so that before appending to a tape, it can verify that the number of
382 files are correct, and thus prevent overwriting valid data. If the Director or
383 the Storage daemon crashes before the job has completed, the tape will contain
384 one more file than is noted in the Catalog, and the next time you attempt to
385 use the same Volume, Bacula will reject it due to a mismatch between the
386 physical tape (Volume) and the catalog.
388 The easiest solution to this problem is to label a new tape and start fresh.
389 If you wish to continue appending to the current tape, you can do so by using
390 the {\bf update} command in the console program to change the {\bf Volume
391 Files} entry in the catalog. A typical sequence of events would go like the
405 17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
406 Job=kernsave.2003-01-17_16.45.46
407 17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
408 moving to end of data.
409 17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error:
410 I cannot write on this volume because:
411 The number of files mismatch! Volume=11 Catalog=10
412 17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting.
413 Cannot find any appendable volumes.
414 Please use the "label" command to create a new Volume for:
421 (note, lines wrapped for presentation)
422 The key here is the line that reads:
426 The number of files mismatch! Volume=11 Catalog=10
430 It says that Bacula found eleven files on the volume, but that the catalog
431 says there should be ten. When you see this, you can be reasonably sure that
432 the SD was interrupted while writing before it had a chance to update the
433 catalog. As a consequence, you can just modify the catalog count to eleven,
434 and even if the catalog contains references to files saved in file 11,
435 everything will be OK and nothing will be lost. Note that if the SD had
436 written several file marks to the volume, the difference between the Volume
437 cound and the Catalog count could be larger than one, but this is unusual.
439 If on the other hand the catalog is marked as having more files than Bacula
440 found on the tape, you need to consider the possible negative consequences of
441 modifying the catalog. Please see below for a more complete discussion of
444 Continuing with the example of {\bf Volume = 11 Catalog = 10}, to enable to
445 Bacula to append to the tape, you do the following:
452 2: Pool from resource
453 3: Slots from autochanger
454 Choose catalog item to update (1-3): {\bf 1}
458 Select the Pool (1-2):
459 +-------+---------+--------+---------+-----------+------+----------+------+-----+
460 | MedId | VolName | MedTyp | VolStat | VolBytes | Last | VolReten | Recy | Slt |
461 +-------+---------+--------+---------+-----------+------+----------+------+-----+
462 | 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 |
463 +-------+---------+--------+---------+-----------+------+----------+------+-----+
464 Enter MediaId or Volume name: {\bf 1}
468 (note table output truncated for presentation) First, you chose to update the
469 Volume parameters by entering a {\bf 1}. In the volume listing that follows,
470 notice how the VolStatus is {\bf Error}. We will correct that after changing
471 the Volume Files. Continuing, you respond 1,
475 Updating Volume "test01"
476 Parameters to modify:
478 2: Volume Retention Period
479 3: Volume Use Duration
480 4: Maximum Volume Jobs
481 5: Maximum Volume Files
482 6: Maximum Volume Bytes
488 Select parameter to modify (1-11): {\bf 9}
489 Warning changing Volume Files can result
490 in loss of data on your Volume
491 Current Volume Files is: 10
492 Enter new number of Files for Volume: {\bf 11}
493 New Volume Files is: 11
494 Updating Volume "test01"
495 Parameters to modify:
497 2: Volume Retention Period
498 3: Volume Use Duration
499 4: Maximum Volume Jobs
500 5: Maximum Volume Files
501 6: Maximum Volume Bytes
507 Select parameter to modify (1-10): {\bf 1}
511 Here, you have selected {\bf 9} in order to update the Volume Files, then you
512 changed it from {\bf 10} to {\bf 11}, and you now answer {\bf 1} to change the
517 Current Volume status is: Error
525 Choose new Volume Status (1-6): {\bf 1}
526 New Volume status is: Append
527 Updating Volume "test01"
528 Parameters to modify:
530 2: Volume Retention Period
531 3: Volume Use Duration
532 4: Maximum Volume Jobs
533 5: Maximum Volume Files
534 6: Maximum Volume Bytes
540 Select parameter to modify (1-11): {\bf 11}
545 At this point, you have changed the Volume Files from {\bf 10} to {\bf 11} to
546 account for the last file that was written but not updated in the database,
547 and you changed the Volume Status back to {\bf Append}.
549 This was a lot of words to describe something quite simple.
551 The {\bf Volume Files} option exists only in version 1.29 and later, and you
552 should be careful using it. Generally, if you set the value to that which
553 Bacula said is on the tape, you will be OK, especially if the value is one
554 more than what is in the catalog.
556 Now lets consider the case:
560 The number of files mismatch! Volume=10 Catalog=12
564 Here the Bacula found fewer files on the volume than what is marked in the
565 catalog. Now, in this case, you should hesitate lot before modifying the count
566 in the catalog, because if you force the catalog from 12 to 10, Bacula will
567 start writing after the file 10 on the tape, possibly overwriting valid data,
568 and if you ever try to restore any of the files that the catalog has marked as
569 saved on Files 11 and 12, all chaos will break out. In this case, you will
570 probably be better off using a new tape. In fact, you might want to see what
571 files the catalog claims are actually stored on that Volume, and back them up
572 to another tape and recycle this tape.
574 \subsection*{Security Considerations}
576 \index[general]{Considerations!Security }
577 \index[general]{Security Considerations }
578 \addcontentsline{toc}{subsection}{Security Considerations}
580 Only the File daemon needs to run with root permission (so that it can access
581 all files). As a consequence, you may run your Director, Storage daemon, and
582 MySQL or PostgreSQL database server as non-root processes. Version 1.30 has
583 the {\bf -u} and the {\bf -g} options that allow you to specify a userid and
584 groupid on the command line to be used after Bacula starts.
586 As of version 1.33, thanks to Dan Langille, it is easier to configure the
587 Bacula Director and Storage daemon to run as non-root.
589 You should protect the Bacula port addresses (normally 9101, 9102, and 9103)
590 from outside access by a firewall or other means of protection to prevent
591 unauthorized use of your daemons.
593 You should ensure that the configuration files are not world readable since
594 they contain passwords that allow access to the daemons. Anyone who can access
595 the Director using a console program can restore any file from a backup
598 You should protect your Catalog database. If you are using SQLite, make sure
599 that the working directory is readable only by root (or your Bacula userid),
600 and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb{--{r\verb{--{} (i.e. 640) or
601 more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
602 setup procedure leaves the database open to anyone. At a minimum, you should
603 assign the user {\bf bacula} a userid and add it to your Director's
604 configuration file in the appropriate Catalog resource.
606 \subsection*{Creating Holiday Schedules}
608 \index[general]{Schedules!Creating Holiday }
609 \index[general]{Creating Holiday Schedules }
610 \addcontentsline{toc}{subsection}{Creating Holiday Schedules}
612 If you normally change tapes every day or at least every Friday, but Thursday
613 is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no
614 job runs on Thursday so that you can insert Friday's tape and be sure it will
615 be used on Friday. To do so, define a {\bf RunJobBefore} script that normally
616 returns zero, so that the Bacula job will normally continue. You can then
617 modify the script to return non-zero on any day when you do not want Bacula to
620 \subsection*{Automatic Labeling Using Your Autochanger}
622 \index[general]{Automatic Labeling Using Your Autochanger }
623 \index[general]{Autochanger!Automatic Labeling Using Your }
624 \addcontentsline{toc}{subsection}{Automatic Labeling Using Your Autochanger}
626 If you have an autochanger but it does not support barcodes, using a ``trick''
627 you can make Bacula automatically label all the volumes in your autochanger's
630 First create a file containing one line for each slot in your autochanger that
631 has a tape to be labeled. The line will contain the slot number a colon (:)
632 then the Volume name you want to use. For example, create a file named {\bf
633 volume-list}, which contains:
643 The records do not need to be in any order and you don't need to mention all
644 the slots. Normally, you will have a consistent set of Volume names and a
645 sequential set of numbers for each slot you want labeled. In the example
646 above, I've left out slots 3 and 4 just as an example. Now, modify your {\bf
647 mtx-changer} script and comment out all the lines in the {\bf list)} case by
648 putting a \# in column 1. Then add the following two lines:
652 cat <absolute-path>/volume-list
657 so that the whole case looks like:
663 # commented out lines
664 cat <absolute-path>/volume-list
670 where you replace \lt{}absolute-path\gt{} with the full path to the
671 volume-list file. Then using the console, you enter the following command:
679 and Bacula will proceed to mount the autochanger Volumes in the list and label
680 them with the Volume names you have supplied. Bacula will think that the list
681 was provided by the autochanger barcodes, but in reality, it was you who
682 supplied the \lt{}barcodes\gt{}.
684 If it seems to work, when it finishes, enter:
692 and you should see all the volumes nicely created.
694 \subsection*{Backing Up Portables Using DHCP}
696 \index[general]{DHCP!Backing Up Portables Using }
697 \index[general]{Backing Up Portables Using DHCP }
698 \addcontentsline{toc}{subsection}{Backing Up Portables Using DHCP}
700 You may want to backup laptops or portables that are not always connected to
701 the network. If you are using DHCP to assign an IP address to those machines
702 when they connect, you will need to use the Dynamic Update capability of DNS
703 to assign a name to those machines that can be used in the Address field of
704 the Client resource in the Director's conf file.
706 \subsection*{Going on Vacation}
708 \index[general]{Vacation!Going on }
709 \index[general]{Going on Vacation }
710 \addcontentsline{toc}{subsection}{Going on Vacation}
712 At some point, you may want to be absent for a week or two and you want to
713 make sure Bacula has enough tape left so that the backups will complete. You
714 start by doing a {\bf list volumes} in the Console program:
720 Using default Catalog name=BackupDB DB=bacula
722 +---------+---------------+-----------+-----------+----------------+-
723 | MediaId | VolumeName | MediaType | VolStatus | VolBytes |
724 +---------+---------------+-----------+-----------+----------------+-
725 | 23 | DLT-30Nov02 | DLT8000 | Full | 54,739,278,128 |
726 | 24 | DLT-21Dec02 | DLT8000 | Full | 56,331,524,629 |
727 | 25 | DLT-11Jan03 | DLT8000 | Full | 67,863,514,895 |
728 | 26 | DLT-02Feb03 | DLT8000 | Full | 63,439,314,216 |
729 | 27 | DLT-03Mar03 | DLT8000 | Full | 66,022,754,598 |
730 | 28 | DLT-04Apr03 | DLT8000 | Full | 60,792,559,924 |
731 | 29 | DLT-28Apr03 | DLT8000 | Full | 62,072,494,063 |
732 | 30 | DLT-17May03 | DLT8000 | Full | 65,901,767,839 |
733 | 31 | DLT-07Jun03 | DLT8000 | Used | 56,558,490,015 |
734 | 32 | DLT-28Jun03 | DLT8000 | Full | 64,274,871,265 |
735 | 33 | DLT-19Jul03 | DLT8000 | Full | 64,648,749,480 |
736 | 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 |
737 | 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 |
738 +---------+---------------+-----------+-----------+----------------+
742 Note, I have truncated the output for presentation purposes. What is
743 significant for is that I can see that my current tape has almost 10 Gbytes of
744 data, and that the average amount of data I get on my tapes is about 60
745 Gbytes. So if I go on vacation now, I don't need to worry about tape capacity
746 (at least not for short absences).
748 Equally significant is the fact that I did go on vacation the 28th of June
749 2003, and when I did the {\bf list volumes} command, my current tape at that
750 time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the
751 tape would fill shortly. Consequently, I manually marked it as {\bf Used} and
752 replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring
753 myself that the backups would all complete without my intervention.
755 \subsection*{How to Excude File on Windows Regardless of Case}
757 \index[general]{How to Excude File on Windows Regardless of Case }
758 \index[general]{Case!How to Excude File on Windows Regardless of }
759 \addcontentsline{toc}{subsection}{How to Excude File on Windows Regardless of
762 This tip was submitted by Marc Brueckner who wasn't sure of the case of some
763 of his files on Win32, which is case insensitive. The problem is that Bacula
764 thinks that {\bf /UNIMPORTANT FILES} is different from {\bf /Unimportant
765 Files}. Marc was aware that the file exclusion permits wild-cards. So, he
770 "/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
774 As a consequence, the above exclude works for files of any case.
776 Please note that this works only in Bacula Exclude statement and not in
779 \subsection*{Executing Scripts on a Remote Machine}
780 \label{RemoteExecution}
781 \index[general]{Machine!Executing Scripts on a Remote }
782 \index[general]{Executing Scripts on a Remote Machine }
783 \addcontentsline{toc}{subsection}{Executing Scripts on a Remote Machine}
785 This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
786 by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
787 records, but the technique still could be useful.) First I thought the ``Run
788 Before Job'' statement in the Job-resource is for executing a script on the
789 remote machine(the machine to be backed up). It could be usefull to execute
790 scripts on the remote machine e.g. for stopping databases or other services
791 while doing the backup. (Of cause I have to start the services again when the
792 backup has finished) I found the following solution: Bacula could execute
793 scrips on the remote machine by using ssh. The authentication is done
794 automatically using a private key. First You have to generate a keypair. I ve
799 ssh-keygen -b 4096 -t dsa -f Bacula_key
803 This statement may take a little time to run. It creates a public/private key
804 pair with no pass phrase. You could save the keys in /etc/bacula. Now you have
805 two new files : Bacula\_key which contains the private key and Bacula\_key.pub
806 which contains the public key.
808 Now you have to append the Bacula\_key.pub file to the file authorized\_keys
809 in the \textbackslash{}root\textbackslash{}.ssh directory of the remote
810 machine. Then you have to add (or uncomment) the line
814 AuthorizedKeysFile %h/.ssh/authorized_keys
818 to the sshd\_config file on the remote machine. Where the \%h stands for the
819 home-directory of the user (root in this case).
821 Assuming that your sshd is already running on the remote machine, you can now
822 enter the folloing on the machine where Bacula runs:
826 ssh -i Bacula_key -l root "ls -la"
830 This should execute the ``ls -la'' command on the remote machine.
832 Now you could add lines like the following to your Director's conf file:
837 Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
838 "/etc/init.d/database stop"
839 Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
840 "/etc/init.d/database start"
845 Even though Bacula version 1.32 has a ClientRunBeforeJob, the ssh method still
846 could be useful for updating all the Bacula clients on several remote machines
849 \subsection*{Recycling All Your Volumes}
851 \index[general]{Recycling All Your Volumes }
852 \index[general]{Volumes!Recycling All Your }
853 \addcontentsline{toc}{subsection}{Recycling All Your Volumes}
855 This tip comes from Phil Stracchino.
857 If you decide to blow away your catalog and start over, the simplest way to
858 re-add all your prelabelled tapes with the minimum of fuss (provided you don't
859 care about the data on the tapes) is to add the tape labels using the console
860 {\bf add} command, then go into the catalog and manually set the VolStatus of
861 every tape to {\bf Recycle}.
863 The SQL command to do this is very simple:
867 update Media set VolStatus = "Recycle";
871 Bacula will then ignore the data already stored on the tapes and just re-use
872 each tape without further objection.
874 \subsection*{Backing up ACLs on ext3 or XFS filesystems}
876 \index[general]{Filesystems!Backing up ACLs on ext3 or XFS }
877 \index[general]{Backing up ACLs on ext3 or XFS filesystems }
878 \addcontentsline{toc}{subsection}{Backing up ACLs on ext3 or XFS filesystems}
880 This tip comes from Volker Sauer.
882 Note, this tip was given prior to implementation of ACLs in Bacula (version
883 1.34.5). It is left here because dumping/displaying ACLs can still be useful
884 in testing/verifying that Bacula is backing up and restoring your ACLs
885 properly. Please see the
886 \ilink{aclsupport}{ACLSupport} FileSet option in the
887 configuration chapter of this manual.
889 For example, you could dump the ACLs to a file with a script similar to the
895 BACKUP_DIRS="/foo /bar"
896 STORE_ACL=/root/acl-backup
898 for i in $BACKUP_DIRS; do
899 cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_}
904 Then use Bacula to backup {\bf /root/acl-backup}.
906 The ACLs could be restored using Bacula to the {\bf /root/acl-backup} file,
907 then restored to your system using:
911 setfacl --restore/root/acl-backup
915 \subsection*{Total Automation of Bacula Tape Handling}
917 \index[general]{Handling!Total Automation of Bacula Tape }
918 \index[general]{Total Automation of Bacula Tape Handling }
919 \addcontentsline{toc}{subsection}{Total Automation of Bacula Tape Handling}
921 This tip was provided by Alexander Kuehn.
923 \elink{Bacula}{http://www.bacula.org/} is a really nice backup program except
924 that the manual tape changing requires user interaction with the bacula
927 Fortunately I can fix this.
928 NOTE!!! This suggestion applies for people who do *NOT* have tape autochangers
929 and must change tapes manually.!!!!!
931 Bacula supports a variety of tape changers through the use of mtx-changer
932 scripts/programs. This highly flexible approach allowed me to create
933 \ilink{this shell script}{mtx-changer.txt} which does the following:
934 Whenever a new tape is required it sends a mail to the operator to insert the
935 new tape. Then it waits until a tape has been inserted, sends a mail again to
936 say thank you and let's bacula continue it's backup.
937 So you can schedule and run backups without ever having to log on or see the
939 To make the whole thing work you need to create a Device resource which looks
940 something like this (``Archive Device'', ``Maximum Changer Wait'', ``Media
941 Type'' and ``Label media'' may have different values):
947 Archive Device = # use yours not mine! ;)/dev/nsa0
948 Changer Device = # not really required/dev/nsa0
949 Changer Command = "# use this (maybe change the path)!
950 /usr/local/bin/mtx-changer %o %a %S"
951 Maximum Changer Wait = 3d # 3 days in seconds
952 AutomaticMount = yes; # mount on start
953 AlwaysOpen = yes; # keep device locked
954 Media Type = DDS3 # it's just a name
955 RemovableMedia = yes; #
956 Offline On Unmount = Yes; # keep this too
962 As the script has to emulate the complete wisdom of a mtx-changer it has an
963 internal ``database'' where which tape is stored, you can see this at that
968 labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006
969 VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012"
973 The above should be all on one line, and it effectivly tells Bacula that
974 volume ``VOL-0001'' is located in slot 1 (which is our lowest slot), that
975 volume ``VOL-0002'' is located in slot 2 and so on..
976 The script also maintains a logfile (/var/log/mtx.log) where you can monitor
979 \subsection*{Running Concurrent Jobs}
980 \label{ConcurrentJobs}
981 \index[general]{Jobs!Running Concurrent}
982 \index[general]{Running Concurrent Jobs}
983 \addcontentsline{toc}{subsection}{Running Concurrent Jobs}
985 Bacula can run multiple concurrent jobs, but the default configuration files
986 are not set to do so. Using the {\bf Maximum Concurrent Jobs} directive, you
987 have a lot of control over how many jobs can run at the same time, and which
988 jobs can run simultaneously. The downside is that it can be a bit tricky to
989 set it up for the first time as you need to set the concurrency in at least
990 five different places.
992 The Director, the File daemon, and the Storage daemon each have a {\bf Maximum
993 Concurrent Jobs} directive that determines overall number of concurrent jobs
994 the daemon will run. The default is one for the Director and ten for both the
995 File daemon and the Storage daemon, so assuming you will not be running more
996 than ten concurrent jobs, the only changes that are needed are in the
997 Director's conf file (bacula-dir.conf).
999 Within the Director's configuration file, {\bf Maximum Concurrent Jobs} can be
1000 set in the Direct, Job, Client, and Storage resources. Each one must be set
1001 properly, according to your needs, otherwise your jobs may be run one at a
1004 For example, if you want two different jobs to run simultaneously backing up
1005 the same Client to the same Storage device, they will run concurrentl only if
1006 you have set {\bf Maximum Concurrent Jobs} greater than one in the Director
1007 resource, the Client resource, and the Storage resource in bacula-dir.conf.
1009 We recommend that you carefully test your multiple concurrent backup including
1010 doing thorough restore testing before you put it into production.
1012 Below is a super stripped down bacula-dir.conf file showing you the four
1013 places where the the file has been modified to allow the same job {\bf
1014 NightlySave} to run up to four times concurrently. The change to the Job
1015 resource is not necessary if you want different Jobs to run at the same time,
1016 which is the normal case.
1021 # Bacula Director Configuration file -- bacula-dir.conf
1025 Maximum Concurrent Jobs = 4
1029 Name = "NightlySave"
1030 Maximum Concurrent Jobs = 4
1037 Maximum Concurrent Jobs = 4
1042 Maximum Concurrent Jobs = 4