1\chapter{Tips and Suggestions} 2\label{blb:TipsChapter} 3\index[general]{Tips and Suggestions} 4\index[general]{Suggestions!Tips and} 5\label{blb:examples} 6\index[general]{Examples} 7 8There are a number of example scripts for various things that can be found in 9the \bdirectoryname{example} subdirectory and its subdirectories of the \bacula{} source 10distribution. 11 12For additional tips, please see the \bref{http://wiki.bacula.org}{\bacula{} 13wiki}. 14 15\section{Upgrading \bacula{} Versions} 16\label{blb:upgrading} 17\index[general]{Upgrading \bacula{} Versions} 18\index[general]{Versions!Upgrading \bacula{}} 19\index[general]{Upgrading} 20 21The first thing to do before upgrading from one version to another is to 22ensure that you don't overwrite or delete your production (current) version 23of \bacula{} until you have tested that the new version works. 24 25If you have installed \bacula{} into a single directory, this is simple: simply 26make a copy of your \bacula{} directory. 27 28If you have done a more typical Unix installation where the binaries are 29placed in one directory and the configuration files are placed in another, 30then the simplest way is to configure your new \bacula{} to go into a single 31file. Alternatively, make copies of all your binaries and especially your 32conf files. 33 34Whatever your situation may be (one of the two just described), you should 35probably start with the \btool{defaultconf} script that can be found in the 36\bdirectoryname{examples} subdirectory. Copy this script to the main \bacula{} directory, modify 37it 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\bfilename{*.conf} files from your production \bacula{} directory to the test \bacula{} 40directory, start the test version, and run a few test backups. If all seems 41good, then you can proceed to install the new \bacula{} in place of or possibly 42over the old \bacula{}. 43 44When installing a new \bacula{} you need not worry about losing the changes you 45made to your configuration files as the installation process will not 46overwrite them providing that you do not do a \btool{make uninstall}. 47 48If the new version of \bacula{} requires an upgrade to the database, 49you can upgrade it with the script \btool{update\_bacula\_tables}, which 50will be installed in your scripts directory (default \bdefaultvalue{/etc/bacula}), 51or alternatively, you can find it in the 52\bdirectoryname{\bbracket{bacula-source}/src/cats} directory. 53 54\section{Getting Notified of Job Completion} 55\label{blb:notification} 56\index[general]{Getting Notified of Job Completion} 57\index[general]{Completion!Getting Notified of Job} 58 59One of the first things you should do is to ensure that you are being properly 60notified of the status of each Job run by \bacula{}, or at a minimum of each Job 61that terminates with an error. 62 63Until you are completely comfortable with \textbf{\bacula{}}, we recommend that you 64send an email to yourself for each Job that is run. This is most easily 65accomplished by adding an email notification address in the \textbf{Messages} 66resource of your Director's configuration file. An email is automatically 67configured in the default configuration files, but you must ensure that the 68default \texttt{root} address is replaced by your email address. 69 70For additional examples of how to configure a \bacula{}, please take a look at the 71\bfilename{.conf} files found in the \bdirectoryname{examples} sub-directory. We recommend the 72following configuration (where you change the paths and email address to 73correspond to your setup). Note, the \textbf{mailcommand} and 74\textbf{operatorcommand} should be on a single line. They were split here for 75presentation: 76 77\begin{bVerbatim} 78Messages { 79 Name = Standard 80 mailcommand = "/home/bacula/bin/bsmtp -h localhost 81 -f \"\(Bacula\) %r\" 82 -s \"Bacula: %t %e of %c %l\" %r" 83 operatorcommand = "/home/bacula/bin/bsmtp -h localhost 84 -f \"\(Bacula\) %r\" 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 90} 91\end{bVerbatim} 92 93You will need to ensure that the \bdirectoryname{/home/bacula/bin} path on the 94\textbf{mailcommand} and the \textbf{operatorcommand} lines point to your \textbf{\bacula{}} 95binary directory where the \btool{bsmtp} program will be installed. You will 96also want to ensure that the \textbf{your-email-address} is replaced by your 97email address, and finally, you will also need to ensure that the 98\bdirectoryname{/home/bacula/bin/log} points to the file where you want to log all messages. 99 100With the above Messages resource, you will be notified by email of every Job 101that ran, all the output will be appended to the \bfilename{log} file you specify, 102all output will be directed to the console program, and all mount messages 103will be emailed to you. Note, some messages will be sent to multiple 104destinations. 105 106The form of the mailcommand is a bit complicated, but it allows you to 107distinguish whether the Job terminated in error or terminated normally. Please 108see the 109\bxlink{Mail}{blb:mailcommand}{main}{command} in the \bmainman{} for the 110 details of the substitution characters used above. 111 112Once you are totally comfortable with \bacula{} as I am, or if you have a large 113number of nightly Jobs as I do (eight), you will probably want to change the 114\textbf{Mail} command to \textbf{Mail On Error} which will generate an email message 115only if the Job terminates in error. If the Job terminates normally, no email 116message will be sent, but the output will still be appended to the log file as 117well as sent to the Console program. 118 119\section{Getting Email Notification to Work} 120\label{blb:email} 121\index[general]{Work!Getting Email Notification to} 122\index[general]{Getting Email Notification to Work} 123 124The section above describes how to get email notification of job status. 125Occasionally, however, users have problems receiving any email at all. In that 126case, the things to check are the following: 127 128\begin{bitemize} 129\item Ensure that you have a valid email address specified on your \textbf{Mail} 130 record in the Director's Messages resource. The email address should be fully 131 qualified. Simply using \texttt{root} generally will not work, rather you should 132use \url{root@localhost} or better yet your full domain. 133\item Ensure that you do not have a \textbf{Mail} record in the Storage daemon's 134 or File daemon's configuration files. The only record you should have is 135 \textbf{director}: 136 137\begin{bVerbatim} 138director = director-name = all 139\end{bVerbatim} 140 141\item If all else fails, try replacing the \textbf{mailcommand} with 142 143\begin{bVerbatim} 144mailcommand = "mail -s test your@domain.com" 145\end{bVerbatim} 146 147\item Once the above is working, assuming you want to use \btool{bsmtp}, submit 148 the desired \btool{bsmtp} command by hand and ensure that the email is delivered, 149 then put that command into \textbf{\bacula{}}. Small differences in things such as 150the parenthesis around the word \bacula{} can make a big difference to some 151bsmtp programs. For example, you might start simply by using: 152 153\begin{bVerbatim} 154mailcommand = "/home/bacula/bin/bsmtp -f \"root@localhost\" %r" 155\end{bVerbatim} 156 157\end{bitemize} 158 159\section{Getting Notified that \bacula{} is Running} 160\label{blb:JobNotification} 161\index[general]{Running!Getting Notified that \bacula{} is} 162\index[general]{Getting Notified that \bacula{} is Running} 163 164If like me, you have setup \bacula{} so that email is sent only when a Job has 165errors, as described in the previous section of this chapter, inevitably, one 166day, something will go wrong and \textbf{\bacula{}} can stall. This could be because 167\bacula{} crashes, which is vary rare, or more likely the network has caused 168\textbf{\bacula{}} to \textbf{hang} for some unknown reason. 169 170To avoid this, you can use the \textbf{RunAfterJob} command in the Job resource 171to schedule a Job nightly, or weekly that simply emails you a message saying 172that \bacula{} is still running. For example, I have setup the following Job in 173my Director's configuration file: 174 175\begin{bVerbatim} 176Schedule { 177 Name = "Watchdog" 178 Run = Level=Full sun-sat at 6:05 179} 180Job { 181 Name = "Watchdog" 182 Type = Admin 183 Client=Watchdog 184 FileSet="Verify Set" 185 Messages = Standard 186 Storage = DLTDrive 187 Pool = Default 188 Schedule = "Watchdog" 189 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d" 190} 191Client { 192 Name = Watchdog 193 Address = rufus 194 FDPort = 9102 195 Catalog = Verify 196 Password = "" 197 File Retention = 1day 198 Job Retention = 1 month 199 AutoPrune = yes 200} 201\end{bVerbatim} 202 203Where I established a schedule to run the Job nightly. The Job itself is type 204\textbf{Admin} which means that it doesn't actually do anything, and I've defined 205a FileSet, Pool, Storage, and Client, all of which are not really used (and 206probably don't need to be specified). The key aspect of this Job is the 207command: 208 209\begin{bVerbatim} 210 RunAfterJob = "/home/kern/bacula/bin/watchdog %c %d" 211\end{bVerbatim} 212 213which runs my "watchdog" script. As an example, I have added the Job codes 214\%c and \%d which will cause the Client name and the Director's name to be 215passed to the script. For example, if the Client's name is \textbf{Watchdog} and 216the Director's name is \textbf{main-dir} then referencing \$1 in the script would 217get \textbf{Watchdog} and referencing \$2 would get \textbf{main-dir}. In this case, 218having the script know the Client and Director's name is not really useful, 219but in other situations it may be. 220 221You can put anything in the watchdog script. In my case, I like to monitor the 222size of my catalog to be sure that \textbf{\bacula{}} is really pruning it. The 223following is my watchdog script: 224 225\begin{bVerbatim} 226#!/bin/sh 227cd /home/kern/mysql/var/bacula 228du . * | 229/home/kern/bacula/bin/bsmtp \ 230 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \ 231 -s "Bacula running" abuse@whitehouse.com 232\end{bVerbatim} 233 234If you just wish to send yourself a message, you can do it with: 235 236\begin{bVerbatim} 237#!/bin/sh 238cd /home/kern/mysql/var/bacula 239/home/kern/bacula/bin/bsmtp \ 240 -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \ 241 -s "Bacula running" abuse@whitehouse.com <<END-OF-DATA 242Bacula is still running!!! 243END-OF-DATA 244\end{bVerbatim} 245 246\section{Maintaining a Valid Bootstrap File} 247\label{blb:bootstrap} 248\index[general]{Maintaining a Valid Bootstrap File} 249\index[general]{File!Maintaining a Valid Bootstrap} 250 251By using a \bxdlink{WriteBootstrap}{blb:writebootstrap}{main}{chapter} record in each of your 252Director's Job resources (\bmainman{}), you can constantly maintain a 253\bxdlink{bootstrap}{blb:BootstrapChapter}{main}{chapter} file that will enable you to 254recover the state of your system as of the last backup without having the 255\bacula{} catalog. This permits you to more easily recover from a disaster that 256destroys your \bacula{} catalog. 257 258When a Job resource has a \textbf{WriteBootstrap} record, \bacula{} will maintain 259the designated file (normally on another system but mounted by \acs{NFS}) with up to 260date information necessary to restore your system. For example, in my 261Director's configuration file, I have the following record: 262 263\begin{bVerbatim} 264 Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr" 265\end{bVerbatim} 266 267where I replace \textbf{client-name} by the actual name of the client that is 268being backed up. Thus, \bacula{} automatically maintains one file for each of my 269clients. The necessary bootstrap information is appended to this file during 270each \textbf{Incremental} backup, and the file is totally rewritten during each 271\textbf{Full} backup. 272 273Note, one disadvantage of writing to an \acs{NFS} mounted volume as I do is 274that if the other machine goes down, the OS will wait forever on the fopen() 275call that \bacula{} makes. As a consequence, \bacula{} will completely stall until 276the machine exporting the \acs{NFS} mounts comes back up. A possible solution to this 277problem was provided by Andrew Hilborne, and consists of using the \textbf{soft} 278option instead of the \textbf{hard} option when mounting the \acs{NFS} volume, which is 279typically done in \bfilename{/etc/fstab}/. The \acs{NFS} documentation explains these 280options in detail. However, I found that with the \textbf{soft} option 281\acs{NFS} disconnected frequently causing even more problems. 282 283If you are starting off in the middle of a cycle (i.e. with Incremental 284backups) rather than at the beginning (with a Full backup), the 285\textbf{bootstrap} file will not be immediately valid as it must always have the 286information from a Full backup as the first record. If you wish to synchronize 287your bootstrap file immediately, you can do so by running a \bcommandname{restore} 288command for the client and selecting a full restore, but when the \bcommandname{restore} 289command asks for confirmation to run the restore Job, you simply reply no, 290then copy the bootstrap file that was written to the location specified on the 291\textbf{Write Bootstrap} record. The restore bootstrap file can be found in 292\bfilename{restore.bsr} in the working directory that you defined. In the example given 293below for the client \textbf{rufus}, my input is shown in bold. Note, the JobId 294output has been partially truncated to fit on the page here: 295 296\begin{bVerbatim} 297(in the Console program) 298*restore 299First you select one or more JobIds that contain files 300to be restored. You will then be presented several methods 301of specifying the JobIds. Then you will be allowed to 302select which files from those JobIds are to be restored. 303To select the JobIds, you have the following choices: 304 1: List last 20 Jobs run 305 2: List Jobs where a given File is saved 306 3: Enter list of JobIds to select 307 4: Enter SQL list command 308 5: Select the most recent backup for a client 309 6: Cancel 310Select item: (1-6): 5 311The defined Client resources are: 312 1: Minimatou 313 2: Rufus 314 3: Timmy 315Select Client (File daemon) resource (1-3): 2 316The defined FileSet resources are: 317 1: Other Files 318Item 1 selected automatically. 319+-------+------+-------+---------+---------+------+-------+------------+ 320| JobId | Levl | Files | StrtTim | VolName | File | SesId | VolSesTime | 321+-------+------+-------+---------+---------+------+-------+------------+ 322| 2 | F | 84 | ... | test1 | 0 | 1 | 1035645259 | 323+-------+------+-------+---------+---------+------+-------+------------+ 324You have selected the following JobId: 2 325Building directory tree for JobId 2 ... 326The defined Storage resources are: 327 1: File 328Item 1 selected automatically. 329You are now entering file selection mode where you add and 330remove files to be restored. All files are initially added. 331Enter "done" to leave this mode. 332cwd is: / 333$ done 33484 files selected to restore. 335Run Restore job 336JobName: kernsrestore 337Bootstrap: /home/kern/bacula/working/restore.bsr 338Where: /tmp/bacula-restores 339FileSet: Other Files 340Client: Rufus 341Storage: File 342JobId: *None* 343OK to run? (yes/mod/no): no 344quit 345(in a shell window) 346cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr 347\end{bVerbatim} 348 349\section{Rejected Volumes After a Crash} 350\label{blb:RejectedVolumes} 351\index[general]{Crash!Rejected Volumes After a} 352\index[general]{Rejected Volumes After a Crash} 353 354\bacula{} keeps a count of the number of files on each Volume in its Catalog 355database so that before appending to a tape, it can verify that the number of 356files are correct, and thus prevent overwriting valid data. If the Director or 357the Storage daemon crashes before the job has completed, the tape will contain 358one more file than is noted in the Catalog, and the next time you attempt to 359use the same Volume, \bacula{} will reject it due to a mismatch between the 360physical tape (Volume) and the catalog. 361 362The easiest solution to this problem is to label a new tape and start fresh. 363If you wish to continue appending to the current tape, you can do so by using 364the \bcommandname{update} command in the console program to change the 365\textbf{Volume Files} entry in the catalog. A typical sequence of events would go like the 366following: 367 368\begin{bVerbatim} 369- Bacula crashes 370- You restart Bacula 371\end{bVerbatim} 372 373\bacula{} then prints: 374 375\begin{bVerbatim} 37617-Jan-2003 16:45 rufus-dir: Start Backup JobId 13, 377 Job=kernsave.2003-01-17_16.45.46 37817-Jan-2003 16:45 rufus-sd: Volume test01 previously written, 379 moving to end of data. 38017-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error: 381 I cannot write on this volume because: 382 The number of files mismatch! Volume=11 Catalog=10 38317-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting. 384 Cannot find any appendable volumes. 385Please use the "label" command to create a new Volume for: 386 Storage: SDT-10000 387 Media type: DDS-4 388 Pool: Default 389\end{bVerbatim} 390 391(note, lines wrapped for presentation) 392The key here is the line that reads: 393 394\begin{bVerbatim} 395 The number of files mismatch! Volume=11 Catalog=10 396\end{bVerbatim} 397 398It says that \bacula{} found eleven files on the volume, but that the catalog 399says there should be ten. When you see this, you can be reasonably sure that 400the SD was interrupted while writing before it had a chance to update the 401catalog. As a consequence, you can just modify the catalog count to eleven, 402and even if the catalog contains references to files saved in file 11, 403everything will be OK and nothing will be lost. Note that if the SD had 404written several file marks to the volume, the difference between the Volume 405count and the Catalog count could be larger than one, but this is unusual. 406 407If on the other hand the catalog is marked as having more files than \bacula{} 408found on the tape, you need to consider the possible negative consequences of 409modifying the catalog. Please see below for a more complete discussion of 410this. 411 412Continuing with the example of \textbf{Volume = 11 Catalog = 10}, to enable to 413\bacula{} to append to the tape, you do the following: 414 415\begin{bVerbatim} 416update 417Update choice: 418 1: Volume parameters 419 2: Pool from resource 420 3: Slots from autochanger 421Choose catalog item to update (1-3): 1 422Defined Pools: 423 1: Default 424 2: File 425Select the Pool (1-2): 426+-------+---------+--------+---------+-----------+------+----------+------+-----+ 427| MedId | VolName | MedTyp | VolStat | VolBytes | Last | VolReten | Recy | Slt | 428+-------+---------+--------+---------+-----------+------+----------+------+-----+ 429| 1 | test01 | DDS-4 | Error | 352427156 | ... | 31536000 | 1 | 0 | 430+-------+---------+--------+---------+-----------+------+----------+------+-----+ 431Enter MediaId or Volume name: 1 432\end{bVerbatim} 433 434(note table output truncated for presentation) First, you chose to update the 435Volume parameters by entering a \textbf{1}. In the volume listing that follows, 436notice how the VolStatus is \textbf{Error}. We will correct that after changing 437the Volume Files. Continuing, you respond 1, 438 439\begin{bVerbatim} 440Updating Volume "test01" 441Parameters to modify: 442 1: Volume Status 443 2: Volume Retention Period 444 3: Volume Use Duration 445 4: Maximum Volume Jobs 446 5: Maximum Volume Files 447 6: Maximum Volume Bytes 448 7: Recycle Flag 449 8: Slot 450 9: Volume Files 451 10: Pool 452 11: Done 453Select parameter to modify (1-11): 9 454Warning changing Volume Files can result 455in loss of data on your Volume 456Current Volume Files is: 10 457Enter new number of Files for Volume: 11 458New Volume Files is: 11 459Updating Volume "test01" 460Parameters to modify: 461 1: Volume Status 462 2: Volume Retention Period 463 3: Volume Use Duration 464 4: Maximum Volume Jobs 465 5: Maximum Volume Files 466 6: Maximum Volume Bytes 467 7: Recycle Flag 468 8: Slot 469 9: Volume Files 470 10: Pool 471 11: Done 472Select parameter to modify (1-10): 1 473\end{bVerbatim} 474 475Here, you have selected \textbf{9} in order to update the Volume Files, then you 476changed it from \textbf{10} to \textbf{11}, and you now answer \textbf{1} to change the 477Volume Status. 478 479\begin{bVerbatim} 480Current Volume status is: Error 481Possible Values are: 482 1: Append 483 2: Archive 484 3: Disabled 485 4: Full 486 5: Used 487 6: Read-Only 488Choose new Volume Status (1-6): 1 489New Volume status is: Append 490Updating Volume "test01" 491Parameters to modify: 492 1: Volume Status 493 2: Volume Retention Period 494 3: Volume Use Duration 495 4: Maximum Volume Jobs 496 5: Maximum Volume Files 497 6: Maximum Volume Bytes 498 7: Recycle Flag 499 8: Slot 500 9: Volume Files 501 10: Pool 502 11: Done 503Select parameter to modify (1-11): 11 504Selection done. 505\end{bVerbatim} 506 507At this point, you have changed the Volume Files from \textbf{10} to \textbf{11} to 508account for the last file that was written but not updated in the database, 509and you changed the Volume Status back to \textbf{Append}. 510 511This was a lot of words to describe something quite simple. 512 513The \textbf{Volume Files} option exists only in version 1.29 and later, and you 514should be careful using it. Generally, if you set the value to that which 515\bacula{} said is on the tape, you will be OK, especially if the value is one 516more than what is in the catalog. 517 518Now lets consider the case: 519 520\begin{bVerbatim} 521 The number of files mismatch! Volume=10 Catalog=12 522\end{bVerbatim} 523 524Here the \bacula{} found fewer files on the volume than what is marked in the 525catalog. Now, in this case, you should hesitate a lot before modifying the count 526in the catalog, because if you force the catalog from 12 to 10, \bacula{} will 527start writing after the file 10 on the tape, possibly overwriting valid data, 528and if you ever try to restore any of the files that the catalog has marked as 529saved on Files 11 and 12, all chaos will break out. In this case, you will 530probably be better off using a new tape. In fact, you might want to see what 531files the catalog claims are actually stored on that Volume, and back them up 532to another tape and recycle this tape. 533 534\section{Security Considerations} 535\label{blb:security} 536\index[general]{Considerations!Security} 537\index[general]{Security Considerations} 538 539Only the File daemon needs to run with root permission (so that it can access 540all files). As a consequence, you may run your Director, Storage daemon, and 541MySQL or PostgreSQL database server as non-root processes. Version 1.30 has 542the \textbf{-u} and the \textbf{-g} options that allow you to specify a userid and 543groupid on the command line to be used after \bacula{} starts. 544 545As of version 1.33, thanks to Dan Langille, it is easier to configure the 546\bacula{} Director and Storage daemon to run as non-root. 547 548You should protect the \bacula{} port addresses (normally 9101, 9102, and 9103) 549from outside access by a firewall or other means of protection to prevent 550unauthorized use of your daemons. 551 552You should ensure that the configuration files are not world readable since 553they contain passwords that allow access to the daemons. Anyone who can access 554the Director using a console program can restore any file from a backup 555Volume. 556 557You should protect your Catalog database. If you are using SQLite, make sure 558that the working directory is readable only by root (or your \bacula{} userid), 559and ensure that \textbf{bacula.db} has permissions \textbf{-rw-r{-}{-}r{-}{-}} (i.e. 640) or 560more strict. If you are using MySQL or PostgreSQL, please note that the \bacula{} 561setup procedure leaves the database open to anyone. At a minimum, you should 562assign the user \texttt{bacula} a userid and add it to your Director's 563configuration file in the appropriate Catalog resource. 564 565If you use the make\_catalog\_backup script provided by \bacula{}, remember that 566you should take care when supplying passwords on the command line. Read the 567\bilink{Backing Up Your \bacula{} Database --- Security Considerations}{blb:BackingUpBaculaSecurityConsiderations} 568section for more information. 569 570\section{Creating Holiday Schedules} 571\label{blb:holiday} 572\index[general]{Schedules!Creating Holiday} 573\index[general]{Creating Holiday Schedules} 574 575If you normally change tapes every day or at least every Friday, but Thursday 576is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no 577job runs on Thursday so that you can insert Friday's tape and be sure it will 578be used on Friday. To do so, define a \textbf{RunJobBefore} script that normally 579returns zero, so that the \bacula{} job will normally continue. You can then 580modify the script to return non-zero on any day when you do not want \bacula{} to 581run the job. 582 583\section{Automatic Labeling Using Your Autochanger} 584\label{blb:autolabel} 585\index[general]{Automatic Labeling Using Your Autochanger} 586\index[general]{Autochanger!Automatic Labeling Using Your} 587 588If you have an autochanger but it does not support barcodes, using a "trick" 589you can make \bacula{} automatically label all the volumes in your autochanger's 590magazine. 591 592First create a file containing one line for each slot in your autochanger that 593has a tape to be labeled. The line will contain the slot number a colon (:) 594then the Volume name you want to use. For example, create a file named 595\textbf{volume-list}, which contains: 596 597\begin{bVerbatim} 5981:Volume001 5992:TestVolume02 6005:LastVolume 601\end{bVerbatim} 602 603The records do not need to be in any order and you don't need to mention all 604the slots. Normally, you will have a consistent set of Volume names and a 605sequential set of numbers for each slot you want labeled. In the example 606above, I've left out slots 3 and 4 just as an example. Now, modify your 607\mtxchanger{} script and comment out all the lines in the \textbf{list)} case by 608putting a \# in column 1. Then add the following two lines: 609 610\begin{bVerbatim} 611cat <absolute-path>/volume-list 612exit 0 613\end{bVerbatim} 614 615so that the whole case looks like: 616 617\begin{bVerbatim} 618list) 619# 620# commented out lines 621cat <absolute-path>/volume-list 622exit 0 623;; 624\end{bVerbatim} 625 626where you replace \bbracket{absolute-path} with the full path to the 627volume-list file. Then using the console, you enter the following command: 628 629\begin{bVerbatim} 630label barcodes 631\end{bVerbatim} 632 633and \bacula{} will proceed to mount the autochanger Volumes in the list and label 634them with the Volume names you have supplied. \bacula{} will think that the list 635was provided by the autochanger barcodes, but in reality, it was you who 636supplied the \bbracket{barcodes}. 637 638If it seems to work, when it finishes, enter: 639 640\begin{bVerbatim} 641list volumes 642\end{bVerbatim} 643 644and you should see all the volumes nicely created. 645 646\section{Backing Up Portables Using \acs{DHCP}} 647\label{blb:DNS} 648\index[general]{\acs{DHCP}!Backing Up Portables Using} 649\index[general]{Backing Up Portables Using \acs{DHCP}} 650 651You may want to backup laptops or portables that are not always connected to 652the network. If you are using \acs{DHCP} to assign an IP address to those machines 653when they connect, you will need to use the Dynamic Update capability of \acs{DNS} 654to assign a name to those machines that can be used in the Address field of 655the Client resource in the Director's conf file. 656 657\section{Going on Vacation} 658\label{blb:Vacation} 659\index[general]{Vacation!Going on} 660\index[general]{Going on Vacation} 661 662At some point, you may want to be absent for a week or two and you want to 663make sure \bacula{} has enough tape left so that the backups will complete. You 664start by doing a \textbf{list volumes} in the Console program: 665 666\begin{bVerbatim} 667list volumes 668 669Using default Catalog name=BackupDB DB=bacula 670Pool: Default 671+---------+---------------+-----------+-----------+----------------+- 672| MediaId | VolumeName | MediaType | VolStatus | VolBytes | 673+---------+---------------+-----------+-----------+----------------+- 674| 23 | DLT-30Nov02 | DLT8000 | Full | 54,739,278,128 | 675| 24 | DLT-21Dec02 | DLT8000 | Full | 56,331,524,629 | 676| 25 | DLT-11Jan03 | DLT8000 | Full | 67,863,514,895 | 677| 26 | DLT-02Feb03 | DLT8000 | Full | 63,439,314,216 | 678| 27 | DLT-03Mar03 | DLT8000 | Full | 66,022,754,598 | 679| 28 | DLT-04Apr03 | DLT8000 | Full | 60,792,559,924 | 680| 29 | DLT-28Apr03 | DLT8000 | Full | 62,072,494,063 | 681| 30 | DLT-17May03 | DLT8000 | Full | 65,901,767,839 | 682| 31 | DLT-07Jun03 | DLT8000 | Used | 56,558,490,015 | 683| 32 | DLT-28Jun03 | DLT8000 | Full | 64,274,871,265 | 684| 33 | DLT-19Jul03 | DLT8000 | Full | 64,648,749,480 | 685| 34 | DLT-08Aug03 | DLT8000 | Full | 64,293,941,255 | 686| 35 | DLT-24Aug03 | DLT8000 | Append | 9,999,216,782 | 687+---------+---------------+-----------+-----------+----------------+ 688\end{bVerbatim} 689 690Note, I have truncated the output for presentation purposes. What is 691significant, is that I can see that my current tape has almost 10 Gbytes of 692data, and that the average amount of data I get on my tapes is about 60 693Gbytes. So if I go on vacation now, I don't need to worry about tape capacity 694(at least not for short absences). 695 696Equally significant is the fact that I did go on vacation the 28th of June 6972003, and when I did the \bcommandname{list volumes} command, my current tape at that 698time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the 699tape would fill shortly. Consequently, I manually marked it as \textbf{Used} and 700replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring 701myself that the backups would all complete without my intervention. 702 703\section{Exclude Files on Windows Regardless of Case} 704\label{blb:Case} 705\index[general]{Exclude Files on Windows Regardless of Case} 706% TODO: should this be put in the win32 chapter? 707% TODO: should all these tips be placed in other chapters? 708 709This tip was submitted by Marc Brueckner who wasn't sure of the case of some 710of his files on Win32, which is case insensitive. The problem is that \bacula{} 711thinks that \textbf{/UNIMPORTANT FILES} is different from \textbf{/Unimportant 712Files}. Marc was aware that the file exclusion permits wild-cards. So, he 713specified: 714 715\begin{bVerbatim} 716"/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]" 717\end{bVerbatim} 718 719As a consequence, the above exclude works for files of any case. 720 721Please note that this works only in \bacula{} Exclude statement and not in 722Include. 723 724\section{Executing Scripts on a Remote Machine} 725\label{blb:RemoteExecution} 726\index[general]{Machine!Executing Scripts on a Remote} 727\index[general]{Executing Scripts on a Remote Machine} 728 729This tip also comes from Marc Brueckner. (Note, this tip is probably outdated 730by the addition of \textbf{ClientRunBeforJob} and \textbf{ClientRunAfterJob} Job 731records, but the technique still could be useful.) First I thought the "Run 732Before Job" statement in the Job-resource is for executing a script on the 733remote machine (the machine to be backed up). (Note, this is possible as mentioned 734above by using \textbf{ClientRunBeforJob} and \textbf{ClientRunAfterJob}). 735It could be useful to execute 736scripts on the remote machine e.g. for stopping databases or other services 737while doing the backup. (Of course I have to start the services again when the 738backup has finished) I found the following solution: \bacula{} could execute 739scripts on the remote machine by using ssh. The authentication is done 740automatically using a private key. First you have to generate a keypair. I've 741done this by: 742 743\begin{bVerbatim} 744ssh-keygen -b 4096 -t dsa -f Bacula_key 745\end{bVerbatim} 746 747This statement may take a little time to run. It creates a public/private key 748pair with no passphrase. You could save the keys in \bdirectoryname{/etc/bacula}. Now you have 749two new files : Bacula\_key which contains the private key and Bacula\_key.pub 750which contains the public key. 751 752Now you have to append the Bacula\_key.pub file to the file authorized\_keys 753in the \bdirectoryname{/root/.ssh} directory of the remote 754machine. Then you have to add (or uncomment) the line 755 756\begin{bVerbatim} 757AuthorizedKeysFile %h/.ssh/authorized_keys 758\end{bVerbatim} 759 760to the \bfilename{sshd\_config} file on the remote machine. Where the \%h stands for the 761home-directory of the user (root in this case). 762 763Assuming that your sshd is already running on the remote machine, you can now 764enter the following on the machine where \bacula{} runs: 765 766\begin{bVerbatim} 767ssh -i Bacula_key -l root <machine-name-or-ip-address> "ls -la" 768\end{bVerbatim} 769 770This should execute the \btool{ls -la} command on the remote machine. 771 772Now you could add lines like the following to your Director's conf file: 773 774\begin{bVerbatim} 775... 776Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \ 777 "/etc/init.d/database stop" 778Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 \ 779 "/etc/init.d/database start" 780... 781\end{bVerbatim} 782 783Even though \bacula{} version 1.32 and later has a ClientRunBeforeJob, the \btool{ssh} method still 784could be useful for updating all the \bacula{} clients on several remote machines 785in a single script. 786 787\section{Recycling All Your Volumes} 788\label{blb:recycle} 789\index[general]{Recycling All Your Volumes} 790\index[general]{Volumes!Recycling All Your} 791 792This tip comes from Phil Stracchino. 793 794If you decide to blow away your catalog and start over, the simplest way to 795re-add all your prelabeled tapes with a minimum of fuss (provided you don't 796care about the data on the tapes) is to add the tape labels using the console 797\bcommandname{add} command, then go into the catalog and manually set the VolStatus of 798every tape to \textbf{Recycle}. 799 800The \acs{SQL} command to do this is very simple, either use your vendor's 801command line interface (\mysql{}, \postgresql{}, \sqlite{},\ldots{}) or use the \bcommandname{sql} 802command in the \bacula{} console: 803 804\begin{bVerbatim} 805update Media set VolStatus='Recycle'; 806\end{bVerbatim} 807 808\bacula{} will then ignore the data already stored on the tapes and just re-use 809each tape without further objection. 810 811\section{Backing up ACLs on ext3 or XFS filesystems} 812\label{blb:ACLs} 813\index[general]{Filesystems!Backing up ACLs on ext3 or XFS} 814\index[general]{Backing up ACLs on ext3 or XFS filesystems} 815 816This tip comes from Volker Sauer. 817 818Note, this tip was given prior to implementation of \acsp{ACL} in \bacula{} (version 8191.34.5). It is left here because dumping/displaying \acsp{ACL} can still be useful 820in testing/verifying that \bacula{} is backing up and restoring your \acsp{ACL} 821properly. Please see the 822\bilink{aclsupport}{blb:ACLSupport} FileSet option in the configuration chapter of this manual. 823 824For example, you could dump the \acsp{ACL} to a file with a script similar to the 825following: 826 827\begin{bVerbatim} 828#!/bin/sh 829BACKUP_DIRS="/foo /bar" 830STORE_ACL=/root/acl-backup 831umask 077 832for i in $BACKUP_DIRS; do 833 cd $i /usr/bin/getfacl -R --skip-base .>$STORE_ACL/${i//\//_} 834done 835\end{bVerbatim} 836 837Then use \bacula{} to backup \bfilename{/root/acl-backup}. 838 839The \acsp{ACL} could be restored using \bacula{} to the \bfilename{/root/acl-backup} file, 840then restored to your system using: 841 842\begin{bVerbatim} 843setfacl --restore/root/acl-backup 844\end{bVerbatim} 845 846\section{Total Automation of \bacula{} Tape Handling} 847\label{blb:automate} 848\index[general]{Handling!Total Automation of \bacula{} Tape} 849\index[general]{Total Automation of \bacula{} Tape Handling} 850 851This tip was provided by Alexander Kuehn. 852 853\bfootref{\bacula{}}{http://www.bacula.org/} is a really nice backup program except 854that the manual tape changing requires user interaction with the bacula 855console. 856 857Fortunately I can fix this. 858NOTE!!! This suggestion applies for people who do \textbf{not} have tape autochangers 859and must change tapes manually.!!!!! 860 861\bacula{} supports a variety of tape changers through the use of \mtxchanger{} 862scripts/programs. This highly flexible approach allowed me to create 863\bfootref{this shell script}{http://www.bacula.org/en/rel-manual/mtx-changer.txt} which does the following: 864% TODO: We need to include this in book appendix and point to it. 865% TODO: 866Whenever a new tape is required it sends a mail to the operator to insert the 867new tape. Then it waits until a tape has been inserted, sends a mail again to 868say thank you and let's bacula continue its backup. 869So you can schedule and run backups without ever having to log on or see the 870console. 871To make the whole thing work you need to create a Device resource which looks 872something like this (\bog{}Archive Device\cog{}, \bog{}Maximum Changer Wait\cog{}, \bog{}Media Type\cog{} 873and \bog{}Label media\cog{} may have different values): 874 875\begin{bVerbatim} 876Device { 877 Name=DDS3 878 Archive Device = # use yours not mine! ;)/dev/nsa0 879 Changer Device = # not really required/dev/nsa0 880 Changer Command = "# use this (maybe change the path)! 881 /opt/bacula/scripts/mtx-changer %o %a %S" 882 Maximum Changer Wait = 3d # 3 days in seconds 883 AutomaticMount = yes; # mount on start 884 AlwaysOpen = yes; # keep device locked 885 Media Type = DDS3 # it's just a name 886 RemovableMedia = yes; # 887 Offline On Unmount = Yes; # keep this too 888 Label media = Yes; # 889} 890\end{bVerbatim} 891 892As the script has to emulate the complete wisdom of a \mtxchanger{} it has an 893internal \bog{}database\cog{} containing where which tape is stored, you can see this on 894the following line: 895 896\begin{bVerbatim} 897labels="VOL-0001 VOL-0002 VOL-0003 VOL-0004 VOL-0005 VOL-0006 898VOL-0007 VOL-0008 VOL-0009 VOL-0010 VOL-0011 VOL-0012" 899\end{bVerbatim} 900 901The above should be all on one line, and it effectively tells \bacula{} that 902volume \bog{}VOL-0001\cog{} is located in slot 1 (which is our lowest slot), that 903volume \bog{}VOL-0002\cog{} is located in slot 2 and so on. 904The script also maintains a logfile (\bfilename{/var/log/mtx.log}) where you can monitor 905its operation. 906 907\section{Running Concurrent Jobs} 908\label{blb:ConcurrentJobs} 909\index[general]{Jobs!Running Concurrent} 910\index[general]{Running Concurrent Jobs} 911\index[general]{Concurrent Jobs} 912 913\bacula{} can run multiple concurrent jobs, but the default configuration files 914do not enable it. Using the \textbf{Maximum Concurrent Jobs} directive, you 915can configure how many and which jobs can be run simultaneously. 916The Director's default value for \textbf{Maximum Concurrent Jobs} is \bdefaultvalue{1}. 917 918To initially setup concurrent jobs you need to define \textbf{Maximum Concurrent Jobs} in 919the Director's configuration file (\bfilename{bacula-dir.conf}) in the 920Director, Job, Client, and Storage resources. 921 922Additionally the File daemon, and the Storage daemon each have their own 923\textbf{Maximum Concurrent Jobs} directive that sets the overall maximum 924number of concurrent jobs the daemon will run. The default for both the 925File daemon and the Storage daemon is \bdefaultvalue{20}. 926 927For example, if you want two different jobs to run simultaneously backing up 928the same Client to the same Storage device, they will run concurrently only if 929you have set \textbf{Maximum Concurrent Jobs} greater than one in the Director 930resource, the Client resource, and the Storage resource in \bfilename{bacula-dir.conf}. 931 932We recommend that you read the \bilink{Data Spooling}{blb:SpoolingChapter} 933of this manual first, then test your multiple 934concurrent backup including restore testing before you put it into 935production. 936 937Below is a super stripped down \bfilename{bacula-dir.conf} file showing you the four 938places where the the file must be modified to allow the same job 939\textbf{NightlySave} to run up to four times concurrently. The change to the Job 940resource is not necessary if you want different Jobs to run at the same time, 941which is the normal case. 942 943\begin{bVerbatim} 944# 945# Bacula Director Configuration file -- bacula-dir.conf 946# 947Director { 948 Name = rufus-dir 949 Maximum Concurrent Jobs = 4 950 ... 951} 952Job { 953 Name = "NightlySave" 954 Maximum Concurrent Jobs = 4 955 Client = rufus-fd 956 Storage = File 957 ... 958} 959Client { 960 Name = rufus-fd 961 Maximum Concurrent Jobs = 4 962 ... 963} 964Storage { 965 Name = File 966 Maximum Concurrent Jobs = 4 967 ... 968} 969\end{bVerbatim} 970