Bacula 事始め

投稿者: | 2014年6月11日

Getting Started with Bacula

皆さんが私のようにいらちであれば、Baculaをすぐに利用し、どういう物かを体感し、その後で戻って詳細を読みたいと思うでしょう。この章は、このアプローチにもとづいている。細かい説明や注意事項抜きで、まず動かす方法を説明する。プール、ボリューム、ラベルの節をスキップして後で振り返ることも可能だが、この章は最後まで読んでほしい。とくにテープドライブのテスト方法は飛ばさないでほしい。開始する前に、すでにBacula のビルドとインストールは終わっているものと仮定する。まだの場合は、本マニュアルの「システム要件」の章を参照してほしい。

ジョブとスケジュールを理解する

Bacula を柔軟に活用するために重要なことは、Bacula に対する指示を適切にブレークダウンすることである。中心となる指示は、ジョブを定義するジョブリソースである。一般に、ひとつのバックアップジョブは、ファイルセット、クライアント、1 回または複数回の実行スケジュール、プール、および付加的な指示で構成される。別の角度から見れば、「どのファイル(What)」をファイルセット、「どのマシン(Who)」をクライアント、「いつ(When)」をスケジュールで定義し、「バックアップ保管場所(Where)」をプール(すなわちどのボリュームに) で定義する。

通常、ファイルセットとクライアントの組み合わせがジョブを形成する。他のほとんどのディレクティブ、たとえばファイルセット、プール、スケジュールなどは、いくつかを選んでジョブに対応づけることになる。したがって、複数のクライアントのバックアップを実行する複数のジョブが、同じスケジュール、ファイルセット、およびプールを採用している、ということもありえる。いつどのタイプのバックアップを行うか(たとえば、月曜日にフルバックアップ、週の残りは増分バックアップを行うなど) を定義するのがスケジュールである。複数のジョブが同じスケジュールを使用している場合、ジョブの実行順序はジョブの優先度にもとづいて決定される。類似のジョブを多数定義する場合、JobDefs リソースが便利である。これはジョブのデフォルト設定を定義するが、ジョブリソースの中で変更することもできる。同一のパラメータ群を個々のジョブで指定する手間を軽減できる。クライアントのファイルセットをバッ
クアップするジョブ以外に、カタログをバックアップするジョブも定義できる。

なお、バックアップのためのジョブだけでなく、リストア、照合、管理目的のジョブもある。
これらには上記とは別の要件がある。

プール、ボリューム、ラベルを理解する

tar などのプログラムでバックアップしていたユーザは、プール、ボリューム、ラベルなどの概念に最初は戸惑うかもしれない。ボリュームは、Bacula がバックアップデータを書き込む物理テープまたはひとつのファイルである。プールは複数のボリュームをグループ化したもので、バックアップできるサイズが個々のボリュームのサイズで制限されなくするために使用する。このため、ジョブでボリュームを直接指定する代わりにプールを指定するのが望ましい。Bacula はプールから書き込み可能なボリュームを検索して、オペレータにマウントするように指示してくれる。

プールの基本的なパラメータはディレクタのPool リソースで指定するが、実際のプールはBacula カタログで維持管理される。カタログ情報には、Pool リソース(bacula-dir.conf) に指定した情報に加えて、プールに追加したボリュームの情報も含まれている。プールにボリュームを追加するには、通常はコンソールプログラムのlabel コマンドを使う。

個々のボリュームについて、Bacula は最初の書き込み日時、最後の書き込み日時、ボリューム上のファイルの数、ボリュームに書き込み済みのバイト数、マウント回数などの情報を記録する。

Bacula でボリュームに読み書きする前に、Bacula が適切なボリュームをマウントできるようにするために、あらかじめBacula のソフトウェアラベルを物理ボリュームに書き込む必要がある。通常、コンソールプログラムのlabel コマンドを使う。

プールの定義、ボリュームの追加、ソフトウェア・ラベルのボリュームへの書き込み、という一連のステップは、初めのうちは回りくどく感じられるだろう。しかし、実際の作業はきわめて簡単で、単一テープのサイズ制限から解放されて複数のボリュームを使用できるようになる。プールには、バックアップ業務の柔軟性を高めるメリットもある。たとえば、日々の増分バックアップに”Daily”プールの中のボリュームを使い、週次のフルバックアップに”Weekly”
プールのボリュームを割り当てられる。日次と週次のバックアップジョブに正しいプールを指定してあれば、日次バックアップデータが”Weekly”に書き込まれていないことや、週次データが”Daily”に書き込まれないことが確実になる。さらに、Bacula は必要なメディアを管理者に要求する。

プールの詳細については「ディレクタの設定」の章のPool リソースを参照。または本章でも後でこの話題に戻る。


Bacula 設定ファイルの作成

Bacula Enterprise Edition のユーザであれば、.deb や.rpm 形式でパッケージ化されたプログラムをインストールするだけで、デフォルトの設定ファイル一式が/opt/bacula/etc ディレクトリに用意される。もちろん、実行環境に合わせて設定を変更する必要があり、またバックアップ対象のクライアントの定義も追加する必要がある。

実行環境に適合するようにデフォルトの設定ファイルを修正する作業には、多少の時間を要する。すべての設定が正しい状態になるまでに、Bacula を数回再起動する必要もある。どうか投げ出さずに完遂してほしい。いったん正しい設定ファイルを作ってしまえば、それを変更したりBacula を再起動することはほとんどなくなる。その後の作業は、ディスクまたはテープの残量やジョブが失敗していないことのチェックになる。

コンソールプログラムの設定

管理者が使用するコンソールプログラムは、ディレクタと双方向で通信する。そして、手動でジョブを起動/終了させる、またはジョブの情報を確認するために用いる。

コンソール設定ファイルは、./configure コマンドの–sysconfdir で指定したディレクトリ(Bac-ula Enterprise では/opt/bacula/etc) に格納されており、デフォルトではbconsole.conf という
名前になっている。

–enable-bwx-console オプションを指定してwxWidgets コンソールプログラムをビルドした
場合には、デフォルトの設定ファイルがbwx-console.conf という名前で作成される。

通常、初めてBacula を使用するユーザは、これらのファイルを変更しなくてもよい。適切なデフォルト値が設定されているためである。

詳細は「コンソール設定」の章を参照。

モニタプログラムの設定

モニタプログラムは、通常、システムトレイにアイコンを表示する。アイコンをクリックすると、ディレクタ、自機のバックアップ状況、他のBacula デーモンの状況などを確認できるウィンドウが開く。

Image Bacula-tray-monitor

画像は3 つのデーモン用に調整されたトレイモニタ画面である。左上部のラジオボタンをクリックすると、それぞれのデーモンの状態を確認できる。合わせて、現在選択しているストレージデーモン(MainSD) の詳細な情報も表示されている。上の図ではストレージデーモン(MainSD)のステータスが表示されており、そのストレージデーモンは現在Cが選択されている事を示している。

モニタ設定ファイルは./configure コマンドの–sysconfdir オプションで指定したディレクトリ(Bacula Enterprise では/opt/bacula/etc) に格納されており、デフォルトではtray-monitor.conf
という名前になっている。root 以外のユーザがモニタを実行できるようにするために、非rootユーザがアクセスできるように設定ファイルのパーミッションを変更し、非root ユーザにもbacula-tray-monitor の実行権限を与えなければならない。デフォルトの設定で使用する限り、この設定変更はセキュリティ面で問題にならない。

詳しくは「モニタの設定」の章を参照。

ファイルデーモンの設定

ファイルデーモンは、各クライアントマシンで動作するプログラムで、ディレクタからのリクエストに応じて、バックアップ対象のデータを探してストレージデーモンに引き渡す。

ファイルデーモン設定ファイルは./configure コマンドの--sysconfdir オプションで指定したディレクトリ(Bacula Enterprise では/opt/bacula/etc) に格納される。ファイルデーモン設定ファイル名のデフォルトはbacula-fd.conf である。初めてBacula を設定する場合、このファイルを変更する必要はない。適切なデフォルト値が設定されているためである。しかし、複数のマシンをバックアップしたいなら、対象のすべてのマシンにファイルデーモンをインストールして固有の設定ファイルを用意する必要がある。さらに、それらのファイルデーモンに関す
る情報をディレクタ設定ファイルに登録する必要がある。

詳細な情報は「クライアント/ファイルデーモンの設定」の章を参照。

ディレクタの設定

ディレクタは他のすべてのデーモンを集中制御するプログラムで、すべてのバックアップジョブのスケジュールを調整し、状況をモニタする。

ディレクタ設定ファイルは./configure コマンドの–sysconfdir オプションで指定したディレクトリ(Bacula Enterprise では/opt/bacula/etc) に格納される。ディレクタ設定ファイル名のデフォルトはbacula-dir.conf である。

一般に、FileSet リソースのInclude ディレクティブにバックアップ対象のディレクトリ(またはファイル) を1 行以上指定する必要がある

DLT テープドライブを使わない場合には、実際に使用するストレージデバイスを示す適切な名前をStorage リソースに指定する。既存の名前に加えて任意の名前を指定できるが、ストレージデーモン設定ファイルで定義した名前と一致しなければならない。

また、通知先メールアドレスをデフォルトのroot から別のアドレスに変更してもよい。

最後に、複数のマシンをバックアップしたいなら、ファイルデーモン(クライアント) ごとの名前、アドレス、パスワードを設定しなければならない。ファイルデーモンの名前については、デバッグを効率的に進める観点から、ホスト名の後ろに-fd という接尾辞を追加した名前にすることを推奨する。[たとえばホスト名がfoobaz だとすると、foobaz-fd をファイルデーモン名とするとよい。同様に、ディレクタ名はfoobaz-dir に、ストレージデーモン名はfoobaz-sdするのがよい。すべてのBacula の構成要素に一意な名前を付けなければならない。もしもすべてのデーモンに同じ名前を付けてしまうと、送られてきたメッセージがどのデーモンからなのかがわからなくなるだけでなく、作業ディレクトリ内に作られる一時ファイル名が一意でなくなることに起因する、さまざまなストレージの障害が起こる。

詳しくは「ディレクタの設定」の章を参照。

ストレージデーモンの設定

ストレージデーモンは、ディレクタからのリクエストに応じて、ファイルサーバから送られてきたデータをストレージメディアに保存する。リストアのリクエストを受け取った場合は、データを探してファイルデーモンに送る。

ストレージデーモン設定ファイルは、./configure コマンドの–sysconfdir オプションで指定したディレクトリ(Bacula Enterprise では/opt/bacula/etc) に格納される。ストレージデーモン設定ファイル名のデフォルトはbacula-sd.conf である。使用するすべてのテープデバイスに対して、Archive Device ディレクティブに適切な値を割り当てる。インストール後に実行される初期設定プロセスがデバイスを検出した場合には、あらかじめ適切な値が書き込まれている。ストレージデバイスのリソース名とメディアタイプは、ディレクタ設定ファイルbacula-dir.confでの記述と完全に一致していなければならない。テープの代わりにファイルにバックアップする場合は、ボリュームラベルが与えられたときにこれをファイルとして格納するディレクトリ名を、Archive Device ディレクティブに指定する必要がある。.

詳しくは「ストレージデーモンの設定」の章を参照。

設定ファイルのテスト

設定ファイルの構文をチェックするには、-t オプションを付けて対応するデーモンを起動する。デーモンは設定ファイルを処理し、エラーがあればエラーメッセージを表示して終了する。たとえば、バイナリファイルと設定ファイルの両方を同じディレクトリにインストールした場合、

cd <installation-directory>
./bacula-dir -t -c bacula-dir.conf
./bacula-fd -t -c bacula-fd.conf
./bacula-sd -t -c bacula-sd.conf
./bconsole -t -c bconsole.conf
./bwx-console -t -c bwx-console.conf
./bat -t -c bat.conf
su <normal user> -c "./bacula-tray-monitor -t -c tray-monitor.conf"

上記のスクリプトは主要なプログラムの設定ファイルをテストする。設定ファイルに問題がなければ、スクリプトは何も表示せず終了する。コンソールに関する最後の3 つの行は、システム構成によっては利用できないかもしれない。Unix システムにおける伝統的なインストールパスにバイナリをインストールした場合、上記のコマンドを適切に修正しなければならない(./をコマンドの前に置かず、設定ファイルはフルパスで指定する)。

テープドライブの互換性を確認する。

膨大な時間をかけて調査した結果、テープドライブがBacula で使えないことがわかるという無駄を避けるために、本マニュアルの「New Features in 5.2.x」の章のTesting Your TapeDrive を読んでほしい。Linux かSolaris で利用可能なSCSI テープドライブはほとんど動作するはずだが、念のために確認しておく方がよい。FreeBSD(およびたぶん他のxBSD) を使う場合は、テープドライブの事前確認は必須である。。なおFreeBSD に関しては、Bacula を稼働できるようにするための詳細については、The FreeBSD Diary を確認してほしい。FreeBSD4.9-STABLE dated Mon Dec 29 15:18:01 2003 UTC 以前のバージョンでテープデバイスの使用を検討している場合、Bacula メインディレクトリにあるplatforms/freebsd/pthreads-fix.txt
を読んで、Bacula とテープの互換性を確認してほしい。

/lib/tls ディレクトリの問題点(Linux 2.4.x カーネル)

本節は過去の2.4.x カーネルにのみ適用され、実際に本節の内容が影響するユーザはいないと
思われる

Linux カーネル2.4.x ベースのRed Hat に採用されているpthread ライブラリ(/lib/tls) には欠
陥がある。Bacula を稼働させる前にこのディレクトリを削除するかまたはリネームして、システムを再起動する必要がある。これを実行しなかったら、Bacula は長期間停止するかデッドロックに陥る。/lib/tls を削除する代わりに、環境変数で上書きして無効化してもよい。この問題についてのより詳しい情報は「サポート対象オペレーティングシステム」の章を参照。

2.6.x カーネルが動作しているLinux システムでは、この問題は起こらない。

Bacula の実行

Bacula を使うときにもっとも大切なことは、ファイルをリストアできることである。リストア作業を体験していないまま実際に必要な局面に遭遇したら、強い緊張を感じるだけでなく、間違いを犯しやすくなる。事前に一度でも確認しておくことを勧める。

Bacula の運用のイメージを理解するために、本マニュアルの「チュートリアル」の章にある例題を実際に実行してみることを強く推奨する。

ログローテート

デフォルトまたは部分的に変更しただけのbacula-dir.conf を使っている場合、Bacula のすべてのログはファイルに出力される。このファイルが無限に肥大しないようにするには、script-s/logrotate にあるlogrotate/etc/logrotate.d/bacula にコピーする。毎月1 回ローテーションが行われ、最大5ヶ月分のログが保存される。デフォルトのローテーションは、このファイルを編集して変更できる。

ログ監視

Red Hat やFedora は毎晩logwatch を実行している。これは、ログファイルの解析レポートをメールで送る。このレポートにBacula のジョブを含めたい、という場合には、scripts/logwatchディレクトリの中の、README ファイルに記載してあるインストール方法と出力内容の説明を参照のこと。

ディザスタリカバリ

失ったり壊れたファイルのリストアだけでなくディザスタリカバリの手段としてBacula を使うのであれば、本マニュアルの「ディザスタリカバリ」の章を参照してほしい。

災害やクラッシュが起きるまで何もしないのではなく、ファイルのリストア方法を注意深く確認しておくことを推奨する。備えあれば憂いなし、である。

 

カテゴリー: