Learn Bacula - Restore Workflow

#Introduction

Every previous episode built toward one thing: the ability to restore data. A backup system that has never been restore-tested is not a backup system — it's merely a file-copying process. In episode 8 we do the most important thing: restore data from volumes back to the client, with full control over location and overwrite behavior.

We'll build a restore job through bconsole, understand the where and replace parameters, then close with the restore drill practice — the routine that separates professional administrators from those who just run jobs.

#Building a Restore Job

#The restore Command

In bconsole, type:

* restore

Bacula opens a menu of ways to find the files to restore:

To select the JobIds, you have the following options:
  1: List last 20 Jobs
  2: List Jobs where a given File is saved
  3: Enter list of JobIds to select from
  4: Find the JobIds for a File in a given Job
  5: Find the JobIds for a File in the last 20 Jobs
  6: Find the JobIds for a File in the last 20 Jobs for a Client
  7: Enter a list of Paths to look up
  8: Enter a list of Client names
  9: Enter a list of Restore Job names
Select item:

The most-used options:

• 1 — select from the last 20 jobs.
• 2 — find the jobs that saved a specific file.
• 8 — select by client.

Choose 1, then pick the JobId of the backup you want to restore. Bacula asks for confirmation and builds the restore job:

The defined Restore Job is:
Restore Job Parameters:
  Job:        RestoreFiles
  Client:     client-fd
  Storage:    FileStorage
  Pool:       FilePool
  FileSet:    Set Web
  Restore Job:  RestoreFiles
  Where:      /tmp/bacula-restores
  Replace:    always
  JobId(s) to restore: 1
OK to run? (yes/mod/no):

#Choosing Time and Client

Catalog-based restore means Bacula searches for files at a specific point in time. The JobIds choice defines that point: pick the JobId of the last backup before the data-loss event. If unsure, pick the latest full JobId followed by later incrementals — Bacula restores the file state according to the versions in the catalog.

You can also restore client A's backup to client B — just choose the target client in the menu. This is useful for server migration or hardware replacement.

#where and replace

#where: Restore Location

The Where parameter sets the destination directory on the client. This is your biggest safeguard:

• Where = /tmp/bacula-restores — restores to a test directory, never touching the original data.
• Where = / — restores to the original location (paths in the backup map directly).

OK to run? (yes/mod/no): mod
... choose "Where" then fill in the path ...

Always start with a non-root where to verify the results before overwriting original data.

#replace: Overwrite Behavior

Replace determines what happens when a file with the same name already exists at the destination:

• Replace = always — overwrite without asking.
• Replace = never — don't overwrite; save the restored file under another name.
• Replace = ifnewer — overwrite only if the backup file is newer.
• Replace = ifolder — overwrite only if the backup file is older.

The safe rule:

* restore ... replace=ifnewer where=/tmp/bacula-restores

#Restore Drill into a Test Directory

#Standard Procedure

The number one best practice in backup administration: routine restore drills. The procedure:

* restore jobid=1 where=/tmp/bacula-test replace=ifnewer

After the job finishes (Terminated, status Restore OK), verify:

ls -l /tmp/bacula-test/var/www/index.html
cat /tmp/bacula-test/var/www/index.html

Compare with the original file:

sha256sum /var/www/index.html /tmp/bacula-test/var/www/index.html

Identical checksums are proof of a valid restore.

#When to Drill

• Every time the FileSet/Pool configuration changes.
• Every new Bacula release (regression test).
• Scheduled at minimum monthly for critical jobs — and immediately after major events (migration, upgrade, data-loss incident).

#Real Restore Scenarios

#A Single Deleted File

* restore
... choose option 2: find JobIds that saved the file ...
Path to File: /var/www/index.html

Bacula finds the jobs that saved that file and builds a restore for it — without needing to know a specific volume or job.

#Restore to a New Machine

Install an FD on the new machine, define a new Client on the Director, then during restore choose the new machine as the target. Bacula will restore the data to the replacement machine with paths according to where. This is the basis of cross-hardware disaster recovery migration.

#Closing

Key takeaways:

• restore in bconsole builds a restore job from your JobId/client/time choices.
• where sets the destination location; replace sets the overwrite behavior.
• For testing, always use where=/tmp/... and replace=ifnewer.
• Routine restore drills with checksum verification are mandatory.
• The catalog enables per-file restore without knowing the specific volume.

In the next episode, episode 9, we'll verify data and manage autoprune — running Verify jobs to compare the client with the catalog, checking list volumes, triggering prune/purge for catalog consistency, and making sure the catalog itself is always backed up. This is the key to trusting your backup system.