Bacula 1.32 User's Guide | Chapter 15

Using Autochangers | Index | Utility Programs

# Tips and Suggestions

## Upgrading Bacula Versions

The first thing to do before upgrading from one version to another is to ensure that don't overwrite your production (current) version of Bacula until you have tested that the new version works.

If you have installed Bacula into a single directory, this is simple: simply make a copy of your Bacula directory.

If you have done a more typical Unix installation where the binaries are placed in one directory and the configuration files are placed in another, then the simplest way is to configure your new Bacula to go into a single file.

Whatever your situation may be (one of the two just described), you should probably start with the defaultconf script that can be found in the examples subdirectory. Copy this script to the main Bacula directory, modify it as necessary (there should not need to be many modifications), configure Bacula, build it, install it, then stop your production Bacula, copy all the *.conf files from your production Bacula directory to the test Bacula directory, start the test version, and run a few test backups. If all seems good, then you can proceed to install the new Bacula in place of or possibly over the old Bacula.

When installing a new Bacula you need not worry about losing the changes you made to your configuration files as the installation process will not overwrite them.

## Getting Notified of Job Completion

One of the first things you should do is to ensure that you are being properly notified of the status of each Job run by Bacula, or at a minimum of each Job that terminates with an error.

Until you are completely comfortable with Bacula, we recommend that you send an email to yourself for each Job that is run. This is most easily accomplished by adding an email notification address in the Messages resource of your Director's configuration file. An email is automatically configured in the default configuration files, but you must ensure that the default root address is replaced by your email address.

For examples of how I (Kern) configure my system, please take a look at the .conf files found in the examples sub-directory. We recommend the following configuration (where you change the paths and email address to correspond to your setup). Note, the mailcommand and operatorcommand should be on a single line. They were split here for presentation:

    Messages {
      Name = Standard
      mailcommand = "/home/bacula/bin/smtp -h localhost -f \"\(Bacula\) %r\"
                    -s \"Bacula: %t %e of %c %l\" %r"
      operatorcommand = "/home/bacula/bin/smtp -h localhost -f \"\(Bacula\) %r\"
                        -s \"Bacula: Intervention needed for %j\" %r"
      Mail = your-email-address = all, !skipped, !terminate
      append = "/home/bacula/bin/log" = all, !skipped, !terminate
      operator = your-email-address = mount
      console = all, !skipped, !saved
    }

You will need to ensure that the /home/bacula/bin path on the mailcommand and the operatorcommand lines points to your Bacula binary directory where the smtp program will be installed. You will also want to ensure that the your-email-address is replaced by your email address, and finally, you will also need to ensure that the /home/bacula/bin/log points to the file where you want to log all messages.

With the above Messages resource, you will be notified by email of every Job that ran, all the output will be appended to the log file you specify, all output will be directed to the console program, and all mount messages will be emailed to you. Note, some messages will be sent to multiple destinations.

The form of the mailcommand is a bit complicated, but it allows you to distinguish whether the Job terminated in error or terminated normally. Please see the Mail Command section of the Messages Resource chapter of this manual for the details of the substitution characters used above.

Once you are totally comfortable with Bacula as I am, or if you have a large number of nightly Jobs as I do (eight), you will probably want to change the Mail command to Mail On Error which will generate an email message only if the Job terminates in error. If the Job terminates normally, no email message will be sent, but the output will still be appended to the log file as well as sent to the Console program.

## Getting Email Notification to Work

The section above describes how to get email notification of job status. Occasionally, however, users have problems receiving any email at all. In that case, the things to check are the following:

- Ensure that you have a valid email address specified on your Mail record in the Director's Messages resource. The email address should be fully qualified. Simply using root generally will not work, rather you should use root@localhost or better yet your full domain.
- Ensure that you do not have a Mail record in the Storage daemon's or File daemon's configuration files. The only record you should have is director:

            director = director-name = all

- If all else fails, try replacing the mailcommand with

            mailcommand = "mail -s test your-email@domain.com"

- Once the above is working, assuming you want to use smtp, submit the desired smtp command by hand and ensure that the email is delivered, then put that command into Bacula. Small differences in things such as the parenthesis around the word Bacula can make a big difference to some smtp programs. For example, you might start simply by using:

               mailcommand = "/home/bacula/bin/smtp -f \"root@localhost\" %r"

## Getting Notified that Bacula is Running

If like me, you have setup Bacula so that email is sent only when a Job has errors, as described in the previous section of this chapter, inevitably, one day, something will go wrong and Bacula can stall. This could be because Bacula crashes, which is vary rare, or more likely the network has caused Bacula to hang for some unknown reason.

To avoid this, you can use the RunAfterJob command in the Job resource to schedule a Job nightly, or weekly that simply emails you a message saying that Bacula is still running. For example, I have setup the following Job in my Director's configuration file:

    Schedule {
      Name = "Watchdog"
      Run = Level=Full sun-sat at 6:05
    }

    Job {
      Name = "Watchdog"
      Type = Admin
      Client=Watchdog
      FileSet="Verify Set"
      Messages = Standard
      Storage = DLTDrive
      Pool = Default
      Schedule = "Watchdog"
      RunAfterJob = "/home/kern/bacula/bin/watchdog"
    }

    Client {
      Name = Watchdog
      Address = rufus
      FDPort = 9102
      Catalog = Verify
      Password = ""
      File Retention = 1d                 # 1 days
      Job Retention = 1m                  # 1 month
      AutoPrune = yes                     # Prune expired Jobs/Files
    }

Where I established a schedule to run the Job nightly. The Job itself is type Admin which means that it doesn't actually do anything, and I've defined a FileSet, Pool, Storage, and Client, all of which are not really used (and probably don't need to be specified). The key aspect of this Job is the command:

      RunAfterJob = "/home/kern/bacula/bin/watchdog"

which runs my "watchdog" script. You can put anything in the watchdog scrip. In my case, I like to monitor the size of my catalog to be sure that Bacula is really pruning it. The following is my watchdog script:

    #!/bin/sh
    cd /home/kern/mysql/var/bacula
    du . * |
    /home/kern/bacula/bin/smtp -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
                               -s "Bacula running" abuse@whitehouse.com

If you just wish to send yourself a message, you can do it with:

    #!/bin/sh
    cd /home/kern/mysql/var/bacula
    /home/kern/bacula/bin/smtp -f "\(Bacula\) abuse@whitehouse.com" -h mail.yyyy.com \
                               -s "Bacula running" abuse@whitehouse.com <<END-OF-DATA
    Bacula is still running!!!
    END-OF-DATA

## Maintaining a Valid Bootstrap File

By using a WriteBootstrap record in each of your Director's Job resources, you can constantly maintain a bootstrap file that will enable you to recover the state of your system as of the last backup without having the Bacula catalog. This permits you to more easily recover from a disaster that destroys your Bacula catalog.

When a Job resource has a WriteBootstrap record, Bacula will maintain the designated file (normally on another system but mounted by NSF) with up to date information necessary to restore your system. For example, in my Director's configuration file, I have the following record:

     Write Bootstrap = "/mnt/deuter/files/backup/client-name.bsr"

where I replace client-name by the actual name of the client that is being backed up. Thus, Bacula automatically maintains one file for each of my clients. The necessary bootstrap information is appended to this file during each Incremental backup, and the file is totally rewritten during each Full backup.

Note, one major disadvantage of writing to a NFS mounted volume as I do is that if the other machine goes down, the OS will wait forever on the fopen() call that Bacula makes. As a consequence, Bacula will completely stall until the machine exporting the NSF mounts comes back up. If someone knows a way around this, please let me know.

If you are starting off in the middle of a cycle (i.e. with Incremental backups) rather than at the beginning (with a Full backup), the bootstrap file will not be immediately valid as it must always have the information from a Full backup as the first record. If you wish to synchronize your bootstrap file immediately, you can do so by running a restore command for the client and selecting a full restoration, but when the restore command asks for confirmation to run the restore Job, you simply reply no, then copy the bootstrap file that was written to the location specified on the Write Bootstrap record. The restore bootstrap file can be found in restore.bsr in the working directory that you defined. In the example given below for the client rufus, my input is shown in bold. Note, the JobId output has been partially truncated to fit on the page here:

    (in the Console program)
    *restore
    First you select one or more JobIds that contain files
    to be restored. You will be presented several methods
    of specifying the JobIds. Then you will be allowed to
    select which files from those JobIds are to be restored.

    To select the JobIds, you have the following choices:
         1: List last 20 Jobs run
         2: List Jobs where a given File is saved
         3: Enter list of JobIds to select
         4: Enter SQL list command
         5: Select the most recent backup for a client
         6: Cancel
    Select item:  (1-6): 5
    The defined Client resources are:
         1: Minimatou
         2: Rufus
         3: Timmy
    Select Client (File daemon) resource (1-3): 2
    The defined FileSet resources are:
         1: Kerns Files
    Item 1 selected automatically.

    +-------+-------+----------+-----------+---------+---------+----------+------------+
    | JobId | Level | JobFiles | StartTime | VolName | StrtFil | VolSesId | VolSesTime |
    +-------+-------+----------+-----------+---------+---------+----------+------------+
    | 2     | F     | 84       |  ...      | test1   | 0       | 1        | 1035645259 |
    +-------+-------+----------+-----------+---------+---------+----------+------------+

    You have selected the following JobId: 2
    Building directory tree for JobId 2 ...

    The defined Storage resources are:
         1: File
    Item 1 selected automatically.

    You are now entering file selection mode where you add and
    remove files to be restored. All files are initially added.
    Enter "done" to leave this mode.

    cwd is: /
    $ done

    84 files selected to restore.

    Run Restore job
    JobName:    kernsrestore
    Bootstrap:  /home/kern/bacula/working/restore.bsr
    Where:      /tmp/bacula-restores
    FileSet:    Kerns Files
    Client:     Rufus
    Storage:    File
    JobId:      *None*
    OK to run? (yes/mod/no): no
    quit

    (in a shell window)
    cp ../working/restore.bsr /mnt/deuter/files/backup/rufus.bsr

## Rejected Volumes After a Crash

Bacula keeps the number of files on each Volume in its Catalog database so that before appending to a tape, it can verify that the number of files are correct, and thus prevent overwriting valid data. If the Director or the Storage daemon crashes before the job has completed, the tape will contain one more file than is noted in the Catalog, and the next time you attempt to use the same Volume, Bacula will reject it due to a mismatch between the physical tape and the catalog.

The easiest solution to this problem is to label a new tape and start fresh. If you wish to continue appending to the current tape, you can do so by using the update command in the console program to change the Volume Files entry in the catalog. A typical sequence of events would go like the following:

    - Bacula crashes
    - You restart Bacula

Bacula then prints:

    17-Jan-2003 16:45 rufus-dir: Start Backup JobId 13,
                      Job=kernsave.2003-01-17_16.45.46
    17-Jan-2003 16:45 rufus-sd: Volume test01 previously written,
                      moving to end of data.
    17-Jan-2003 16:46 rufus-sd: kernsave.2003-01-17_16.45.46 Error:
                      I cannot write on this volume because:
                      The number of files mismatch! Volume=11 Catalog=10
    17-Jan-2003 16:46 rufus-sd: Job kernsave.2003-01-17_16.45.46 waiting.
                       Cannot find any appendable volumes.
    Please use the "label"  command to create a new Volume for:
        Storage:      SDT-10000
        Media type:   DDS-4
        Pool:         Default

(note, lines wrapped for presentation)
To get out of this situation and use the same tape, you do the following:

    update
    Update choice:
         1: Volume parameters
         2: Pool from resource
         3: Slots from autochanger
    Choose catalog item to update (1-3): 1
    Defined Pools:
         1: Default
         2: File
    Select the Pool (1-2):

    +---------+---------+-----------+-----------+-----------+------+----------+------+------+
    | MediaId | VolName | MediaType | VolStatus | VolBytes  | Last | VolReten | Recy | Slot |
    +---------+---------+-----------+-----------+-----------+------+----------+------+------+
    | 1       | test01  | DDS-4     | Error     | 352427156 | ...  | 31536000 | 1    | 0    |
    +---------+---------+-----------+-----------+-----------+------+----------+------+------+

    Enter MediaId or Volume name: 1

(note table output truncated for presentation) First, you chose to update the Volume parameters by entering a 1. In the volume listing that follows, notice how the VolStatus is Error. We will correct that after changing the Volume Files. Continuing, you respond 1,

    Updating Volume "test01"
    Parameters to modify:
         1: Volume Status
         2: Volume Retention Period
         3: Volume Use Duration
         4: Maximum Volume Jobs
         5: Maximum Volume Files
         6: Maximum Volume Bytes
         7: Recycle Flag
         8: Slot
         9: Volume Files
        10: Pool
        11: Done
    Select parameter to modify (1-11): 9
    Warning changing Volume Files can result
    in loss of data on your Volume

    Current Volume Files is: 10
    Enter new number of Files for Volume: 11
    New Volume Files is: 11
    Updating Volume "test01"
    Parameters to modify:
         1: Volume Status
         2: Volume Retention Period
         3: Volume Use Duration
         4: Maximum Volume Jobs
         5: Maximum Volume Files
         6: Maximum Volume Bytes
         7: Recycle Flag
         8: Slot
         9: Volume Files
        10: Pool
        11: Done
    Select parameter to modify (1-10): 1

Here, you have selected 9 in order to update the Volume Files, then you changed it from 10 to 11, and you now answer 1 to change the Volume Status.

    Current Volume status is: Error
    Possible Values are:
         1: Append
         2: Archive
         3: Disabled
         4: Full
         5: Used
         6: Read-Only
    Choose new Volume Status (1-6): 1
    New Volume status is: Append
    Updating Volume "test01"
    Parameters to modify:
         1: Volume Status
         2: Volume Retention Period
         3: Volume Use Duration
         4: Maximum Volume Jobs
         5: Maximum Volume Files
         6: Maximum Volume Bytes
         7: Recycle Flag
         8: Slot
         9: Volume Files
        10: Pool
        11: Done
    Select parameter to modify (1-11): 11
    Selection done.

At this point, you have changed the Volume Files from 10 to 11 to account for the last file being written but not updated in the database, and you changed the Volume Status back to Append.

This was a lot of words to describe something quite simple.

The Volume Files option exists only in version 1.29 and later, and you should be careful using it. Generally, if you set the value to that which Bacula said is on the tape, you will be OK, especially if the value is one more than what is in the catalog.

## Security Considerations

Only the File daemon needs to run with root permission (so that it can access all files). As a consequence, you may run your Director, Storage daemon, and MySQL database server as non-root processes. Version 1.30 has the -u and the -g options that allow you to specify a userid and groupid on the command line to be used after Bacula starts.

You should protect the Bacula port addresses (normally 9101, 9102, and 9103) from outside access by a firewall or other means of protection to prevent unauthorized use of your daemons.

You should ensure that the configuration files are not world readable since they contain passwords that allow access to the daemons. Anyone who can access the Director using a console program can restore any file from a backup Volume.

You should protect your Catalog database. If you are using SQLite, make sure that the working directory is readable only by root (or your Bacula userid), and ensure that bacula.db has permissions -rw-r--r-- (i.e. 640) or more strict. If you are using MySQL, please note that the Bacula setup procedure leaves the database open to anyone. At a minimum, you should assign the user bacula a userid and add it to your Director's configuration file in the appropriate Catalog resource.

## Creating Holiday Schedules

If you normally change tapes every day or at least every Friday, but Thursday is a holiday, you can use a trick proposed by Lutz Kittler to ensure that no job runs on Thursday so that you can insert Friday's tape and be sure it will be used on Friday. To do so, define a RunJobBefore script that normally returns zero, so that the Bacula job will normally continue. You can then modify the script to return non-zero on any day when you do not want Bacula to run the job.

## Automatic Labeling Using Your Autochanger

If you have an autochanger but it does not support barcodes, using a "trick" you can make Bacula automatically label all the volumes in your autochanger's magazine.

First create a file containing one line for each slot in your autochanger that has a tape to be labeled. The line will contain the slot number a colon (:) then the Volume name you want to use. For example, create a file named volume-list, which contains:

    1:Volume001
    2:TestVolume02
    5:LastVolume

The records do not need to be in any order and you don't need to mention all the slots. Normally, you will have a consistent set of Volume names and a sequential set of numbers for each slot you want labeled. In the example above, I've left out slots 3 and 4 just as an example. Now, modify your mtx-changer script and comment out all the lines in the list) case by putting a # in column 1. Then add the following two lines:

      cat <absolute-path>/volume-list
      exit 0

so that the whole case looks like:

      list)
    #
    # commented out lines
       cat <absolute-path>/volume-list
       exit 0
       ;;

where you replace <absolute-path> with the full path to the volume-list file. Then using the console, you enter the following command:

       label barcodes

and Bacula will proceed to mount the autochanger Volumes in the list and label them with the Volume names you have supplied. Bacula will think that the list was provided by the autochanger barcodes, but in reality, it was you who supplied the <barcodes>.

If it seems to work, when it finishes, enter:

       list volumes

and you should see all the volumes nicely created.

## Keep Your Client Machines' Clocks Synchronized to the Director

Please ensure that the clocks on all your client machines are synchronized with the clock on the server (Director) machine. If they are not synchronized or close, it is possible during an Incremental or Differential backup that a file changed during the time difference of the machines will not be backed up. This is because the Client uses the timestamp provided by the Director to determine whether or not the files should be backed up.

## Backing Up Portables Using DHCP

You may want to backup laptops or portables that are not always connected to the network. If you are using DHCP to assign an IP address to those machines when they connect, you will need to use the Dynamic Update capability of DNS to assign a name to those machines that can be used in the Address field of the Client resource in the Director's conf file.

## Going on Vacation

At some point, you may want to be absent for a week or two and you want to make sure Bacula has enough tape left so that the backups will complete. You start by doing a list volumes in the Console program:

    list volumes

    Using default Catalog name=BackupDB DB=bacula
    Pool: Default
    +---------+---------------+-----------+-----------+----------------+-
    | MediaId | VolumeName    | MediaType | VolStatus |       VolBytes |
    +---------+---------------+-----------+-----------+----------------+-
    |      23 | DLT-30Nov02   | DLT8000   | Full      | 54,739,278,128 |
    |      24 | DLT-21Dec02   | DLT8000   | Full      | 56,331,524,629 |
    |      25 | DLT-11Jan03   | DLT8000   | Full      | 67,863,514,895 |
    |      26 | DLT-02Feb03   | DLT8000   | Full      | 63,439,314,216 |
    |      27 | DLT-03Mar03   | DLT8000   | Full      | 66,022,754,598 |
    |      28 | DLT-04Apr03   | DLT8000   | Full      | 60,792,559,924 |
    |      29 | DLT-28Apr03   | DLT8000   | Full      | 62,072,494,063 |
    |      30 | DLT-17May03   | DLT8000   | Full      | 65,901,767,839 |
    |      31 | DLT-07Jun03   | DLT8000   | Used      | 56,558,490,015 |
    |      32 | DLT-28Jun03   | DLT8000   | Full      | 64,274,871,265 |
    |      33 | DLT-19Jul03   | DLT8000   | Full      | 64,648,749,480 |
    |      34 | DLT-08Aug03   | DLT8000   | Full      | 64,293,941,255 |
    |      35 | DLT-24Aug03   | DLT8000   | Append    |  9,999,216,782 |
    +---------+---------------+-----------+-----------+----------------+

Note, I have truncated the output for presentation purposes. What is significant for is that I can see that my current tape has almost 10 Gbytes of data, and that the average amount of data I get on my tapes is about 60 Gbytes. So if I go on vacation now, I don't need to worry about tape capacity (at least not for short absences).

Equally significant is the fact that I did go on vacation the 28th of June 2003, and when I did the list volumes command, my current tape at that time, DLT-07Jun03 MediaId 31, had 56.5 Gbytes written. I could see that the tape would fill shortly. Consequently, I manually marked it as Used and replaced it with a fresh tape that I labeled as DLT-28Jun03, thus assuring myself that the backups would all complete without my intervention.

## How to Excude File on Windows Regardless of Case

This tip was submitted by Marc Brueckner who wasn't sure of the case of some of his files on Win32, which is case insensitive. The problem is that Bacula thinks that /UNIMPORTANT FILES is different from /Unimportant Files. Marc was aware that the file exclusion permits wild-cards. So, he specified:

    "/[Uu][Nn][Ii][Mm][Pp][Oo][Rr][Tt][Aa][Nn][Tt] [Ff][Ii][Ll][Ee][Ss]"

As a consequence, the above exclude works for files of any case.

Please note that this works only in Bacula Exclude statement and not in Include.

## Executing Scripts on a Remote Machine

This tip also comes from Marc Brueckner. First I thought the "Run Before Job" statement in the Job-resource is for executing a script on the remote machine(the machine to be backed up). It could be usefull to execute scripts on the remote machine e.g. for stopping databases or other services while doing the backup. (Of cause I have to start the services again when the backup has finished) I found the following solution: Bacula could execute scrips on the remote machine by using ssh. The authentication is done automatically using a private key. First You have to generate a keypair. I ve done this by:

    ssh-keygen -b 4096 -t dsa -f Bacula_key

This statement may take a little time to run. It creates a public/private key pair with no pass phrase. You could save the keys in /etc/bacula. Now you have two new files : Bacula_key which contains the private key and Bacula_key.pub which contains the public key.

Now you have to append the Bacula_key.pub file to the file authorized_keys in the \root\.ssh directory of the remote machine. Then you have to add (or uncomment) the line

    AuthorizedKeysFile      %h/.ssh/authorized_keys

to the sshd_config file on the remote machine. Where the %h stands for the home-directory of the user (root in this case).

Assuming that your sshd is already running on the remove machine, you can now enter the folloing on the machine where Bacula runs:

    ssh -i Bacula_key <ip of remote machine> -l root "ls -la"

This should execute the "ls -la" command on the remote machine.

Now you could add lines like the following to your Director's conf file:

    ...
    Run Before Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 "/etc/init.d/database stop"
    Run After Job = ssh -i /etc/bacula/Bacula_key 192.168.1.1 "/etc/init.d/database start"
    ...

Even though Bacula version 1.32 has a ClientRunBeforeJob, the ssh method still could be useful for updating all the Bacula clients on several remote machines in a single script.

Using Autochangers | Index | Utility Programs

Bacula 1.32 User's Guide The Network Backup Solution | Copyright © 2000-2003 Kern Sibbald and John Walker