Backup サーバーの最初のクライアントはサーバー自身です。サーバーの「Clients」リソースは、ソフトウェアをインストールした時点で自動的に作成されます。サーバーのクライアントを設定すると、Backup で配布される構成内容が自動的に使用されます。「Clients」リソースの事前構成済みの設定値の一覧を表 2-1 に示します。
表 2-1 「Clients」リソースの事前構成済みの属性値
属性 |
事前構成済みの値 |
---|---|
「Archive Services」 |
「Disabled」(クライアントはアーカイブを実行できない) |
「Schedule」 |
「Default」 |
「Browse Policy」 |
「Month」(クライアントファイルインデックスのエントリは、バックアップから 1 か月間ブラウズ可能) |
「Retention Policy」 |
「Year」(クライアントのセーブセットについてのメディアデータベースのエントリは 1 年間保存される) |
「Directive」 |
「Null」(クライアントのバックアップに特別なディレクティブを使用しない) |
「Group」 |
「Default」 |
「Save Set」 |
「All」(クライアントの全ファイルシステムをバックアップする) |
「Remote Access」、「Remote User」、「Password」 |
「Null」(クライアントのファイルインデックスのブラウズとデータの復旧は、クライアントマシンのユーザーだけが可能) |
「Backup Command」 |
「Null」(標準のクライアントの save プログラムを使用) |
「Aliases」 |
「Null」(クライアントは交信に使用する修飾名を他に持たない) |
「Archive Users」 |
「Null」(アーカイブサービスに必要な認証済みのログイン ID はない) |
これらのクライアントについての事前構成済みの設定値は、ユーザーがニーズに合わせて変更できます。「Group」、「Schedule」、「Browse Policy」、「Retention Policy」、または「Directive」属性にカスタマイズした設定値を適用したい場合には、まずこれらの属性のリソースをカスタマイズして作成してから、新しい、または既存の Backup クライアントに適用します。これらのリソースの間には依存関係があるので、リソースのカスタマイズは次の順序で行います。
「Groups」
「Pools」
「Schedules」
「Policies」
「Directives」
Backup クライアントのリソースのカスタマイズ方法については、第 5 章「Backup クライアントの操作」を参照してください。
リソースをカスタマイズして作成すると、「Groups」、「Schedules」、「Policies」および「Directives」リソース内に作成されているすべての事前構成済みの設定とカスタマイズした構成の設定が「Clients」リソースの中に選択項目として表示されます。ユーザーはこれらを選択して、新しい、または既存のクライアントに適用できます。
「Groups」リソースでは、いつ、どのマシンを一括してバックアップするのかを指定できます。グループを使うと、選択したマシンを異なるタイミングでバックアップして、ネットワーク上のトラフィックを制御できます。また、「Groups」リソースを使ってバックアップデータのクローンを自動的に作成できます。
すべての Backup クライアントは、初期状態ではあらかじめ構成されている「Default」グループに割り当てられています。Backup をインストールした時点では、「Default」グループの「Autostart」属性は「Disabled」になっています。Backup ソフトウェアのテストを行う準備ができたら、「Start Now」属性を選択し、「Start Time」属性に割り当てられている「3:33」の値を上書きします。スケジュールされたバックアップを開始するには、「Autostart」属性で「Enabled」を選択します。
「Groups」リソースの事前構成済みの属性値を表 2-2 に示します。
表 2-2 「Groups」リソースの事前構成済みの属性値
属性 |
事前構成済みの値 |
---|---|
「Name」 |
「Default」 |
「Autostart」 |
「Disabled」 |
「Autorestart」 |
「Disabled」 |
「Client Retries」 |
「1」 |
「Stop Now」 |
「False」 |
「Start Time」 |
「3:33」 |
「Interval」(グループの実行頻度。24 時間制) |
「24:00」 |
「Clones」 |
「No」 |
「Clone Pool」 |
「Default Clone」 |
「Migration Clone Pool」 |
「Migration Clone」 |
「Inactivity Timeout」(この時間が経過すると、クライアントはハングしているとみなされる。分単位) |
「30」 |
「Printer」 |
サーバーに割り当てられているデフォルトプリンタ |
バックアップグループの詳細は、「グループバックアップの監視と管理」を参照してください。
「Pools」リソースは、バックアップデータの出力先を決定します。Backup にはいくつかの事前構成済みプールが用意されています。「Default」グループのデータは、「Default」プールのラベルが付けられたメディアにバックアップされるようにあらかじめ構成されています。「Pools」リソースの事前構成済みの属性値を表 2-3 に示します。
表 2-3 「Pools」リソースの事前構成済みの属性値
属性 |
事前構成済みの値 |
---|---|
「Name」 |
「Default」 |
「Enabled」 |
「Yes」 |
「Pool Type」 |
「Backup」 |
「Label Template」 |
「Default」 |
「Store Index Entries」 |
「Yes」 |
「Auto Media Verify」 |
「No」 |
「Recycle to Other Pools」 |
「No」 |
Backup は「Schedules」リソースを使って、特定の日に各クライアントのバックアップするデータのレベルを決定します。新しい Backup クライアントを作成すると、「Schedules」属性には自動的に「Default」スケジュールが割り当てられます。ユーザーは別の事前構成済みスケジュールを割り当てたり、独自のスケジュールをカスタマイズしたりできます。
Backup には、表 2-4 に示す 5 つの事前構成済みスケジュールが添付されており、ユーザーのバックアップの要件に合っていれば、これらのスケジュールをさらに構成しなくてもそのまま使用できます。また、ニーズに合わせて新しいスケジュールを作成することもできます。
事前構成済みの「Default」スケジュールは、変更はできますが、削除はできません。Default 以外の事前構成済みスケジュールの属性は削除も変更もできますが、事前構成済みスケジュールの名前を変更はできません。Backup の事前構成済みのバックアップスケジュールの一覧を表 2-4 に示します。
表 2-4 事前構成済みバックアップスケジュール
スケジュール名 |
Backup 操作 |
---|---|
「Default」 |
毎日曜日にフルバックアップを、それ以外の日は差分バックアップを実行する |
「Full Every Friday」 |
毎金曜日にフルバックアップを、それ以外の日は差分バックアップを実行する |
「Full on 1st Friday of Month」 |
毎月第一金曜日にフルバックアップを、それ以外の日は差分バックアップを実行する。 Backup には、このスケジュール用の設定済みのスケジュールFailed Cross Reference Formatオプションが用意されている。このスケジュールの変更は毎年持ち越される |
「Full on 1st of Month」 |
毎月 1 日にフルバックアップを、それ以外の日は差分バックアップを実行する |
「Quarterly」 |
各四半期の初日にフルバックアップを実行し、その他の月の 1 日にレベル 5 バックアップを実行する。7 日おきにレベル 7 バックアップを、その他の日に差分バックアップを実行する。 Quarterly スケジュールをカスタマイズするときには、Month 期間を使ってレベルバックアップを設定してから、スケジュール変更メニューを使ってカレンダ上で四半期ごとのフルバックアップを設定する |
「Policies」リソースを使って、バックアップしたデータのブラウズポリシーと保持ポリシーの両方のライフサイクルを作成します。クライアントリソースには、すでにデフォルトのブラウズポリシー「Month」と、デフォルトの保持ポリシー「Year」が割り当てられています。
ブラウズポリシーは、クライアントファイルインデックスがどれだけの期間、ブラウズ可能なエントリを保持しているかを決定します。ブラウズポリシーが期限切れになっていなければ、nwrecover プログラムを使って、バックアップされたファイルシステムをグラフィカルに表示できます。ブラウズポリシーが期限切れになったあとでも、セーブセット情報はメディアデータベースに格納されているので、セーブセット復旧機能か scanner プログラムを使ってデータを復旧できます。
保持ポリシーは、メディアデータベースにセーブセット情報が格納されている期間と、ファイルがバックアップボリュームから取り出し可能になっている期間を決定します。ボリューム上のセーブセットと、それに依存する、他のボリュームに格納されているセーブセットのすべての保持ポリシーが期限切れになると、ボリュームはリサイクル可能状態になり、Backup はこれを再利用できるようになります。ただし、ボリュームのラベルが付け直されるまでは、scanner コマンドを使って、期限切れになったセーブセットを復旧できます。
Backup には表 2-5 に示すポリシーがあらかじめ構成されています。これらはブラウズポリシーと保持ポリシーのどちらにも適用できます。
表 2-5 事前構成済み Backup ポリシー
ポリシー名 |
Backup の動作 |
---|---|
「Decade」 |
10 年間有効 |
「Half Year」 |
6 か月間有効 |
「Month」 |
1 か月間有効 |
「Week」 |
1 週間有効 |
「Year」 |
1 年間有効 |
セーブセットのライフサイクルの管理方法については、「バックアップデータの保持期間の指定方法」を参照してください。
ディレクティブには、バックアッププロセスを支援する手順が含まれています。たとえば、「Unix With Compression」ディレクティブを使用すると、バックアップの際に、UNIX クライアントマシンからデータがメディアに送信される前に、データの圧縮を行うことができます。
Backup には、表 2-6 に示すように、事前構成済みのディレクティブが用意されています。それぞれのディレクティブは、重要で便利なバックアップの命令に対応しています。
表 2-6 事前構成済みのディレクティブ
ユーザー専用のディレクティブを作成して、クライアントファイルのバックアップの効率をさらに高めることができます。詳細は、「カスタマイズしたディレクティブの作成」を参照してください。