Baculaでバックアップサーバーを構築する方法（Director・SD・FDの設定と復元まで）

Bacula は、1台のバックアップサーバーから複数のサーバーのバックアップを集中管理できるオープンソースのソフトウェアです。複数のWebサーバーを運用していて、取得のスケジュール、世代、復元をまとめて扱いたい場合に向いています。この記事では、Bacula の構成要素と通信の向きを押さえたうえで、Ubuntu 系のサーバーにバックアップサーバーを構築し、WordPressのサーバーをクライアントとして登録して、バックアップと復元を試すところまでを説明します。

Bacula の構成を理解する

Bacula は役割の違う複数のプログラムが連携して動きます。設定ファイルが分かれていて、互いのパスワードと名前を一致させる必要があるため、最初に全体像をつかんでおくとつまずきにくくなります。

• Director（bacula-dir）：司令塔です。いつ、どのクライアントの、どのファイルを、どこへ保存するかを管理します。待ち受けポートは 9101。
• Storage Daemon（bacula-sd、SD）：バックアップデータを受け取り、ディスクやテープに書き込みます。ポートは 9103。
• File Daemon（bacula-fd、FD）：バックアップ対象のサーバーで動き、ファイルを読み出して SD へ送ります。ポートは 9102。
• Catalog：どのファイルを、いつ、どのボリュームに保存したかの記録です。PostgreSQL や MySQL / MariaDB のデータベースに保存します。
• bconsole：Director を操作するコマンドラインのコンソールです。

通信の向きは、Director から FD と SD へ接続して指示を出し、データは FD から SD へ直接流れます。つまり、クライアント（FD）からバックアップサーバーの SD に接続できる必要があります。ここを見落として、Director からの指示は届くのにデータが送れない、という状態になりがちです。

今回は、バックアップサーバー1台に Director・SD・Catalog を置き、WordPressのサーバーに FD を入れる構成で進めます。

手順1：パッケージを入れる

Ubuntu や Debian では、ディストリビューションのパッケージで導入できます。パッケージの分け方はリリースによって違うことがあるため、apt search bacula で名前を確認してください。また、ディストリビューションのパッケージは bacula.org で配布される最新版より古いことがあります（2026年10月現在）。

# バックアップサーバー
sudo apt update
sudo apt install postgresql bacula-director-pgsql bacula-sd bacula-console

# WordPressのサーバー（クライアント）
sudo apt install bacula-fd

Catalog 用のデータベースは、インストール時に表示される設定画面（dbconfig-common）で作成できる場合が多いです。バックアップの記録が入る大事なデータベースなので、後で触れる Catalog 自体のバックアップも設定します。

設定ファイルは /etc/bacula/ に置かれます。編集前に、ディレクトリごとコピーを取っておいてください。

sudo cp -a /etc/bacula /etc/bacula.orig

手順2：Storage Daemon を設定する

まず、バックアップデータを書き込む場所を用意します。SD を動かしているユーザー（Debian / Ubuntu では bacula の場合が多い）が書き込めるようにします。

sudo mkdir -p /srv/bacula/volumes
sudo chown bacula:bacula /srv/bacula/volumes
sudo chmod 750 /srv/bacula/volumes

/etc/bacula/bacula-sd.conf で、受け付ける Director と、書き込み先のデバイスを定義します。

Storage {
  Name = backup-sd
  SDPort = 9103
  WorkingDirectory = "/var/lib/bacula"
  Pid Directory = "/run/bacula"
  Maximum Concurrent Jobs = 20
}

Director {
  Name = backup-dir
  Password = "your-sd-password"
}

Device {
  Name = FileStorage
  Media Type = File
  Archive Device = /srv/bacula/volumes
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
}

パッケージの既定の設定では、SDAddress = 127.0.0.1 のように待ち受けが自サーバーだけに限られていることがあります。別のサーバーの FD からデータを受け取るには、この行を外部から届くアドレスに変えるか削除する必要があります。

手順3：Director を設定する

/etc/bacula/bacula-dir.conf に、クライアント、保存先、対象ファイル、保存の方針を追加します。既定のファイルにはサンプルのジョブやスケジュールが入っているので、それを参考にしながら追記するのが楽です。

Client {
  Name = web01-fd
  Address = web01.example.com
  FDPort = 9102
  Catalog = MyCatalog
  Password = "your-fd-password"
  File Retention = 60 days
  Job Retention = 6 months
  AutoPrune = yes
}

Storage {
  Name = FileStorage
  Address = backup.example.com
  SDPort = 9103
  Password = "your-sd-password"
  Device = FileStorage
  Media Type = File
}

Pool {
  Name = WebPool
  Pool Type = Backup
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 70 days
  Maximum Volume Bytes = 20G
  Maximum Volumes = 50
  Label Format = "Web-"
}

FileSet {
  Name = "WordPress"
  Include {
    Options {
      signature = SHA1
      compression = GZIP
    }
    File = /var/www/html
    File = /var/backups/wp-db
  }
  Exclude {
    File = /var/www/html/wp-content/cache
  }
}

Job {
  Name = "web01-backup"
  Type = Backup
  Level = Incremental
  Client = web01-fd
  FileSet = "WordPress"
  Schedule = "WeeklyCycle"
  Storage = FileStorage
  Pool = WebPool
  Messages = Standard
  Write Bootstrap = "/var/lib/bacula/%c.bsr"
  RunScript {
    RunsWhen = Before
    RunsOnClient = Yes
    FailJobOnError = Yes
    Command = "/usr/local/sbin/wp-db-dump.sh"
  }
}

設定のポイントは次のとおりです。

• Storage の Address：クライアントの FD がこのアドレスで SD に接続します。localhost のままだと、クライアントは自分自身に接続しようとして失敗します。
• パスワードの対応：Director の Storage に書いたパスワードは SD 側の Director に、Client に書いたパスワードは FD 側の Director に、それぞれ一致させます。名前（backup-dir など）も相手側の設定と一致している必要があります。
• WeeklyCycle：既定の設定に入っているスケジュールで、月初の日曜にフル、その他の日曜に差分、平日に増分を取る内容になっていることが多いです。中身は Schedule リソースで確認してください。
• 保持期間：増分や差分は、その元になったフルバックアップがないと戻せません。Volume Retention はフルバックアップの間隔より十分長くし、少なくとも2回分のフルが残るようにします。この例では月1回のフルに対して70日にしています。

データベースは事前にダンプする

FD はファイルを読むだけなので、動作中の MySQL のデータファイルをそのまま取っても整合性のある状態にはなりません。RunScript でジョブの前にクライアント側でダンプを作り、そのファイルを FileSet に含めます。

#!/bin/bash
# /usr/local/sbin/wp-db-dump.sh（クライアント側、root 所有・権限 700）
set -euo pipefail
umask 077
mkdir -p /var/backups/wp-db
mysqldump --defaults-extra-file=/root/.wp-backup.cnf \
  --single-transaction --quick wordpress > /var/backups/wp-db/wordpress.sql

FailJobOnError = Yes にしておくと、ダンプに失敗したときにジョブ全体を失敗として記録するので、気づきやすくなります。

手順4：File Daemon を設定する

WordPressのサーバー側の /etc/bacula/bacula-fd.conf で、接続を許可する Director と、自分の名前を設定します。

Director {
  Name = backup-dir
  Password = "your-fd-password"
}

FileDaemon {
  Name = web01-fd
  FDport = 9102
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /run/bacula
  Maximum Concurrent Jobs = 20
}

Messages {
  Name = Standard
  director = backup-dir = all, !skipped, !restored
}

FD も既定では FDAddress = 127.0.0.1 で待ち受けていることがあるので、Director から届くアドレスに変えます。

手順5：ファイアウォールと設定の検証

必要な通信だけを、相手のアドレスに限って許可します。

• バックアップサーバー → クライアント：9102（Director から FD）
• クライアント → バックアップサーバー：9103（FD から SD）

# クライアント側（ufw の例）
sudo ufw allow from 192.0.2.10 to any port 9102 proto tcp
# バックアップサーバー側
sudo ufw allow from 192.0.2.20 to any port 9103 proto tcp

再起動の前に、各デーモンの設定を -t で検査します。書式の誤りがあると、ここで行番号つきで表示されます。

sudo bacula-dir -t -c /etc/bacula/bacula-dir.conf
sudo bacula-sd -t -c /etc/bacula/bacula-sd.conf
sudo bacula-fd -t -c /etc/bacula/bacula-fd.conf

問題がなければ、それぞれのサービスを再起動します。サービス名はパッケージによって違うことがあるので、systemctl list-units 'bacula*' で確認してください。

手順6：bconsole で動作を確認する

sudo bconsole

*status client=web01-fd
*run job=web01-backup level=Full yes
*messages
*list jobs
*list volumes

status client= で FD に接続できるかを確認し、最初のジョブはフルバックアップとして手動で実行します。messages で、エラーなく終了したか、何ファイル・何バイトを保存したかを確認できます。Label Format と LabelMedia = yes を設定しているので、ボリュームは自動で作られます。

手順7：復元を試す

バックアップの仕組みは、復元できて初めて完成です。bconsole の restore で対話的に戻すファイルを選べます。

*restore client=web01-fd select current

ファイルの一覧が表示されたら、cd で移動し、mark で戻したいファイルやディレクトリを選んで done で確定します。既定の復元ジョブは、元の場所ではなく別のディレクトリ（設定の Where）に戻すようになっているのが一般的です。まずはその場所に戻して中身を確認し、本番へ反映するのはそのあとにしてください。上書きで戻すと、障害の原因と関係ないファイルまで古い状態になることがあります。

運用で押さえておくこと

• Catalog のバックアップ：Catalog が失われると、どのボリュームに何が入っているかが分からなくなります。既定の設定に含まれる Catalog のバックアップ用ジョブを有効にし、ブートストラップファイル（.bsr）も別の場所に保管します。
• オフサイトへのコピー：バックアップサーバー1台にデータを集めると、そのサーバーが単一障害点になります。Copy ジョブで別のプールや別の場所へ複製する、ボリュームのディレクトリを別の事業者のストレージへ同期するなど、もう1か所に置く仕組みを用意します。
• 通信とデータの暗号化：デーモン間の通信は TLS で暗号化でき、FD 側でデータを暗号化してから送る設定（PKI）もあります。インターネットを経由する構成では検討してください。
• 設定ファイルの権限：設定ファイルにはパスワードが平文で書かれます。所有者とグループ以外が読めない権限になっているかを確認します。

画面から操作したい場合は、Web管理ツールの Bacularis のような選択肢があります。また、Bacula から分かれた Bareos も、似た構成のバックアップソフトとして開発が続いています。どちらも機能や対応バージョンは変わるため、導入前に公式のドキュメントで確認してください。

まとめ

• Bacula は Director・SD・FD・Catalog の分業で動き、データは FD から SD へ直接流れる
• Storage の Address はクライアントから届くアドレスにし、既定の 127.0.0.1 待ち受けにも注意する
• パスワードと名前を設定ファイル間で一致させ、-t で検査してから再起動する
• データベースは RunScript で事前にダンプし、保持期間はフル2回分以上を残す長さにする
• 復元は別ディレクトリに戻して確認し、Catalog のバックアップとオフサイトのコピーも用意する

• ファイルサーバーのバックアップ設計
• Amandaでバックアップを構築する方法