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, FATAL, 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).

In general, messages are attached to a Job and are included in the Job report. There are some rare cases, where this is not possible, e.g. when no job is running, or if a communications error occurs between a daemon and the director. In those cases, the message may remain in the system, and should be flushed at the end of the next Job. However, since such messages are not attached to a Job, any that are mailed will be sent to /usr/lib/sendmail. On some systems, such as FreeBSD, if your sendmail is in a different place, you may want to link it to the the above location.

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, …), message-type is one of a predefined set of keywords that define the type of message generated by Bacula (ERROR, WARNING, FATAL, etc.), and address varies according to the destination keyword, but is typically an email address or a filename.

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

The explanation on how to read the directive format:

Name: Contains the linked name of the directive.

Description: Explains what the directive does.

Value: Indicates what type of value to provide (e.g., <type-specification>).

Data Type: Specifies the type of data expected.

Values: Lists specific acceptable values.

Required: If present, indicates that the directive must be set by the user, there is no default value.

Default: If present, indicates that the directive has a predefined value that does not need to be set by the user, cannot be removed.

Comment: Additional important notes.

Example: Shows a usage example.

Messages Start of the Messages records.

Name

Description: The name of the Messages resource.

Value(s): <name>

Data Type: string

Comment: The name you specify here will be used to tie this Messages resource to a Job and/or to the daemon.

Mail Command

Description:

Value(s): <command>

Data Type: string

Comment: In many cases, depending on your machine, this command may not work. However, by using the MailCommand, you can specify exactly how to send the mail. During the processing of the command part, normally specified as a quoted string, the following substitutions will be used:
%% = %
%b = Job Bytes
%c = Client’s name
%C = If the job is a Cloned job (Only on director side)
%d = Daemon’s name (Such as host-dir or host-fd)
%D = Director’s name (Also valid on file daemon)
%e = Job Exit Status
%E = Non-fatal Job Errors
%f = Job Fileset (Only on director side)
%F = Job Files
%h = Client address
%i = JobId
%I = Migration/Copy JobId (Only in Copy/Migrate Jobs)
%j = Unique Job id
%l = Job Level
%n = Job name
%o = Job Priority
%p = Pool name (Only on director side)
%P = Current PID process
%r = Recipients
%R = Read Bytes
%s = Since time
%S = Previous Job name (Only on file daemon side)
%t = Job type (Backup, ...)
%v = Volume name (Only on director side)
%w = Storage name (Only on director side)
%x = Spooling enabled? ("yes" or "no")
Note

Any MailCommand directive must be specified in the Messages resource before the desired Mail, MailOnSuccess, or MailOnError directive. In fact, each of those directives may be preceded by a different MailCommand.

Example: See the following is an example:
mailcommand = "/opt/bacula/bin/bsmtp -h mail.example.com -f \\"\(Bacula\) %r \\" -s \\"Bacula: %t %e of %c %l\" %r\"
The bsmtp program is provided as part of Bacula. For additional details, please see the bsmtp – Customizing Your Email Messages section. Please test any mailcommand that you use to ensure that your bsmtp gateway accepts the addressing form that you use. Certain programs such as Exim can be very selective as to what forms are permitted particularly in the from part. Be careful, most of the samples use %r in the sender part of the mailcommand. This is a convenient way to setup the sender and the recipient at once. When you configure multiple recipients (separated by a comma) you must replace the %r in the sender part with only one valid email address.

Operator Command

Description: This resource specification is similar to the MailCommand except that it is used for Operator messages.

Value(s): <command>

Data Type: string

Comment: Normally, you will set this command to the same value as specified for the MailCommand. The OperatorCommand directive must appear in the Messages resource before the Operator directive.

<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.

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

Where address depends on the destination.

The destination may be one of the following:

Director Sends 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 Sends the message to the system log (syslog) using the facility specified in the address field. The address field is ignored and the message is always sent to the LOG_DAEMON facility. The level of ERR, NOTICE, and INFO are used only. See man 3 syslog for more details.

Mail Sends the message to the email addresses that are given as a comma separated 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 five or ten 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).

MailOnError Sends 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.

MailOnSuccess Sends the message to the email addresses that are given as a comma separated list in the address field if the Job terminates normally (no error MailOnSuccess 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 abnormally, the message is totally discarded (for this destination). If the Job terminates normally, it is emailed.

Operator Sends the message to the email addresses that are specified as a comma 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).

Console Sends the message to the Bacula console.

The message will be written to the table named Log and a timestamp field will also be added. This permits Job Reports and other messages to be recorded in the Catalog so that they can be accessed by reporting software. Bacula will prune the Log records associated with a Job when the Job records are pruned. Otherwise, Bacula never uses these records internally, so this destination is only used for special purpose programs (e.g. Bweb).

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

event messages, ex: Daemon startup/shutdown, Console login/logout, commands… This class of message is not included in the all message type. Specific events can be specified in the form events.string. Each destination directive can support up to 10 sub events.

info General information messages.

warning Warning messages. Generally this is some unusual condition but not expected to be serious.

error Non-fatal error messages. The job continues running. Any error message should be investigated as it means that something went wrong.

fatal Fatal error messages. Fatal errors cause the job to terminate.

terminate Message generated when the daemon shuts down.

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. These requests require a specific operator intervention for the job to continue.

restored The ls style listing generated for each file restored is sent to this message class.

saved The ls style listing generated for each file saved is sent to this message class.

all All message types except debug, events and saved.

security Security info/warning messages principally from unauthorized connection attempts.

alert Alert messages. These are messages generated by tape alerts.

volmgmt Volume management messages. Currently there are no volume management messages generated.

Example: See the following example:
syslog = all, !skipped
Although the syslog destination is not used in the default Bacula config files, in certain cases where Bacula encounters errors in trying to deliver a message, as a last resort, it will send it to the system syslog to prevent loss of the message, so you might occasionally check the syslog for Bacula output (normally var/log/syslog).

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.com. In addition all mount messages are sent to the operator (i.e. emailed to enforcement@sec.com). Finally all messages other than explicitly skipped files and files saved are sent to the console:
Messages {
   Name = Standard
   mail = enforcement@sec.com = all, !skipped, !terminate
   operator = enforcement@sec.com = mount
   console = all, !skipped, !saved
   catalog = all
}
With the exception of the email address (changed to avoid junk mail from robot’s), an example Director’s Messages resource is as follows.
Messages {
   Name = Standard
   mailcommand = "bacula/bin/bsmtp -h mail.example.com -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
   operatorcommand = "bacula/bin/bsmtp -h mail.example.com -f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed for %j\" %r"
   MailOnError = security@example.com = all, !skipped, !terminate
   append = "bacula/working/log" = all, !skipped, !terminate
   operator = security@example.com = mount
    console = all, !skipped, !saved
}
The following is an example of a valid Messages resource definition where Bacula will keep track of the user activity. It is often called “Auditing”.
Messages {
    Name = Standard
    console = all, !skipped, !saved
    append = bacula/working/bacula.log = all
    catalog = all, events
    append = bacula/working/audit.log = events, !events.bweb
}