Normal vs Command Plugins

In general, there are two ways that plugins are called. The first way, is when a particular event is detected in Bacula, it will transfer control to each plugin that is loaded in turn informing the plugin of the event. This is very similar to how a RunScript works, and the events are very similar. Once the plugin gets control, it can interact with Bacula by getting and setting Bacula variables. In this way, it behaves much like a RunScript. Currently very few Bacula variables are defined, but they will be implemented as the need arrises, and it is very extensible.

We plan to have plugins register to receive events that they normally would not receive, such as an event for each file examined for backup or restore. This feature is not yet implemented.

The second type of plugin, which is more useful and fully implemented in the current version is what we call a command plugin. As with all plugins, it gets notified of important events as noted above (details described below), but in addition, this kind of plugin can accept a command line, which is a:

   Plugin = <command-string>

directive that is placed in the Include section of a FileSet and is very similar to the "File = " directive. When this Plugin directive is encountered by Bacula during backup, it passes the "command" part of the Plugin directive only to the plugin that is explicitly named in the first field of that command string. This allows that plugin to backup any file or files on the system that it wants. It can even create "virtual files" in the catalog that contain data to be restored but do not necessarily correspond to actual files on the filesystem.

The important features of the command plugin entry points are:

• It is triggered by a "Plugin =" directive in the FileSet
• Only a single plugin is called that is named on the "Plugin =" directive.
• The full command string after the "Plugin =" is passed to the plugin so that it can be told what to backup/restore.