Basic information

API capabilities

Bacularis Web works together with Bacularis API hosts. A single Bacularis Web interface can manage multiple Bacularis API hosts — local or remote ones. These API hosts are responsible for performing various tasks, including:

• Configuring Bacula components such as the Director, File Daemon, Storage Daemon, and Bconsole

• Managing autochangers (e.g., load, unload, label tapes with or without barcodes, move tapes between slots, etc.)

• Starting, stopping, and restarting Bacula components

• Retrieving data from the Bacula catalog database (jobs, volumes, clients, pools, filesets, and more)

• Running bconsole commands like estimate, prune, purge, status, run, and others

• Installing, upgrading, and uninstalling Bacula components such as Director, Client/File Daemon, Storage Daemon or Bconsole

• Running plugins provided by Bacularis to work with Bacula

Each of these API capabilities can be enabled or disabled independently. This flexibility allows you to tailor each API host to your specific needs. For example, if a remote host runs only the Storage Daemon, you can install Bacularis API on that host, enable the configuration capability for the Storage Daemon, and connect it to Bacularis Web. You will then be able to manage that remote Storage Daemon configuration through the central web interface.

Enabling API capabilities

Here’s what is required to enable each capability:

• Bacula component configuration

  Requires Bacula JSON tools provided with Bacula:

  • bdirjson program for the Director

  • bsdjson program for the Storage Daemon

  • bfdjson program for the File Daemon

  • bbconsjson program for Bconsole

  Define their paths on the Bacularis API Settings page under the Config tab.

• Autochanger management

  You can define devices on the Bacularis API web panel that will be managed by this host. Optionally, enable access to the catalog database to display detailed volume information in the autochanger view. The devices are possible to add on the Devices page in API panel, and catalog access is configured on the API panel Settings page on the Catalog tab.

• Start/stop/restart Bacula components

  These operations are referred to as Actions in Bacularis API. To enable them, define the appropriate commands (e.g., systemctl for systemd) on the Actions tab of the API panel Settings page.

• Access to Bacula catalog database

  Configure the connection parameters to the Bacula database in the Catalog tab of the API panel Settings page.

• Running bconsole commands

  Specify the path to the bconsole binary and its configuration file on the Console tab of the API panel Settings page.

• Bacula software management (install/upgrade/uninstall)

  If Bacularis API was deployed via Bacularis Web using the deployment feature, the necessary configuration is automatically applied based on the OS profile. If not, this function is possible to configure on the Software management page in the API panel Settings page.

• Plugins for Bacula

  Plugins must be both configured and explicitly enabled. They will not run if configuration is missing or if they are disabled.

Host connection

Each configured Bacularis API host can be connected to the Bacularis Web interface. The connection process is the same for both local and remote hosts. All hosts communicate with Bacularis Web using the HTTP(S) protocol, and there’s no functional difference between local and remote instances.

During normal operation, the first API host added must support at least the catalog and bconsole capabilities. This instance is referred to as the Main API and is configured during the Bacularis Web installation wizard. Any additional API hosts can be added without these specific requirements.

Bacula configuration

If you enable the configuration capability for any Bacula component in a connected Bacularis API, you can fully manage that component’s configuration from the Bacularis Web interface. This includes actions like creating, editing, and deleting configurations.

All changes made through the web interface are applied immediately to the relevant remote host. There is no local copy of the Bacula configuration stored on the Bacularis Web server — changes are pushed directly to the target system when you click Save.

• If the modified component is the Director, the configuration is automatically reloaded after saving.

• For other components, you’ll need to manually restart them — either using the Actions feature in Bacularis or directly via the command line.