Learn Bacula - Schedule & Job Types

#Introduction

In episode 6 we managed media. But backups run manually every night are not enterprise backups — they are a burden. In episode 7 we make Bacula work on its own: scheduling jobs through the Schedule resource, understanding job types, and preventing old data from piling up with three-layer retention. The industry-standard pattern we build: weekly full backup + daily incremental — balancing media size, restore time, and administrative effort.

#Schedule

#Basic Syntax

The Schedule resource in bacula-dir.conf defines when and at which level a job runs:

Schedule {
  Name = WeeklyCycle
  Run = Full Mon at 22:00
  Run = Incremental Tue-Sun at 22:00
}

A Run line consists of level, days, and time — for example Full Mon at 22:00, Incremental Tue-Sun at 22:00, Full 1st sun at 22:00 (the first Sunday of the month), or Differential Sat at 23:00.

The job simply points to its schedule:

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

#First-Level Behavior

An important rule: if a level has never been run for this client, Bacula will always start with Full regardless of the schedule. So the first incremental job that runs without a prior full automatically becomes full. This prevents an incremental with no base, which would be impossible to restore.

#Job Types

Every Bacula job has a Type. The four most core:

#Backup

Sends client data to storage according to the FileSet. Levels: Full, Incremental, Differential.

Job {
  Name = "Backup Harian"
  Type = Backup
  Level = Incremental
  Client = client-fd
  FileSet = "Set Server"
  Schedule = WeeklyCycle
}

#Restore

Builds a job that restores data from volumes to the client. Usually created dynamically via restore in bconsole (episode 8), not defined statically.

#Verify

Compares the data on the client with what is recorded in the catalog — making sure the catalog isn't lying. Details in episode 9.

#Admin

Runs scheduled administrative tasks, such as cleaning up stale volumes or backing up the catalog:

Job {
  Name = "Backup Catalog"
  Type = Backup
  Level = Full
  Client = bacula-fd
  FileSet = "Catalog"
  Schedule = "WeeklyCycleAfterBackup"
  Storage = FileStorage
  Pool = FilePool
}

There are also other types such as Migration, Copy, Consolidation, and System — used for advanced scenarios we touch on in later phases.

#Three-Layer Retention

Retention decides how long data records survive in the catalog. There are three interrelated layers:

#File Retention

How long file metadata (the per-file record) is stored in the catalog after a job finishes. When file retention expires, the file records are deleted — but the jobs and volumes remain. The consequence: you can no longer restore per-file from those jobs, because Bacula doesn't know which files were inside them.

#Job Retention

How long job records (the information from one backup session) are kept. After it expires, the job disappears from list jobs and the media it used can be considered for recycling.

#Volume Retention

How long media volumes are kept before they can be recycled (if Recycle = yes). This is the outermost and longest layer.

The relationship rule must be memorized — and kept consistent in Pools:

Pool {
  Name = FilePool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 30 days
  Job Retention = 14 days
  File Retention = 7 days
}

If File Retention is longer than Job Retention, file metadata survives longer than the job records — useful for forensics but wasteful of catalog space. Set it according to your restore needs.

#Auto-Prune

Prune is the process of deleting records that have passed retention. There are two ways to trigger it:

#Automatic

With AutoPrune = yes in a Pool, Bacula runs prune when a job runs — stale records are cleaned without administrator intervention. This is the recommended default for production.

#Manual

From bconsole, you can force it:

* prune
* prune volume=FilePool-0001
* purge jobs

prune deletes stale records; purge forcibly deletes records regardless of retention. purge is very dangerous — it removes records but not always the data on media. We discuss how to use it safely in episode 9.

#Running and Verifying Schedules

* list schedules
* status dir

status dir shows jobs being processed and upcoming ones; list jobs gives a summary of when the last and next jobs run.

#Closing

Key takeaways:

• Schedule uses the Level Day at Time syntax; the standard pattern = weekly Full + daily Incremental.
• The first level is always Full, regardless of the schedule.
• Job types: Backup, Restore, Verify, Admin (plus advanced ones like Copy/Migration).
• Three-layer retention: File <= Job <= Volume, set per Pool; AutoPrune keeps the catalog lean.

In the next episode, episode 8, we'll master the restore workflow — restoring data from backups via the restore command in bconsole, selecting client/FileSet/time, directing results to the original or an alternative location with where= and replace=, plus practicing restore drills into a test directory. This is the most important capability: making sure your data can really come back.