Bacula 1.30 User's Guide | Chapter

Storage Daemon Configuration | Index | Console Configuration

# Messages Resource

## The Messages Resource

The Messages resource defines how messages are to be handled and destinations to which they should be sent.

Even though each daemon has a full message handler, within the File daemon and the Storage daemon, you will normally choose to send all the appropriate messages back to the Director. This permits all the messages associated with a single Job to be combined in the Director and sent as a single email message to the user, or logged together in a single file.

Each message that Bacula generates (i.e. that each daemon generates) has an associated type such as INFO, WARNING, ERROR, etc. Using the message resource, you can specify which message types you wish to see and where they should be sent. In addition, a message may be sent to multiple destinations. For example, you may want all error messages both logged as well as sent to you in an email. By defining multiple messages resources, you can have different message handling for each type of Job (e.g. Full backups versus Incremental backups).

The records contained in a Messages resource consist of a destination specification followed by a list of message-types in the format:

destination = message-type1, message-type2, message-type3, ...

or for those destinations that need and address specification (e.g. email):

destination = address = message-type1, message-type2, message-type3, ...

Where destination is one of a predefined set of keywords that define where the message is to be sent (stdout, file, ...), and message-type is one of a predefined set of keywords that define the type of message generated by Bacula (ERROR, WARNING, FATAL, ...).

The following are the list of the possible record definitions that can be used in a message resource.

Messages
  Start of the Messages records.
Name = <name>
  The name of the Messages resource. The name you specify here will be used to tie this Messages resource to a Job and/or to the daemon.
MailCommand = <command>
  In the absence of this resource, Bacula will send all mail using the following command:

  mail -s "Bacula Message" <recipients>

  In many cases, depending on your machine, this command may not work. Using the MailCommand, you can specify exactly how to send the mail. During the processing of the command, normally specified as a quoted string, the following substitutions will be used:

  - %% = %
  - %j = Job name
  - %t = Job type (e.g. Backup, ...)
  - %e = Job Exit code (OK, Error, ...)
  - %l = Job level
  - %c = Client's name
  - %r = Recipients
  - %d = Director's name

  The following is the command I (Kern) use. Note, the whole command should appear on a single line in the configuration file rather than split as is done here for presentation:

  mailcommand = "/home/kern/bacula/bin/smtp -h mail.whitehouse.com -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"

  Note, the smtp program is provided as part of Bacula. For additional details, please see the smtp -- Customizing Your Email Messages section of the Bacula Utility Programs chapter of this manual. Please test any mailcommand that you use to ensure that your SMTP gateway accepts the addressing form that you use. Certain program such as Exim can be very selective as to what forms are permitted particularly in the from part.

OperatorCommand = <command>
  This resource specification is similar to the MailCommand except that it is used for Operator messages. The substitutions performed for the MailCommand are also done for this command. Normally, you will set this command to the same value as specified for the MailCommand.
Debug = <debug-level>
  This sets the debug message level to the debug level, which is an integer. Higher debug levels cause more debug information to be produced. You are requested not to use this record since it will be deprecated.
<destination> = <message-type1>, <message-type2>, ...

  Where destination may be one of the following:

stdout
  Send the message to standard output.
stderr
  Send the message to standard error.
console
  Send the message to the console (Bacula Console). These messages are held until the console program connects to the Director.
*broadcast
  broadcast the message to all users on the local machine except dialups similar to what wall does.

<destination> = <address> = <message-type1>, <message-type2>, ...

  Where destination may be one of the following:

director
  Send the message to the Director whose name is given in the address field. Note, in the current implementation, the Director Name is ignored, and the message is sent to the Director that started the Job.
file
  Send the message to the filename given in the address field. If the file already exists, it will be overwritten.
append
  Append the message to the filename given in the address field. If the file already exists, it will be appended to. If the file does not exist, it will be created.
syslog
  Send the message to the system log (syslog) using the facility specified in the address field. Note, for the moment, the address field is ignored and the message is always sent to the LOG_ERR facility.
mail
  Send the message to the email addresses that are given as a comma separated list in the address field. Mail messages are grouped together during a job and then sent as a single email message when the job terminates. The advantage of this destination is that you are notified about every Job that runs. However, if you backup 5 or 10 machines every night, the volume of email messages can be important. Some users use filter programs such as procmail to automatically file this email based on the Job termination code (see mailcommand).
mail on error
  Send the message to the email addresses that are given as a comma separated list in the address field if the Job terminates with an error condition. MailOnError messages are grouped together during a job and then sent as a single email message when the job terminates. This destination differs from the mail destination in that if the Job terminates normally, the message is totally discarded (for this destination). If the Job terminates in error, it is emailed. By using other destinations such as append you can ensure that even if the Job terminates normally, the output information is saved.
operator
  Send the message to the email addresses that are specified as a comma separated list in the address field. This is similar to mail above, except that each message is sent as received. Thus there is one email per message. This is most useful for mount messages (see below).

For any destination, the message-type field is a comma separated list of the following types or classes of messages:

info
  general information messages.
warning
  warning messages.
error
  non-fatal error messages. The job continues running.
fatal
  fatal error messages. Fatal errors cause the job to terminate.
terminate
  message generated when the daemon shuts down.
saved
  files saved normally.
notsaved
  files not saved because of some error. Usually because the file cannot be accessed (i.e. it does not exist or is not mounted).
skipped
  files that were skipped because of a user supplied option such as an incremental backup or a file that matches an exclusion pattern. This is not considered an error condition such as the files listed for the notsaved type because the configuration file explicitly requests these types of files to be skipped. For example, any unchanged file during an incremental backup, or any subdirectory if the no recursion option is specified.
mount
  Volume mount or intervention requests from the Storage daemon
restored
  The ls style listing generated for each file restored is sent to this message class.
all
  all message types.
*security
  security info/warning messages (not currently implemented).

The following is an example of a valid Messages resource definition, where all messages except files explicitly skipped or daemon termination messages are sent by email to enforcement@sec.gov. In addition all mount messages are sent to the operator (i.e. emailed to enforcement@sec.gov). Finally all messages other than explicitly skipped files and files saved are sent to the console:

    Messages {
      Name = Standard
      mail = enforcement@sec.gov = all, !skipped, !terminate
      operator = enforcement@sec.gov = mount
      console = all, !skipped, !saved
    }

With the exception of the email address (changed to avoid junk mail from robot's), Kern's Director's Messages resource is as follows. Note, the mailcommand and operatorcommand are on a single line -- they had to be split for this manual:

    Messages {
      Name = Standard
      mailcommand = "bacula/bin/smtp -h mail.whitehouse.com -f \"\(Bacula\) %r\"
                    -s \"Bacula: %t %e of %c %l\" %r"
      operatorcommand = "bacula/bin/smtp -h mail.whitehouse.com -f \"\(Bacula\) %r\"
                        -s \"Bacula: Intervention needed for %j\" %r"
      MailOnError = security@whitehouse.gov = all, !skipped, !terminate
      append = "bacula/bin/log" = all, !skipped, !terminate
      operator = security@whitehouse.gov = mount
      console = all, !skipped, !saved
    }

Storage Daemon Configuration | Index | Console Configuration

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