Learn Bacula - Tape & Storage Management

#Introduction

In episode 10 we protected live workloads. But where is the data stored long-term? For years-long retention, tape is still the hero many organizations rely on — and Bacula is one of the open source options with the most mature tape support. In episode 11 we master tape and changers, then balance them with disk storage.

The disk vs tape decision isn't about trends — it's about data profiles: data that is frequently restored wants to live on disk; data stored only for compliance fits on tape. Professional administrators understand both.

#Tape Storage

#Tape Device Configuration

In bacula-sd.conf, tape is defined as a sequential device:

LTO tape device

Device {
  Name = TapeDrive
  MediaType = LTO-9
  Archive Device = /dev/nst0
  LabelMedia = yes
  Random Access = no
  AutomaticMount = yes
  RemovableMedia = yes
  AlwaysOpen = no
}

Key differences from disk:

Random Access = no — tape can only be read sequentially. Restoring one small file can mean scanning an entire tape.
RemovableMedia = yes — tape can be removed from the drive and stored on a shelf; this is the core of an offsite strategy.
Archive Device = /dev/nst0 — the Linux tape character device. /dev/nst0 is the non-rewinding tape, more appropriate for backups than /dev/st0 (rewinding).

#Tape Rotation

Tape is physical: you buy a number of tapes and rotate them. A classic pattern:

Weekly tape rotation

Pool {
  Name = WeeklyTapePool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 14 days
  Maximum Volumes = 6
}

Six tapes, two weeks' retention, rotated: each week one tape leaves the cycle and is reused. Tapes holding compliance data are removed from the pool (purge + put on the shelf) so they are never recycled.

Note

Tapes meant for long-term storage must be removed from the active pool. If a tape is still registered in a pool with Recycle = yes, Bacula will overwrite its contents after retention — including the "archive" you thought was safe on the shelf.

#Changer and Autoloader

#The Changer Concept

A tape library (autoloader) is a box with many tape slots and one or more drives. Bacula controls the changer for automatic mount/unmount of tapes from slot to drive — this is what makes backups run without an operator.

The configuration in bacula-sd.conf uses a two-part device: the changer device + the tape drive device.

Changer and drive in bacula-sd.conf

Device {
  Name = Changer
  DeviceType = Changer
  Changer Device = /dev/sg0
  Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d"
  Changer Devices = "TapeDrive"
}
Device {
  Name = TapeDrive
  MediaType = LTO-9
  Archive Device = /dev/nst0
  Random Access = no
  RemovableMedia = yes
}

mtx-changer is a script that wraps the mtx commands (SCSI changer tools) — Bacula doesn't use its own changer driver; it calls this tool instead.

#Per-Slot Labels

Tapes inside the changer are identified by slot and barcode. From bconsole:

Label the entire changer contents

* label barcodes pool=WeeklyTapePool

label barcodes scans the barcode of every tape in the changer and labels each according to its barcode (for example LTO009-0001). Without barcodes, label manually:

Label one slot

* label slot=3 pool=WeeklyTapePool

Important: physical tape barcodes must be unique, because Bacula associates a slot with a barcode. Move tapes between slots, and Bacula follows via the barcode.

Warning

A wrong label on a tape is a restore-disaster scenario: Bacula thinks the tape contains data X when it actually contains data Y, and then Recycle overwrites it. Always verify barcodes/labels with list volumes after labeling, and check status device after changer operations.

#Disk Storage

#File Storage

What we've been using since episode 3:

Disk storage

Device {
  Name = FileStorage
  MediaType = File
  Archive Device = /var/lib/bacula/storage
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
}

Disk excels at restore speed and simplicity, but costs more per GB and is vulnerable to a single disk failure — consider RAID or external storage.

#Deduplication

Deduplication removes repeated data: a block is stored once, and references cover the rest. The impact is dramatic for VM workloads (many identical OSes) or duplicate files.

Enterprise: the built-in dedup plugin in the Storage Daemon — blocks are deduplicated before being written, significantly saving space.
Community: no built-in dedup. It is purely file-based; savings are done manually (for example using a filesystem dedup such as ZFS/btrfs at the storage level, or accepting the redundancy).

ZFS-based storage (FS-level dedup)

Device {
  Name = ZFSStorage
  MediaType = File
  Archive Device = /backup/zpool/bacula
  Random Access = yes
  ...
}

Tip

The disk-to-disk-to-tape (D2D2T) strategy: night backups go to disk (fast, easy to restore), then a Copy/Migration job moves the disk volumes to tape for long-term archiving. This combines the speed of disk with the economy of tape — a standard enterprise pattern.

#Monitoring Storage

Storage and volume status

* status storage=FileStorage
* status device
* list volumes

Watch for: devices stuck (Waiting on mount), volumes full with no headroom, and tapes never rotated. These three are the root of most failed jobs in production.

#Closing

Key takeaways:

Tape = sequential, RemovableMedia = yes; disk = random access, fast to restore.
Changer/autoloader uses mtx-changer; label barcodes labels per slot.
Tape rotation requires discipline: archive tapes must leave the active pool.
Dedup: the Enterprise SD plugin, or filesystem-level dedup (ZFS/btrfs) in Community.
D2D2T combines disk speed and tape economy; status storage is your eye on storage.

In the next episode, episode 12, we'll secure daemons and authentication — unique passwords per daemon pair (director-sd, director-fd, fd-sd), no defaults, TLS options, plus the port mapping of 9101/9102/9103 and firewall policy. This is the security foundation before we enter the full TLS phase.