Learn Bacula - Core Concepts & Main Architecture

#Introduction

In episode 1 we understood the history of Bacula and why it exists. Now it's time to dissect the system's anatomy: what components live in a Bacula deployment, how they talk to each other, and where the configuration is stored. Without this mental map, every Failed to connect or Authorization problem error will feel like a puzzle.

In episode 2 we answer three questions: who does what, what is sent between components, and how the resources in /etc/bacula/ tie everything together into a single backup policy.

#Four-Component Architecture

Bacula separates its work into four roles that run as separate daemons:

+----------+    command    +----------+
|  bconsole| ------------->|  Director|--> Catalog (DB)
+----------+               +----+-----+
                                | schedule/job
                                v
+----------+   data push   +----------+
|  File    | ------------> | Storage  |
|  Daemon  |<---- control--|  Daemon  |
+----------+               +----------+

The simplified backup flow: the Director schedules a job and tells the File Daemon and Storage Daemon what to do; the File Daemon reads files on the client and sends the data to the Storage Daemon; when finished, the Director records the metadata into the Catalog.

#Director

The Director is the brain of the system. It reads the bacula-dir.conf configuration, schedules jobs, decides which volume to use, and coordinates the whole process. The Director never touches backup data directly — it only sends instructions. If the Director dies, scheduled backups stop, but the data already on media stays safe.

#Storage Daemon (SD)

The Storage Daemon is the hand that touches the media. It is responsible for writing and reading data to a device — which can be a directory on disk, a tape, or an autoloader. Its configuration lives in bacula-sd.conf. Each SD has one or more Device resources that describe the physical media and how to access it.

#File Daemon (FD)

The File Daemon is the eyes and ears on the client side. It runs on every machine being backed up, reads files according to a FileSet, and sends the data to the Storage Daemon at the Director's command. Because the FD must run on the same machine as the data, every client — including the Bacula server itself — needs its own FD.

#Catalog

The Catalog is Bacula's memory: a database containing the metadata of every backed-up file (name, size, checksum, location on the volume), job history, and media status. Database support in Community: PostgreSQL, MySQL, and SQLite. This metadata is what lets bconsole restore a single file without knowing exactly which volume the file is on.

#Software Components

A single Bacula installation produces several binaries:

• bacula-dir — the Director daemon; default port 9101.
• bacula-sd — the Storage daemon; default port 9102.
• bacula-fd — the File daemon; default port 9103.
• bconsole — the interactive console for controlling the Director.

The three daemons and bconsole communicate using shared passwords defined in each config file — this is the authentication system (covered in episode 12).

#Configuration under /etc/bacula/

All configuration lives in the /etc/bacula/ directory. Typically:

/etc/bacula/
├── bacula-dir.conf      # Director: Job, Client, FileSet, Pool, Schedule, Catalog
├── bacula-sd.conf       # Storage Daemon: Device, Storage
└── bacula-fd.conf       # File Daemon: Client, Director

Bacula recognizes two main directives: Director (the flow toward the Director) and Director {} as a resource. Don't confuse them — Director in bacula-fd.conf and bacula-sd.conf is a resource defining who is allowed to connect to that daemon, whereas in bacula-dir.conf the Director {} resource defines who may access the Director.

#Main Resources in bacula-dir.conf

The entire backup policy is expressed through resources. The six most core ones:

#Job

Defines the work: which client, which FileSet, which pool, which schedule, and which job type.

Job {
  Name = "BackupClient"
  Type = Backup
  Client = client-fd
  FileSet = "Set Web"
  Schedule = "WeeklyCycle"
  Storage = FileStorage
  Pool = FilePool
}

#Client

Identifies a single File Daemon that can be backed up — with its address and password.

Client {
  Name = client-fd
  Address = 10.0.0.12
  FDPort = 9103
  Password = "rahasia-fd"
}

#FileSet

Defines which files are backed up and its include/exclude rules (episode 5).

#Pool

A collection of volumes where data is written, complete with retention and labels (episode 6).

#Schedule

Rules for when jobs run — weekly full, daily incremental, etc. (episode 7).

#Storage

Connects the Director to a specific Storage Daemon.

Storage {
  Name = FileStorage
  Address = 127.0.0.1
  SDPort = 9102
  Password = "rahasia-sd"
  Device = "FileStorage"
  MediaType = File
}

#How to Read the Flow of a Backup

When a Backup job runs, the sequence roughly goes:

1. The Director reads the Job resource to find the Client, FileSet, Pool, and Storage.
2. The Director contacts the Storage Daemon and makes sure a volume is available.
3. The Director contacts the File Daemon and tells it which FileSet to read.
4. The File Daemon reads files on the client and sends the data to the Storage Daemon.
5. The Storage Daemon writes the data to the volume and sends statistics back to the Director.
6. The Director records all metadata in the Catalog and closes the job.

This sequence happens for every job — and explains why authentication between daemons must be correct, because all three connect directly to each other.

#Closing

Key takeaways:

• Four components: Director (brain), Storage Daemon (media), File Daemon (client), Catalog (metadata).
• Default ports: 9101 (Director), 9102 (Storage), 9103 (File).
• Configuration under /etc/bacula/: bacula-dir.conf, bacula-sd.conf, bacula-fd.conf.
• Policy is expressed through the Job/Client/FileSet/Pool/Schedule/Storage resources.
• Backup flow: Director coordinates, FD pushes data to SD, Catalog records metadata.

In the next episode, episode 3, we'll install Bacula 15.0.4 and write a minimal configuration — installing the bacula-* packages, creating the catalog database, starting the three daemons, then validating bacula-dir.conf with bacula-dir -t. This is the first moment your backup system truly comes alive!