Bacula 1.29 User's Guide Chapter 13
Back
Using AutoChangers
Index
Index
Next
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 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:
cd /home/kern/mysql/var/bacula
du . * |
/home/kern/bacula/bin/smtp -f "Bacula " -h mail.yyyy.com \
                           -s "Bacula running" xxxx@yyyy.com
If you just wish to send yourself a message, you can do it with:
cd /home/kern/mysql/var/bacula
/home/kern/bacula/bin/smtp -f "Bacula " -h mail.yyyy.com \
                           -s "Bacula running" xxxx@yyyy.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.

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.

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       | 2002-10-26 17:14 | 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

Manually Recycling Tapes

Although automatic recycling of tapes is implemented in version 1.20 and later (see the Automatic Recycling of Volumes chapter of this manual), you may want to manually force reuse (recycling) of a tape.

The simplest way to manually recycle a tape is write an end of file on the physical tape and then to remove the Volume name from the Media database. To write an end of file mark on the tape:

  (stop Bacula or unmount the drive)
  mt -f /dev/nst0 rewind
  mt -f /dev/nst0 weof
where you replace /dev/nst0 with the appropriate device name on your system.

To remove the Media (Volume) from the database, you do the following:

  ./console
  delete media
  (select the correct one)
With Bacula versions prior to 1.19, the delete command will only delete the selected Volume from the database and not its associated Job and File records. With Bacula version 1.19 and later, all associated records are deleted from the database.

Please be aware that the delete command can be dangerous. Once it is done, there is currently no way to recover your database records without restoring your database.

After doing the above, you can use the Console program to label the tape again.

If you prefer not to use the delete command, after writing an end of file mark on the tape, you can simply re-label the tape using a different Volume name. In this case, the old database records will remain unused (generally no great harm except that your database is not consistent with the real world).

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.

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.



Back
Using AutoChangers
Index
Index
Next
Utility Programs
Bacula 1.29 User's Guide
The Network Backup Solution
Copyright © 2000-2003
Kern Sibbald and John Walker