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 you 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 If the new version of Bacula requires an upgrade to the database,
53 you can upgrade it with the script {\bf update_bacula_tables}, which
54 will be installed in your scripts directory (default {\bf /etc/bacula}),
55 or alternatively, you can find it in the
56 {\bf \lt{}bacula-source\gt{}/src/cats} directory.
58 \subsection*{Getting Notified of Job Completion}
60 \index[general]{Getting Notified of Job Completion }
61 \index[general]{Completion!Getting Notified of Job }
62 \addcontentsline{toc}{subsection}{Getting Notified of Job Completion}
64 One of the first things you should do is to ensure that you are being properly
65 notified of the status of each Job run by Bacula, or at a minimum of each Job
66 that terminates with an error.
68 Until you are completely comfortable with {\bf Bacula}, we recommend that you
69 send an email to yourself for each Job that is run. This is most easily
70 accomplished by adding an email notification address in the {\bf Messages}
71 resource of your Director's configuration file. An email is automatically
72 configured in the default configuration files, but you must ensure that the
73 default {\bf root} address is replaced by your email address.
75 For examples of how I (Kern) configure my system, please take a look at the
76 {\bf .conf} files found in the {\bf examples} sub-directory. We recommend the
77 following configuration (where you change the paths and email address to
78 correspond to your setup). Note, the {\bf mailcommand} and {\bf
79 operatorcommand} should be on a single line. They were split here for
86 mailcommand = "/home/bacula/bin/bsmtp -h localhost
88 -s \"Bacula: %t %e of %c %l\" %r"
89 operatorcommand = "/home/bacula/bin/bsmtp -h localhost
91 -s \"Bacula: Intervention needed for %j\" %r"
92 Mail = your-email-address = all, !skipped, !terminate
93 append = "/home/bacula/bin/log" = all, !skipped, !terminate
94 operator = your-email-address = mount
95 console = all, !skipped, !saved
100 You will need to ensure that the {\bf /home/bacula/bin} path on the {\bf
101 mailcommand} and the {\bf operatorcommand} lines point to your {\bf Bacula}
102 binary directory where the {\bf bsmtp} program will be installed. You will
103 also want to ensure that the {\bf your-email-address} is replaced by your
104 email address, and finally, you will also need to ensure that the {\bf
105 /home/bacula/bin/log} points to the file where you want to log all messages.
107 With the above Messages resource, you will be notified by email of every Job
108 that ran, all the output will be appended to the {\bf log} file you specify,
109 all output will be directed to the console program, and all mount messages
110 will be emailed to you. Note, some messages will be sent to multiple
113 The form of the mailcommand is a bit complicated, but it allows you to
114 distinguish whether the Job terminated in error or terminated normally. Please
116 \ilink{Mail Command}{mailcommand} section of the Messages
117 Resource chapter of this manual for the details of the substitution characters
120 Once you are totally comfortable with Bacula as I am, or if you have a large
121 number of nightly Jobs as I do (eight), you will probably want to change the
122 {\bf Mail} command to {\bf Mail On Error} which will generate an email message
123 only if the Job terminates in error. If the Job terminates normally, no email
124 message will be sent, but the output will still be appended to the log file as
125 well as sent to the Console program.
127 \subsection*{Getting Email Notification to Work}
129 \index[general]{Work!Getting Email Notification to }
130 \index[general]{Getting Email Notification to Work }
131 \addcontentsline{toc}{subsection}{Getting Email Notification to Work}
133 The section above describes how to get email notification of job status.
134 Occasionally, however, users have problems receiving any email at all. In that
135 case, the things to check are the following:
138 \item Ensure that you have a valid email address specified on your {\bf Mail}
139 record in the Director's Messages resource. The email address should be fully
140 qualified. Simply using {\bf root} generally will not work, rather you should
141 use {\bf root@localhost} or better yet your full domain.
142 \item Ensure that you do not have a {\bf Mail} record in the Storage daemon's
143 or File daemon's configuration files. The only record you should have is {\bf
148 director = director-name = all
153 \item If all else fails, try replacing the {\bf mailcommand} with
157 mailcommand = "mail -s test your@domain.com"
161 \item Once the above is working, assuming you want to use {\bf bsmtp}, submit
162 the desired bsmtp command by hand and ensure that the email is delivered,
163 then put that command into {\bf Bacula}. Small differences in things such as
164 the parenthesis around the word Bacula can make a big difference to some
165 bsmtp programs. For example, you might start simply by using:
169 mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r"
175 \subsection*{Getting Notified that Bacula is Running}
176 \label{JobNotification}
177 \index[general]{Running!Getting Notified that Bacula is }
178 \index[general]{Getting Notified that Bacula is Running }
179 \addcontentsline{toc}{subsection}{Getting Notified that Bacula is Running}
181 If like me, you have setup Bacula so that email is sent only when a Job has
182 errors, as described in the previous section of this chapter, inevitably, one
183 day, something will go wrong and {\bf Bacula} can stall. This could be because
184 Bacula crashes, which is vary rare, or more likely the network has caused {\bf
185 Bacula} to {\bf hang} for some unknown reason.
187 To avoid this, you can use the {\bf RunAfterJob} command in the Job resource
188 to schedule a Job nightly, or weekly that simply emails you a message saying
189 that Bacula is still running. For example, I have setup the following Job in
190 my Director's configuration file:
196 Run = Level=Full sun-sat at 6:05
206 Schedule = "Watchdog"
207 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
215 File Retention = 1day
216 Job Retention = 1 month
222 Where I established a schedule to run the Job nightly. The Job itself is type
223 {\bf Admin} which means that it doesn't actually do anything, and I've defined
224 a FileSet, Pool, Storage, and Client, all of which are not really used (and
225 probably don't need to be specified). The key aspect of this Job is the
230 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d"
234 which runs my "watchdog" script. As an example, I have added the Job codes
235 \%c and \%d which will cause the Client name and the Director's name to be
236 passed to the script. For example, if the Client's name is {\bf Watchdog} and
237 the Director's name is {\bf main-dir} then referencing \$1 in the script would
238 get {\bf Watchdog} and referencing \$2 would get {\bf main-dir}. In this case,
239 having the script know the Client and Director's name is not really useful,
240 but in other situations it may be.
242 You can put anything in the watchdog script. In my case, I like to monitor the
243 size of my catalog to be sure that {\bf Bacula} is really pruning it. The
244 following is my watchdog script:
249 cd /home/kern/mysql/var/bacula
251 /home/kern/bacula/bin/bsmtp \
252 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
253 -s "Bacula running" abuse@whitehouse.com
257 If you just wish to send yourself a message, you can do it with:
262 cd /home/kern/mysql/var/bacula
263 /home/kern/bacula/bin/bsmtp \
264 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
265 -s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
266 Bacula is still running!!!
271 \subsection*{Maintaining a Valid Bootstrap File}
273 \index[general]{Maintaining a Valid Bootstrap File }
274 \index[general]{File!Maintaining a Valid Bootstrap }
275 \addcontentsline{toc}{subsection}{Maintaining a Valid Bootstrap File}
278 \ilink{ WriteBootstrap}{writebootstrap} record in each of your
279 Director's Job resources, you can constantly maintain a
280 \ilink{bootstrap}{_ChapterStart43} file that will enable you to
281 recover the state of your system as of the last backup without having the
282 Bacula catalog. This permits you to more easily recover from a disaster that
283 destroys your Bacula catalog.
285 When a Job resource has a {\bf WriteBootstrap} record, Bacula will maintain
286 the designated file (normally on another system but mounted by NSF) with up to
287 date information necessary to restore your system. For example, in my
288 Director's configuration file, I have the following record:
292 Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"
296 where I replace {\bf client-name} by the actual name of the client that is
297 being backed up. Thus, Bacula automatically maintains one file for each of my
298 clients. The necessary bootstrap information is appended to this file during
299 each {\bf Incremental} backup, and the file is totally rewritten during each
302 Note, one disadvantage of writing to an NFS mounted volume as I do is
303 that if the other machine goes down, the OS will wait forever on the fopen()
304 call that Bacula makes. As a consequence, Bacula will completely stall until
305 the machine exporting the NSF mounts comes back up. A possible solution to this
306 problem was provided by Andrew Hilborne, and consists of using the {\bf soft}
307 option instead of the {\bf hard} option when mounting the NFS volume, which is
308 typically done in {\bf /etc/fstab}/. The NFS documentation explains these
309 options in detail. However, I found that with the {\bf soft} option
310 NFS disconnected frequently causing even more problems.
312 If you are starting off in the middle of a cycle (i.e. with Incremental
313 backups) rather than at the beginning (with a Full backup), the {\bf
314 bootstrap} file will not be immediately valid as it must always have the
315 information from a Full backup as the first record. If you wish to synchronize
316 your bootstrap file immediately, you can do so by running a {\bf restore}
317 command for the client and selecting a full restore, but when the restore
318 command asks for confirmation to run the restore Job, you simply reply no,
319 then copy the bootstrap file that was written to the location specified on the
320 {\bf Write Bootstrap} record. The restore bootstrap file can be found in {\bf
321 restore.bsr} in the working directory that you defined. In the example given
322 below for the client {\bf rufus}, my input is shown in bold. Note, the JobId
323 output has been partially truncated to fit on the page here:
327 (in the Console program)
329 First you select one or more JobIds that contain files
330 to be restored. You will then be presented several methods
331 of specifying the JobIds. Then you will be allowed to
332 select which files from those JobIds are to be restored.
333 To select the JobIds, you have the following choices:
334 1: List last 20 Jobs run
335 2: List Jobs where a given File is saved
336 3: Enter list of JobIds to select
337 4: Enter SQL list command
338 5: Select the most recent backup for a client
340 Select item: (1-6): {\bf 5}
341 The defined Client resources are:
345 Select Client (File daemon) resource (1-3): {\bf 2}
346 The defined FileSet resources are:
348 Item 1 selected automatically.
349 +-------+------+-------+---------+---------+------+-------+------------+
350 | JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime |
351 +-------+------+-------+---------+---------+------+-------+------------+
352 | 2 | F | 84 | ... | test1 | 0 | 1 | 1035645259 |
353 +-------+------+-------+---------+---------+------+-------+------------+
354 You have selected the following JobId: 2
355 Building directory tree for JobId 2 ...
356 The defined Storage resources are:
358 Item 1 selected automatically.
359 You are now entering file selection mode where you add and
360 remove files to be restored. All files are initially added.
361 Enter "done" to leave this mode.
364 84 files selected to restore.
366 JobName: kernsrestore
367 Bootstrap: /home/kern/bacula/working/restore.bsr
368 Where: /tmp/bacula-restores
373 OK to run? (yes/mod/no): {\bf no}
376 {\bf cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr}
380 \subsection*{Rejected Volumes After a Crash}
381 \label{RejectedVolumes}
382 \index[general]{Crash!Rejected Volumes After a }
383 \index[general]{Rejected Volumes After a Crash }
384 \addcontentsline{toc}{subsection}{Rejected Volumes After a Crash}
386 Bacula keeps a count of the number of files on each Volume in its Catalog
387 database so that before appending to a tape, it can verify that the number of
388 files are correct, and thus prevent overwriting valid data. If the Director or
389 the Storage daemon crashes before the job has completed, the tape will contain
390 one more file than is noted in the Catalog, and the next time you attempt to
391 use the same Volume, Bacula will reject it due to a mismatch between the
392 physical tape (Volume) and the catalog.
394 The easiest solution to this problem is to label a new tape and start fresh.
395 If you wish to continue appending to the current tape, you can do so by using
396 the {\bf update} command in the console program to change the {\bf Volume
397 Files} entry in the catalog. A typical sequence of events would go like the
411 17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
412 Job=kernsave.2003-01-17_16.45.46
413 17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
414 moving to end of data.
415 17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error:
416 I cannot write on this volume because:
417 The number of files mismatch! Volume=11 Catalog=10
418 17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting.
419 Cannot find any appendable volumes.
420 Please use the "label" command to create a new Volume for:
427 (note, lines wrapped for presentation)
428 The key here is the line that reads:
432 The number of files mismatch! Volume=11 Catalog=10
436 It says that Bacula found eleven files on the volume, but that the catalog
437 says there should be ten. When you see this, you can be reasonably sure that
438 the SD was interrupted while writing before it had a chance to update the
439 catalog. As a consequence, you can just modify the catalog count to eleven,
440 and even if the catalog contains references to files saved in file 11,
441 everything will be OK and nothing will be lost. Note that if the SD had
442 written several file marks to the volume, the difference between the Volume
443 cound and the Catalog count could be larger than one, but this is unusual.
445 If on the other hand the catalog is marked as having more files than Bacula
446 found on the tape, you need to consider the possible negative consequences of
447 modifying the catalog. Please see below for a more complete discussion of
450 Continuing with the example of {\bf Volume = 11 Catalog = 10}, to enable to
451 Bacula to append to the tape, you do the following:
458 2: Pool from resource
459 3: Slots from autochanger
460 Choose catalog item to update (1-3): {\bf 1}
464 Select the Pool (1-2):
465 +-------+---------+--------+---------+-----------+------+----------+------+-----+
466 | MedId | VolName | MedTyp | VolStat | VolBytes | Last | VolReten | Recy | Slt |
467 +-------+---------+--------+---------+-----------+------+----------+------+-----+
468 | 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 |
469 +-------+---------+--------+---------+-----------+------+----------+------+-----+
470 Enter MediaId or Volume name: {\bf 1}
474 (note table output truncated for presentation) First, you chose to update the
475 Volume parameters by entering a {\bf 1}. In the volume listing that follows,
476 notice how the VolStatus is {\bf Error}. We will correct that after changing
477 the Volume Files. Continuing, you respond 1,
481 Updating Volume "test01"
482 Parameters to modify:
484 2: Volume Retention Period
485 3: Volume Use Duration
486 4: Maximum Volume Jobs
487 5: Maximum Volume Files
488 6: Maximum Volume Bytes
494 Select parameter to modify (1-11): {\bf 9}
495 Warning changing Volume Files can result
496 in loss of data on your Volume
497 Current Volume Files is: 10
498 Enter new number of Files for Volume: {\bf 11}
499 New Volume Files is: 11
500 Updating Volume "test01"
501 Parameters to modify:
503 2: Volume Retention Period
504 3: Volume Use Duration
505 4: Maximum Volume Jobs
506 5: Maximum Volume Files
507 6: Maximum Volume Bytes
513 Select parameter to modify (1-10): {\bf 1}
517 Here, you have selected {\bf 9} in order to update the Volume Files, then you
518 changed it from {\bf 10} to {\bf 11}, and you now answer {\bf 1} to change the
523 Current Volume status is: Error
531 Choose new Volume Status (1-6): {\bf 1}
532 New Volume status is: Append
533 Updating Volume "test01"
534 Parameters to modify:
536 2: Volume Retention Period
537 3: Volume Use Duration
538 4: Maximum Volume Jobs
539 5: Maximum Volume Files
540 6: Maximum Volume Bytes
546 Select parameter to modify (1-11): {\bf 11}
551 At this point, you have changed the Volume Files from {\bf 10} to {\bf 11} to
552 account for the last file that was written but not updated in the database,
553 and you changed the Volume Status back to {\bf Append}.
555 This was a lot of words to describe something quite simple.
557 The {\bf Volume Files} option exists only in version 1.29 and later, and you
558 should be careful using it. Generally, if you set the value to that which
559 Bacula said is on the tape, you will be OK, especially if the value is one
560 more than what is in the catalog.
562 Now lets consider the case:
566 The number of files mismatch! Volume=10 Catalog=12
570 Here the Bacula found fewer files on the volume than what is marked in the
571 catalog. Now, in this case, you should hesitate a lot before modifying the count
572 in the catalog, because if you force the catalog from 12 to 10, Bacula will
573 start writing after the file 10 on the tape, possibly overwriting valid data,
574 and if you ever try to restore any of the files that the catalog has marked as
575 saved on Files 11 and 12, all chaos will break out. In this case, you will
576 probably be better off using a new tape. In fact, you might want to see what
577 files the catalog claims are actually stored on that Volume, and back them up
578 to another tape and recycle this tape.
580 \subsection*{Security Considerations}
582 \index[general]{Considerations!Security }
583 \index[general]{Security Considerations }
584 \addcontentsline{toc}{subsection}{Security Considerations}
586 Only the File daemon needs to run with root permission (so that it can access
587 all files). As a consequence, you may run your Director, Storage daemon, and
588 MySQL or PostgreSQL database server as non-root processes. Version 1.30 has
589 the {\bf -u} and the {\bf -g} options that allow you to specify a userid and
590 groupid on the command line to be used after Bacula starts.
592 As of version 1.33, thanks to Dan Langille, it is easier to configure the
593 Bacula Director and Storage daemon to run as non-root.
595 You should protect the Bacula port addresses (normally 9101, 9102, and 9103)
596 from outside access by a firewall or other means of protection to prevent
597 unauthorized use of your daemons.
599 You should ensure that the configuration files are not world readable since
600 they contain passwords that allow access to the daemons. Anyone who can access
601 the Director using a console program can restore any file from a backup
604 You should protect your Catalog database. If you are using SQLite, make sure
605 that the working directory is readable only by root (or your Bacula userid),
606 and ensure that {\bf bacula.db} has permissions {\bf -rw-r\verb:--:r\verb:--:} (i.e. 640) or
607 more strict. If you are using MySQL or PostgreSQL, please note that the Bacula
608 setup procedure leaves the database open to anyone. At a minimum, you should
609 assign the user {\bf bacula} a userid and add it to your Director's
610 configuration file in the appropriate Catalog resource.
612 \subsection*{Creating Holiday Schedules}
614 \index[general]{Schedules!Creating Holiday }
615 \index[general]{Creating Holiday Schedules }
616 \addcontentsline{toc}{subsection}{Creating Holiday Schedules}
618 If you normally change tapes every day or at least every Friday, but Thursday
619 is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no
620 job runs on Thursday so that you can insert Friday's tape and be sure it will
621 be used on Friday. To do so, define a {\bf RunJobBefore} script that normally
622 returns zero, so that the Bacula job will normally continue. You can then
623 modify the script to return non-zero on any day when you do not want Bacula to
626 \subsection*{Automatic Labeling Using Your Autochanger}
628 \index[general]{Automatic Labeling Using Your Autochanger }
629 \index[general]{Autochanger!Automatic Labeling Using Your }
630 \addcontentsline{toc}{subsection}{Automatic Labeling Using Your Autochanger}
632 If you have an autochanger but it does not support barcodes, using a "trick"
633 you can make Bacula automatically label all the volumes in your autochanger's
636 First create a file containing one line for each slot in your autochanger that
637 has a tape to be labeled. The line will contain the slot number a colon (:)
638 then the Volume name you want to use. For example, create a file named {\bf
639 volume-list}, which contains:
649 The records do not need to be in any order and you don't need to mention all
650 the slots. Normally, you will have a consistent set of Volume names and a
651 sequential set of numbers for each slot you want labeled. In the example
652 above, I've left out slots 3 and 4 just as an example. Now, modify your {\bf
653 mtx-changer} script and comment out all the lines in the {\bf list)} case by
654 putting a \# in column 1. Then add the following two lines:
658 cat <absolute-path>/volume-list
663 so that the whole case looks like:
669 # commented out lines
670 cat <absolute-path>/volume-list
676 where you replace \lt{}absolute-path\gt{} with the full path to the
677 volume-list file. Then using the console, you enter the following command:
685 and Bacula will proceed to mount the autochanger Volumes in the list and label
686 them with the Volume names you have supplied. Bacula will think that the list
687 was provided by the autochanger barcodes, but in reality, it was you who
688 supplied the \lt{}barcodes\gt{}.
690 If it seems to work, when it finishes, enter:
698 and you should see all the volumes nicely created.
700 \subsection*{Backing Up Portables Using DHCP}
702 \index[general]{DHCP!Backing Up Portables Using }
703 \index[general]{Backing Up Portables Using DHCP }
704 \addcontentsline{toc}{subsection}{Backing Up Portables Using DHCP}
706 You may want to backup laptops or portables that are not always connected to
707 the network. If you are using DHCP to assign an IP address to those machines
708 when they connect, you will need to use the Dynamic Update capability of DNS
709 to assign a name to those machines that can be used in the Address field of
710 the Client resource in the Director's conf file.
712 \subsection*{Going on Vacation}
714 \index[general]{Vacation!Going on }
715 \index[general]{Going on Vacation }
716 \addcontentsline{toc}{subsection}{Going on Vacation}
718 At some point, you may want to be absent for a week or two and you want to
719 make sure Bacula has enough tape left so that the backups will complete. You
720 start by doing a {\bf list volumes} in the Console program:
726 Using default Catalog name=BackupDB DB=bacula
728 +---------+---------------+-----------+-----------+----------------+-
729 | MediaId | VolumeName | MediaType | VolStatus | VolBytes |
730 +---------+---------------+-----------+-----------+----------------+-
731 | 23 | DLT-30Nov02 | DLT8000 | Full | 54,739,278,128 |
732 | 24 | DLT-21Dec02 | DLT8000 | Full | 56,331,524,629 |
733 | 25 | DLT-11Jan03 | DLT8000 | Full | 67,863,514,895 |
734 | 26 | DLT-02Feb03 | DLT8000 | Full | 63,439,314,216 |
735 | 27 | DLT-03Mar03 | DLT8000 | Full | 66,022,754,598 |
736 | 28 | DLT-04Apr03 | DLT8000 | Full | 60,792,559,924 |
737 | 29 | DLT-28Apr03 | DLT8000 | Full | 62,072,494,063 |
738 | 30 | DLT-17May03 | DLT8000 | Full | 65,901,767,839 |
739 | 31 | DLT-07Jun03 | DLT8000 | Used | 56,558,490,015 |
740 | 32 | DLT-28Jun03 | DLT8000 | Full | 64,274,871,265 |
741 | 33 | DLT-19Jul03 | DLT8000 | Full | 64,648,749,480 |
742 | 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 |
743 | 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 |
744 +---------+---------------+-----------+-----------+----------------+
748 Note, I have truncated the output for presentation purposes. What is
749 significant, is that I can see that my current tape has almost 10 Gbytes of
750 data, and that the average amount of data I get on my tapes is about 60
751 Gbytes. So if I go on vacation now, I don't need to worry about tape capacity
752 (at least not for short absences).
754 Equally significant is the fact that I did go on vacation the 28th of June
755 2003, and when I did the {\bf list volumes} command, my current tape at that
756 time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the
757 tape would fill shortly. Consequently, I manually marked it as {\bf Used} and
758 replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring
759 myself that the backups would all complete without my intervention.
761 \subsection*{How to Excude File on Windows Regardless of Case}
763 \index[general]{How to Excude File on Windows Regardless of Case }
764 \index[general]{Case!How to Excude File on Windows Regardless of }
765 \addcontentsline{toc}{subsection}{How to Excude File on Windows Regardless of
768 This tip was submitted by Marc Brueckner who wasn't sure of the case of some
769 of his files on Win32, which is case insensitive. The problem is that Bacula
770 thinks that {\bf /UNIMPORTANT FILES} is different from {\bf /Unimportant
771 Files}. Marc was aware that the file exclusion permits wild-cards. So, he
776 "/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"
780 As a consequence, the above exclude works for files of any case.
782 Please note that this works only in Bacula Exclude statement and not in
785 \subsection*{Executing Scripts on a Remote Machine}
786 \label{RemoteExecution}
787 \index[general]{Machine!Executing Scripts on a Remote }
788 \index[general]{Executing Scripts on a Remote Machine }
789 \addcontentsline{toc}{subsection}{Executing Scripts on a Remote Machine}
791 This tip also comes from Marc Brueckner. (Note, this tip is probably outdated
792 by the addition of {\bf ClientRunBeforJob} and {\bf ClientRunAfterJob} Job
793 records, but the technique still could be useful.) First I thought the "Run
794 Before Job" statement in the Job-resource is for executing a script on the
795 remote machine(the machine to be backed up). It could be usefull to execute
796 scripts on the remote machine e.g. for stopping databases or other services
797 while doing the backup. (Of course I have to start the services again when the
798 backup has finished) I found the following solution: Bacula could execute
799 scrips on the remote machine by using ssh. The authentication is done
800 automatically using a private key. First You have to generate a keypair. I've
805 ssh-keygen -b 4096 -t dsa -f Bacula_key
809 This statement may take a little time to run. It creates a public/private key
810 pair with no passphrase. You could save the keys in /etc/bacula. Now you have
811 two new files : Bacula\_key which contains the private key and Bacula\_key.pub
812 which contains the public key.
814 Now you have to append the Bacula\_key.pub file to the file authorized\_keys
815 in the \textbackslash{}root\textbackslash{}.ssh directory of the remote
816 machine. Then you have to add (or uncomment) the line
820 AuthorizedKeysFile %h/.ssh/authorized_keys
824 to the sshd\_config file on the remote machine. Where the \%h stands for the
825 home-directory of the user (root in this case).
827 Assuming that your sshd is already running on the remote machine, you can now
828 enter the following on the machine where Bacula runs:
832 ssh -i Bacula_key -l root "ls -la"
836 This should execute the "ls -la" command on the remote machine.
838 Now you could add lines like the following to your Director's conf file:
843 Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
844 "/etc/init.d/database stop"
845 Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \
846 "/etc/init.d/database start"
851 Even though Bacula version 1.32 has a ClientRunBeforeJob, the ssh method still
852 could be useful for updating all the Bacula clients on several remote machines
855 \subsection*{Recycling All Your Volumes}
857 \index[general]{Recycling All Your Volumes }
858 \index[general]{Volumes!Recycling All Your }
859 \addcontentsline{toc}{subsection}{Recycling All Your Volumes}
861 This tip comes from Phil Stracchino.
863 If you decide to blow away your catalog and start over, the simplest way to
864 re-add all your prelabeled tapes with a minimum of fuss (provided you don't
865 care about the data on the tapes) is to add the tape labels using the console
866 {\bf add} command, then go into the catalog and manually set the VolStatus of
867 every tape to {\bf Recycle}.
869 The SQL command to do this is very simple:
873 update Media set VolStatus = "Recycle";
877 Bacula will then ignore the data already stored on the tapes and just re-use
878 each tape without further objection.
880 \subsection*{Backing up ACLs on ext3 or XFS filesystems}
882 \index[general]{Filesystems!Backing up ACLs on ext3 or XFS }
883 \index[general]{Backing up ACLs on ext3 or XFS filesystems }
884 \addcontentsline{toc}{subsection}{Backing up ACLs on ext3 or XFS filesystems}
886 This tip comes from Volker Sauer.
888 Note, this tip was given prior to implementation of ACLs in Bacula (version
889 1.34.5). It is left here because dumping/displaying ACLs can still be useful
890 in testing/verifying that Bacula is backing up and restoring your ACLs
891 properly. Please see the
892 \ilink{aclsupport}{ACLSupport} FileSet option in the
893 configuration chapter of this manual.
895 For example, you could dump the ACLs to a file with a script similar to the
901 BACKUP_DIRS="/foo /bar"
902 STORE_ACL=/root/acl-backup
904 for i in $BACKUP_DIRS; do
905 cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_}
910 Then use Bacula to backup {\bf /root/acl-backup}.
912 The ACLs could be restored using Bacula to the {\bf /root/acl-backup} file,
913 then restored to your system using:
917 setfacl --restore/root/acl-backup
921 \subsection*{Total Automation of Bacula Tape Handling}
923 \index[general]{Handling!Total Automation of Bacula Tape }
924 \index[general]{Total Automation of Bacula Tape Handling }
925 \addcontentsline{toc}{subsection}{Total Automation of Bacula Tape Handling}
927 This tip was provided by Alexander Kuehn.
929 \elink{Bacula}{http://www.bacula.org/} is a really nice backup program except
930 that the manual tape changing requires user interaction with the bacula
933 Fortunately I can fix this.
934 NOTE!!! This suggestion applies for people who do *NOT* have tape autochangers
935 and must change tapes manually.!!!!!
937 Bacula supports a variety of tape changers through the use of mtx-changer
938 scripts/programs. This highly flexible approach allowed me to create
939 \ilink{this shell script}{mtx-changer.txt} which does the following:
940 Whenever a new tape is required it sends a mail to the operator to insert the
941 new tape. Then it waits until a tape has been inserted, sends a mail again to
942 say thank you and let's bacula continue it's backup.
943 So you can schedule and run backups without ever having to log on or see the
945 To make the whole thing work you need to create a Device resource which looks
946 something like this ("Archive Device", "Maximum Changer Wait", "Media
947 Type" and "Label media" may have different values):
953 Archive Device = # use yours not mine! ;)/dev/nsa0
954 Changer Device = # not really required/dev/nsa0
955 Changer Command = "# use this (maybe change the path)!
956 /usr/local/bin/mtx-changer %o %a %S"
957 Maximum Changer Wait = 3d # 3 days in seconds
958 AutomaticMount = yes; # mount on start
959 AlwaysOpen = yes; # keep device locked
960 Media Type = DDS3 # it's just a name
961 RemovableMedia = yes; #
962 Offline On Unmount = Yes; # keep this too
968 As the script has to emulate the complete wisdom of a mtx-changer it has an
969 internal "database" containing where which tape is stored, you can see this on
974 labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006
975 VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012"
979 The above should be all on one line, and it effectivly tells Bacula that
980 volume "VOL-0001" is located in slot 1 (which is our lowest slot), that
981 volume "VOL-0002" is located in slot 2 and so on..
982 The script also maintains a logfile (/var/log/mtx.log) where you can monitor
985 \subsection*{Running Concurrent Jobs}
986 \label{ConcurrentJobs}
987 \index[general]{Jobs!Running Concurrent}
988 \index[general]{Running Concurrent Jobs}
989 \index[general]{Concurrent Jobs}
990 \addcontentsline{toc}{subsection}{Running Concurrent Jobs}
992 Bacula can run multiple concurrent jobs, but the default configuration files
993 are not set to do so. Using the {\bf Maximum Concurrent Jobs} directive, you
994 have a lot of control over how many jobs can run at the same time, and which
995 jobs can run simultaneously. The downside is that it can be a bit tricky to
996 set it up for the first time as you need to set the concurrency in at least
997 five different places.
999 The Director, the File daemon, and the Storage daemon each have a {\bf Maximum
1000 Concurrent Jobs} directive that determines overall number of concurrent jobs
1001 the daemon will run. The default is one for the Director and ten for both the
1002 File daemon and the Storage daemon, so assuming you will not be running more
1003 than ten concurrent jobs, the only changes that are needed are in the
1004 Director's conf file (bacula-dir.conf).
1006 Within the Director's configuration file, {\bf Maximum Concurrent Jobs} can be
1007 set in the Direct, Job, Client, and Storage resources. Each one must be set
1008 properly, according to your needs, otherwise your jobs may be run one at a
1011 For example, if you want two different jobs to run simultaneously backing up
1012 the same Client to the same Storage device, they will run concurrentl only if
1013 you have set {\bf Maximum Concurrent Jobs} greater than one in the Director
1014 resource, the Client resource, and the Storage resource in bacula-dir.conf.
1016 We recommend that you carefully test your multiple concurrent backup including
1017 doing thorough restore testing before you put it into production.
1019 Below is a super stripped down bacula-dir.conf file showing you the four
1020 places where the the file has been modified to allow the same job {\bf
1021 NightlySave} to run up to four times concurrently. The change to the Job
1022 resource is not necessary if you want different Jobs to run at the same time,
1023 which is the normal case.
1028 # Bacula Director Configuration file -- bacula-dir.conf
1032 Maximum Concurrent Jobs = 4
1036 Name = "NightlySave"
1037 Maximum Concurrent Jobs = 4
1044 Maximum Concurrent Jobs = 4
1049 Maximum Concurrent Jobs = 4