Site Overlay

Bacularis Installation and Configuration Notes

Bacularis is a fully loaded Bacula CE suite that comes with a successor of highly popular Baculum GUI. It can be installed by a one-liner Docker command thereby short-cutting hours of tedious installation steps like the ones I described in one of my previous posts.

1 Creating the container

1.1 with docker run

By default, the docker container mounts six volumes that it labels with non-intuitive random alphanumeric uuids. To get meaningful volumes that we can later identify on the host machine, we add a set of --mount options so that volumes are not created with anonymous uuid labels.

Furthermore, we open not only the Bacularis port 9097 but also ports 9101-9103 which are needed for communication between the director, the file daemons and the storage daemons.

1.2 with docker compose

From my experience, it is more convenient to keep the container configuration in a docker-compose.yml file: The complete configuration is stored readily available on disk, so there is no need to look it up. Besides having to enter multi-line commands with dozens of parameters at the console is cumbersome and prone to syntax errors.

  • Save the docker-compose.yml file below in a directory like ~/docker/bacuprod
  • Launch by issuing the command docker compose up --detach from the directory
  • Stop by issuing the command docker compose down

2 Set meaningful daemon names

The default name of the director is simply the host name of the docker container’s Alpine Linux OS plus an appended -dir. So you get unintuitive names like build-3-16-x86_64-dir. To better identify the machine, …

… stop the Bacularis container, as sudo change to the host machine’s local bacula_etc volume (the path may differ on your machine, depending on the docker installation it might be /var/lib/docker/volumes while in my case it’s ~/.local/share/docker/volumes).

First thing we have to edit is the bconsole.conf file. Replace Name and address directives as follows:

Save and continue editing bacula-dir.conf as follows:

In the same file, we can already change the name of the local client (file daemon) in the JobDef Resource:

Still in bacula-dir.conf we change the client name in the Job Resource for the Restore operation:

And, still in bacula-dir.conf we change the client name in the Client Ressource:

For the sake of house-keeping, we also amend the Name directive of the Console resource in bacula-conf.dir:

Don’t forget that director name also needs to be set for any daemon which the director should talk to. In our default installation, this should be the local file daemon and the storage daemon.

Save the changes in bacula-dir.conf and continue with editing bacula-fd.conf:

Save and continue with editing bacula-sd.conf:

Save and exit.

3 Further amendments

3.1 Add host ip and name to /etc/hosts

As we use host names instead of IP addresses we make sure that the q556 host’s IP address is known to bacularis. We therefore have to edit /etc/hosts inside the bacularis container.

For convenience we first install vim inside the bacularis container.

We can then invoke vim /etc/hosts and add the host machine’s name and IP:

3.2 Wrong database name in script of BackupCatalog job

In my case the default BackupCatalog failed when I tried to run it from the console:

For me the term ‘catalog’ is somewhat confusing. According to the Bacula MRG (Section 22.17), the terms catalog and database are apparently used as synonyms. The error message above FATAL: datatbase "MyCatalog" does not exist corroborates such an assumption.

This leads to two questions:

  1. What is the actual name of the Bacula database as set up by the Docker container? – Answer: The name of the Bacula PostgreSQL database is (unsurprisingly) bacula.
  2. In which Ressource(s) of which config file(s) has this ressource been incorrectly referred to as MyCatalog?

Looking at /etc/bacula-dir.conf, we realize that the Job Ressource BackupCatalog contains a directive that is passed MyCatalog as a command line argument.

Let’s check the content of the script that is called with MyCatalog. And here’s the relevant line:

Clearly, the pg_dump command expects the database name – which by default is bacula – and not some externally assigned label or alias from a config file.

So to fix the problem, we simply have to replace MyCatalog by bacula in the RunBeforeJob Directive of the Job Resource for BackupCatalog in bacula-dir.conf:

3.3 No contact to SD when backing up external clients

bacula-dir.conf of the Bacularis host features two Storage resources with an Address directive pointing to localhost. If you try to connect a client from outside the Docker container the job will stall / spin forever and can only be stopped by cancelling it. You will then get an error message that looks as follows:

The solution is to replace the localhost Address directive in the Storage resource of bacula-dir.conf on host q556 by the host’s hostname – which is q556.

4 First test: running local jobs

We now access the Bacula director from the Docker host machine to start with local backups:

4.1 Catalog backup

4.2 Local FileSet backup

We now try to run a file backup job of the local client. Still in bconsole proceed as follows:

5 Adding an (external) client

Any client must have a Bacula File Daemon running on the system which allows to the machine to connect with the Bacula Director and the Storage Daemon.

5.1 Installing bacula-fd on a client machine

Why not Docker for external file daemons?

The fastest way to install bacula-fd on a client machine is to pull the bacularis-api-fd from Docker and run a container with the file daemon.

The disadvantage is though, that by default, such a file daemon can only see what is inside the container while we are typically interested in the data on the host which runs the container. Granting the container access to the host data comes with a lot of problems:

  • We would need to come up with some NFS stunt to (ideally) mount the client’s complete file system as a volume into the container – but exclude the Docker container files it would produce some kind of “circular reference”.
  • Even if this would work, we would have to worry about file ownership and access privileges in the backup process
  • There may be older client machines that run a 32 bit OS, while Docker generally requires 64 bit architectures. (Still, Bacula’s deb packages are only provided for 64 bit machines, too).

Direct deployment

All this looks pretty nasty, so installing the file daemon on the client machine in a direct deployment from some deb packages (or whatever installs on the client machine’s OS) looks more suitable.

The first thing is to arm the GPG key and set up the repo information on the client machine. proceed as in section 2 of my post Bacula testing installation. Once you have pulled the apt update from the new repositories, you can install bacula-fd:

Check if the client is already running:

5.2 Configuration of the client

We first make sure that the client has the bacula director machine’s IP address mapped to the director machine’s host name, so we check if /etc/hosts on the client has an entry with q556 192.196.4.64.

Next, edit the config file in /opt/bacula/etc/bacula-fd.conf (you need to be root to get access to that file).

In the Director Resource, set the correct Name directive by putting in the Name of the director that runs inside the Bacularis Docker container on our main Bacula Server (which is q556 in my case).

Save and restart the client machine’s file daemon:

5.3 Amending bacula-dir.conf on the Bacula director machine

Now change to the machine running the Bacula Director (our Bacularis container) and amend bacula-dir.conf as shown below. The Password directive must match the Password directive we set on the external client machine in the previous step.

Restart the Bacula director in the Docker container to activate the amendments:

5.4 Opening and forwarding ports

Client side

On the client side, we the Bacula file daemon we installed will listen on port 9102. Use the netstat command to confirm that this port has already been opened when we installed the bacula-client package from the repository.

Docker host side

While Docker usually takes care of opening and forwarding all necessary ports between a container and its host, we also have to make sure that the host machine for the docker container has ports 9101-9103 opened for traffic from and to file and storage daemons.

After making sure that the host machine is actually accepting traffic on ports 9101-9103, we have to ensure that this traffic is actually forwarded to the Docker container.

First we check if the host machine has activated port forwarding per se. Check if the file /etc/sysctl.conf on the Docker host has the following line uncommented. Detailed instructions on principally allowing port forwarding can be found in my Bacula testing installation post.

Next we check the ufw status:

Surprisingly, although the previous iptables command showed that the host is listening on ports 9101-9103, ufw does not list these ports under the allowed ports. We therefore allow these ports explicitly under ufw and remove ports 9095 and 9096 as these look like leftovers from a previous legacy Baculum installation: