💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2016 › bacula_on_… captured on 2022-06-11 at 21:38:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from October 2016. The article has been slightly improved.
Background: Today I'd choose Bareos over Bacula. The former is a fork that happened because Bacula decided to treat the community badly (e.g. dismissing various contributions or even removing features of the Open Source version an favor of the commercial edition). While both diverged over time, they are of course still quite similar when it comes to the 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" as "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 too 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 in comparison to simple backup tools.
All of that is true. That's why we won't be doing backups in this first part. Instead we'll discuss some basics here that you definitely have to know. We'll also install Bacula and get all of its parts running. And 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" know what both of them mean, chances are you'll be fine. If you don't know them, please do a bit of research first and come back later.
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:
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 back 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 be a better fit, but that's not what it is called. What does it do? It reads files from a backup client's filesystem(s) 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 filesystem(s) on the machine it's running on.
Not a daemon but rather a small administration utility is the *bconsole*. It provides a means 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 getting started 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, with Postgres being the default on FreeBSD).
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 done the way it is and not organized 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.
Vagrant: Creating a FreeBSD 11 base box (virtualbox) - pt. 2
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.
Vagrant: Creating a FreeBSD 11 base box (virtualbox) - pt. 1
Let-s create a directory for the VM "backuphost" first and populate it with a Vagrantfile:
% cd ~/vagrant
% mkdir backuphost
% cd backuphost
% vi Vagrantfile
Put the following lines into the file and save:
Vagrant.configure("2") do |config|
config.vm.box = "fbsd-template"
config.vm.network "private_network", type: "dhcp"
config.vm.synced_folder ".", "/vagrant", disabled: true
end
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 -i
# cd /usr/ports/sysutils/bacula-server/
# make install clean
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).
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 such log file! So let's create it and give it to the bacula user so that it has the required permissions. 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 at least 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 about 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 (as PostrgeSQL is the default backend on FreeBSD, that's what you are expected to use if you installed _bacula-server_ from packages).
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.
You have to know a few things before changing 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 here that hint which daemon they actually belong 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 probably 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.
__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 yet, 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.
Bacula on FreeBSD (pt. 2): Bconsole - ruling the Director
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!).