Bacula on FreeBSD (pt. 1): Introduction – Bacula backup basics

Looking for a practical tutorial to get into Bacula hands-on? You’ve come to the right place. So this post is going to cover the three “B”: Bacula Backup Basics, and it will do so on a fourth “B” – (Free)BSD! Read “basics” auds “does not require previous knowledge”. However it’s Bacula basics. Even though the project’s manual officially discourages (!) using Bacula for people unfamiliar with “sophisticated backup tools”, don’t be afraid of it. The reason for the statement in the manual is that Bacula requires quite a bit of configuration work before it can do anything useful. Due to its modularity it’s also a bit harder to understand compared to simple backup tools.

All of that is true. That’s why we won’t be doing backups in this first part. Instead I’ll discuss some basics here that you definitely have to know. We’ll also install Bacula and get all of its parts running. That’s in fact enough for a single post.

While this post does not expect you to know anything about Bacula, you should have a general understanding of backup fundamentals. Simple test: If you know the terms „incremental backup“ and „differential backup“ and you know what both mean, chances are good that you’ll be fine. If you don’t know them, please do a bit of research first and come back later.

What is Bacula?

Bacula is an Open Source backup tool with a lot of advanced features (which I don’t claim to know much about). Or more precisely: Bacula is a set of tools to perform backups. As I touched upon above, Bacula is modular and it is crucial to know its parts:

  • bacula-dir
  • bacula-sd
  • bacula-fd
  • bconsole
  • catalog

First we have bacula-dir, the Bacula director daemon. Just like the name suggests, this is the central instance that supervises and coordinates backup work.

Then there’s bacula-sd, the Bacula storage daemon. The name also kind of implies what it does: It is responsible for storing the backup data that it receives or for reading and sending it in case of a restore.

The third daemon, bacula-fd, is the Bacula file daemon. I’d prefer to call it “client daemon” as that would in my opinion fit it better, but that’s not what it is called. What does it do? It reads files from a backup client and sends them to the storage daemon (sd). Or, in case of a restore, the file daemon (fd) receives data from the sd and writes it back to the disk.

Not a daemon but rather a small administration utility is bconsole. It provides a way of connecting to the director daemon (dir) and interact with it. You need it for maintenance, to debug problems or to test new configuration.

The catalog is where Bacula stores various information about backups (NOT the backup data itself!). We’re just starting with Bacula, so let’s keep things simple. All you have to know for now is that Bacula needs a catalog and that it is kept in a database (MySQL, PostgreSQL and SQLite are supported).

Ok, so much for Bacula’s structure. Next station: The practical part, Installing and getting it to work! But one more thing first: Whenever something about Bacula doesn’t seem to make sense to you, here’s a clue for you. Bacula was designed with tape backups in mind. Recalling this fact often helped me understanding why something in Bacula is the way that it is and not built differently!


My previous post showed how to prepare a Vagrant base box for playing with Bacula. I’ll assume that you are either using that or have a FreeBSD system available that’s configured likewise. You can ignore the Vagrant stuff in that case. I do recommend however that you use Vagrant. For now we’ll stick with a simple setup of one node, but once we add more nodes to our setup in later parts of this series, Vagrant comes in really, really handy. If you don’t know the tool, I’ve written another post that introduces Vagrant + VirtualBox for beginners.

Let’s create a directory for the VM “backuphost” first and populate it with a default Vagrantfile:

% cd ~/vagrant
% mkdir backuphost
% cd backuphost
% vagrant init

Edit the Vagrantfile, delete its content and put the following into it:

Vagrant.configure("2") do |config| = "fbsd-template" "private_network", type: "dhcp"
config.vm.synced_folder ".", "/vagrant", disabled: true

The network setting (creating a private network) is not needed right now but we’re setting it up already so that it can simply be used when we need it later. Now fire up the VM and SSH into it:

% vagrant up
% vagrant ssh

We’ve already prepared things during the base box creation. Now become root and install bacula-server:

% sudo su -
# cd /usr/ports/sysutils/bacula-server/
# make install clean

FileDaemon and StorageDaemon

Now that Bacula is installed, let’s see if we can get the various daemons to run. If you know what they are called, that’s usually not too hard. We’ll start with launching the fd:

# sysrc bacula_fd_enable="YES"
# service bacula-fd start

Starting bacula_fd.

Fair enough. But has it started successfully? Let’s check:

# service bacula-fd status
bacula_fd is running as pid 14003.

It has, everything’s looking fine here. Ignore the PID, BTW, it will most likely be different for you. Time to enable, start and check the sd next:

# sysrc bacula_sd_enable="YES"
# service bacula-sd start

Starting bacula_sd.
# service bacula-sd status
bacula_sd is running as pid 14056.

Again: Nothing unexpected happening here. The default configuration that comes with Bacula on FreeBSD is sufficient for both daemons to be happy with and start up. Now for the remaining daemon, the director… So far things were downright boring. But now they get a bit more interesting (you decide if that’s a good thing. Most administrators hate it when software behaves in interesting ways).

Bringing up the director

Let’s start the director daemon after enabling it for system start and see if it’s running:

# sysrc bacula_dir_enable="YES"
# service bacula-dir start

Starting bacula_dir.
# service bacula-dir status
bacula_dir is not running.

It isn’t! What could be wrong here? What do you do if you have no clue? Take a look at the system log of course:

# tail /var/log/messages | grep bacula-dir
Sep 20 19:00:00 fbsd-template bacula-dir: 20-Sep 19:00 Message delivery ERROR: fopen /var/log/bacula.log failed: ERR=Permission denied

Aha! The director was not allowed to open its log file. Probably because there is no log file! So let’s create it and give it to the bacula user so that it has the permissions needed. Then we’ll try to start the director again:

# touch /var/log/bacula.log
# chown bacula:bacula /var/log/bacula.log
# service bacula-dir start

Starting bacula_dir.
# service bacula-dir status
bacula_dir is not running.

Too bad! But we should have a log now. Let’s take a look at that:

# tail /var/log/bacula.log
20-Sep 19:11 bacula-dir JobId 0: Fatal error: Could not open Catalog “MyCatalog”, database “bacula”.
20-Sep 19:11 bacula-dir JobId 0: Fatal error: sqlite.c:199 Database /var/db/bacula/bacula.db does not exist, please create it.

Right, we forgot the catalog! I told you to configure it for SQLite when we built the base box so that’s what I’m going to assume here. If you chose MySQL or PostgreSQL, refer to the manual or search the net (PostrgeSQL is the default backend on FreeBSD; so if you installed bacula-server from packages, you’re expected to use that).

Bacula provides scripts for each database backend to created the tables needed. Let’s create the catalog and see if the director can start afterwards:

# su -m bacula
% /usr/local/share/bacula/make_sqlite3_tables
% exit
# service bacula-dir start

Starting bacula_dir.
# service bacula-dir status
bacula_dir is running as pid 14069.

All the daemons are up and running and you know a few essential things about Bacula. However we cannot do anything with it just yet. We need to dig into Bacula’s configuration before we can use the bconsole to interact with the director – which can then interact with the other two daemons.

Bacula configuration files

You have to know a few things before making changes to the default configuration makes sense. As these can be considered “basics”, too, I’ll cover them here.

On FreeBSD, Bacula’s configuration files live in /usr/local/etc/bacula/. Bacula’s configuration is divided into several configuration files – one for each daemon and one for the bconsole (as well as another one that we’ll ignore): bacula-dir.conf, bacula-sd.conf, bacula-fd.conf and bconsole.conf.

There are various passwords in the config files and those can be a little confusing at first. This is why I’ll be using simple passwords that hint which daemon they are actually belonging to. As long as you are just testing Bacula, I recommend you do the same. It’s hard enough to work through Bacula’s configuration and the more clear, easy to understand bits you’ve got in there, the better.

All those files have a common structure. They are composed of definitions which assign a value (or values) to a variable. Definitions which belong together are in the same group. Bacula calls these definitions directives and the groups are known as resources. Since there can be multiple resources of the same type, each one must have a unique name so Bacula can tell them apart. When it comes to resource types, think of them as the context which the resource is meant for (e.g. Director, FileDaemon, Messages, etc.)

The structure of a resource always looks like this:

Type {
directive A
directive B
directive C

In configuration files lines starting with a “#” are commented out. If you see a comment sign later in the line that means that anything from there is ignored as a comment while the part before it isn’t.

Take a look at bconsole.conf and bacula-fd.conf (these are the shortest ones) and get a first impression of what Bacula configuration looks like. Think about some of the resources and guess what they maybe do. Don’t look at bacula-sd.conf or bacula-dir.conf if you’re not looking for some more confusion. If things seem crystal clear for you however, of course feel free to go ahead. It’s also OK if you feel a little overwhelmed after reading the files. We’ll be tearing them apart together in a later part.

Saving the progress

IMPORTANT: DON’T destroy your VM if you intend to follow the other parts, too! We’re not starting fresh each time but instead build upon what we’ve done so far.

Maybe you want to play with Bacula on your own in the meantime. That would however complicate things a lot since the configuration would probably no longer match what I take for granted in the next post. But there’s a simple solution to this: Create a snapshot of your VM now! As long as you don’t remove that snapshot, feel free to do inside the VM as you please.

Shutdown the VM properly first and then use Vagrant to create a snapshot; but before you do, make sure that the VM has reached the poweroff state (if it hasn’t, wait a moment!):

# shutdown -p now
% vagrant status
% vagrant snapshot save tut_1_end


That’s it for now. I originally wanted to stuff more into this first post and at least have you do your first backup. But that would have meant to either make this post much longer (which would probably scare some people away) or to skip over some details and have you figure them out yourself (which kind of defeats the idea of writing such a “practical introduction” in the first place).

And since Bacula is a complex topic, I also think that this may be enough information for somebody who’s completely new to it (and perhaps to Vagrant as well). If you feel like this could have been longer you can of course just continue with part 2 whenever you want.

Oh, and if you notice any mistakes or anything, please tell me. I’m by no means a Bacula expert and chances are of course that I’m doing things horribly wrong (it has worked for me so far, though!).

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.