Normal vs Command vs Options vs Verify Plugins

In general, there are four 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 arises, 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.

The third type of plugin is the Options Plugin, this kind of plugin is useful to implement some custom filter on data. For example, you can implement a compression algorithm in a very simple way. Bacula will call this plugin for each file that is selected in a FileSet (according to Wild/Regex/Exclude/Include rules). As with all plugins, it gets notified of important events as noted above (details described below), but in addition, this kind of plugin can be placed in a Options group, which is a:

FileSet {
   Name = TestFS
   Include {
      Options {
         Compression = GZIP1
         Signature = MD5
         Wild = "*.txt"
         Plugin = <command-string>
      }
      File = /
   }
}

The last type of plugin is the Verify Data Plugin, this kind of plugin is useful to implement advanced data stream verification (such as antivirus checking, security, etc…). As with all plugins, it gets notified of important events as noted above (details described below), but in addition, the plugin can register to the bEventVerifyStream. For each regular file analyzed by the Verify Data process, the plugin will be called via the startVerifyFile() and PluginIO() interfaces to have access to data stream. The configuration of the Verify Data plugin can be done via the PluginOptions Job’s directive, or interactively in the run command.

Job {
  Name = TestFS
  Type = verify
  Level = data
  ...
  PluginOptions = <command-string>
}

Possible Next Steps

Go to Loading Plugins.

Go back to Bacula FD Plugin API.

Go back to Developer Guide.