プールとは、Backup がデータの書き込み先として使用する特定のメディアの集合のことです。Backup では、プールを使ってデータのソートと格納を行います。各プールの構成設定は、どのデータをどのボリュームに書き込むかを Backup に指示するためのフィルタの役割を果たしています。
Backup は、プールとラベルテンプレートを使って、各ボリュームにどのようなデータが含まれているかを追跡します。ラベルテンプレートの詳細は、「ストレージボリュームのラベル付け」を参照してください。
プールを構成することによって、どのボリュームにデータを書き込むかを決めます。個々のプール構成には、そのプールに関連付けられているボリュームに書き込まれるデータが満たさなければならない基準が含まれています。プールに入れるセーブセットを指定するときには、具体的なセーブセット名で指定することも、正規表現による照合を使ってセーブセットのグループを特定のプールに送ることもできます。正規表現による照合の使用例については、「例 : クライアントインデックスとブートストラップを別々のプールに送る方法」を参照してください。正規表現による照合の詳細は、nsr_regexp のマニュアルページを参照してください。
スケジュールされたバックアップが実行されるときには、最初に、セーブセットとプール構成が照合されます。セーブセットがプール構成の基準に合致すると、そのプールのラベル付きボリュームにセーブセットが送られます。
次に、正しくラベル付けされたボリュームがストレージデバイスにマウントされているかどうかが確認されます。ストレージデバイスに正しくラベル付けされたボリュームがマウントされていれば、そのボリュームにデータが書き込まれます。ストレージデバイスに正しくラベル付けされたボリュームがマウントされていない場合には、Backup は該当するボリュームをマウントするように指示を出し、そのボリュームがマウントされるまで待ちます。
Backup には、各種のデータを分類するために、事前構成済みのプールタイプが用意されています。1 つのプールの中で、次に示すタイプのデータを混在させることはできません。
バックアップデータ
アーカイブデータ
クローンデータ
マイグレートデータ
特にプールを指定した場合を除いて、バックアップデータは「Default」プールに送られ、アーカイブデータは「Archive」プールに送られます。クローンのバックアップデータは「Default Clone」プールに送られ、クローンアーカイブデータは「Archive Clone」プールに送られます。
Backup を構成するときには、プールを追加作成し、プールのタイプと次に示す 4 つの基準を任意に組み合わせて、データをソートできます。
グループ (バックアップグループ)
Backup クライアント
セーブセット (ファイルまたはファイルシステム)
バックアップレベル (フル、レベル 1-9、差分、手動)
「Group」属性にグループ名を入力すると、プールには、指定したグループに関連付けられたデータだけが入ります。「Group」属性にさらにグループ名を追加すると、プールにはどちらかのグループに関連付けられたデータが入り、それ以外のグループのデータは入りません。1 つの属性に対して指定したエントリは OR 句として扱われます。つまり、そのプールには、指定したいずれかのグループのクライアントのデータが入ります。
ただし、上に示した 4 つの構成基準については、これらの基準を組み合わせて指定すると、それらのエントリは AND 句として扱われます。つまり、「Group」属性と「Save Set」属性の両方に構成基準を入力すると、指定したプールのボリュームには、「Group」基準と「Save Set」基準の両方を満たすデータだけが書き込まれます。
プールタイプ、グループ、クライアント、セーブセット、あるいはレベルについて、まったく同じ設定内容のプールを複数作成することはできません。新しいプールの設定内容が既存のプールの設定内容と一致している場合には、警告メッセージが表示されます。重複する設定を変更してから、プールリソースを保存します。
セーブセットの詳細は、「バックアップするデータの指定」を参照してください。グループまたはバックアップレベルの詳細は、「バックアップレベル」を参照してください。
正規表現による照合を使用して、バックアップデータを送るプールとは別のプールに、クライアントインデックスとブートストラップを送ることができます。
次の例では、クライアントファイルインデックスは /nsr/index にあります。Backup サーバーのブートストラップと、このファイルシステムのすべてのクライアントファイルインデックスを同じプールに送るには、次の属性を持つプールを「Pools」リソースで作成します。
name: Index; pool type: Backup; save sets: bootstrap, /nsr/index/.*; levels: ; |
スケジュールされたバックアップがグループに対して実行されると、クライアントセーブセットは該当するセーブセットプール用のラベルが付けられたボリュームに書き込まれ、Backup サーバーのブートストラップと /nsr/index セーブセットは、「Index」プール用のラベルが付けられた別のボリュームに書き込まれます。
作成するプール構成によっては、データが複数のプール構成の基準を満たすこともあります。たとえば、あるプールは Accounting という名前のグループのデータが入るように構成されていて、別のプールにすべてのフルバックアップのデータが入るように構成されている場合、Backup は Accounting グループのフルバックアップデータをどのプールに書き込むかを判定しなければなりません。Backup は次に示すプール選択基準を使用します。
「Group」 (最も高い優先順位)
「Client」
「Save set」
「Level」 (最も低い優先順位)
データが 2 つのプールの属性に一致する場合、たとえば「Group」と「Level」に一致する場合、プールデータは「Group」属性に指定されているプールに書き込まれます。上に示した例のように、Accounting グループのデータが入るように構成されたプールと、すべてのフルバックアップが入るように構成されたプールがあった場合、Accounting グループのデータが入るプールにデータが送られます。
カスタマイズしたプール構成を使ってデータのソートを行なっているときに、間違って特定のクライアントやセーブセットの指定が漏れてしまうことがあります。スケジュールされたバックアップの際に、いずれのカスタマイズしたプール構成の基準も満たさないデータがあると、そのデータは自動的に「Default」プールに送られます。Backup では、「Default」プールを使って、バックアップグループのクライアントのすべてのデータが何らかのボリュームに確実にバックアップされるようになっています。
「Default」プールにデータが送られるときに、ストレージデバイスにマウントされた 「Default」プールで、このラベルが付いたボリュームを探します。ストレージデバイスに「Default」プールのボリュームがマウントされていない場合は、Backup は該当するボリュームを要求し、そのボリュームがマウントされるまで待ちます。スケジュールされたバックアップ処理の途中で Backup が「Default」プールのボリュームを要求しているにもかかわらず、オペレータが不在でこのプールのボリュームがマウントされない場合には、バックアップ処理はこのプールのボリュームがマウントされるまで停止されます。バックアップ処理を監視している場合には、このような状況が生じたときに備えて、「Default」プールのラベルが付いたボリュームを取り出しやすいところに用意しておくことをお勧めします。
Backup を無人バックアップで使用する場合には、構成内容を変更したら必ずテストを実行して、すべてのデータが適切なボリュームに書き込まれ、Backup から「Default」プールのボリュームをマウントするように要求されないことを確認してください。スケジュールされたバックアップのテストの手順については、「スケジュールされたバックアップグループをただちに開始する方法」を参照してください。
差分バックアップ用のプールを別途作成する場合には、Backup の優先順位によって、データの格納のされ方が左右されるという点に注意します。「Level」属性の値が「incremental」になっていると、差分データはそれに関連付けられたプールに送られますが、クライアントファイルインデックスの対応する変更箇所はそのプールには送られません。Backup では、必要な場合には、復旧処理を迅速にするため、すべてのクライアントファイルインデックスをレベル 9 で保存します。
クライアントファイルインデックスが、差分バックアップに関連付けられているプールの基準を満たしていないと、このインデックスを別のプール (通常は「Default」プール) と照合し、適切なラベルの付いた書き込み先ボリュームを探します。このため、データを復旧する必要が生じた場合には、すべてのデータを復旧するために多数のボリュームを使用しなければならないこともあります。したがって、クライアントファイルインデックスを差分バックアップデータとともに格納し、しかも復旧操作を迅速に行うためには、「Pools」リソースの「Level」の値には、レベル 9 のデータと差分データの両方が適合するように定義してください。
Backup の事前構成済みのプール設定値「NonFull」を使用すると、クライアントファイルインデックスは差分バックアップと同じプールに入ります。インデックスを差分バックアップと同じプールに保存するようにしておけば、復旧に必要なボリュームの数を減らすことができます。
データのクローンを作成する場合、Backup では、クローンデータが入る特定のプールのほかに、ソースボリュームの読み取り用とクローンの書き込み用に少なくとも 2 つのデバイスが必要です。クローン作成するデータにカスタマイズしたクローンプールを関連付けていない場合には、「Default Clone」プールが自動的に使用されます。クローン作成プロセスをスムーズに進行させるためには、別のストレージデバイスに適切なラベルが付いたボリュームをマウントする必要があります。Backup でのクローン作成機能の詳細は、「クローン作成」を参照してください。
Backup Archive ソフトウェアを使用してデータのアーカイブを行う場合には、アーカイブデータを入れるプールが必要です。アーカイブ後、これらのボリュームを必要に応じてオフサイトに保管できます。アーカイブするデータにカスタマイズしたアーカイブプールを関連付けていない場合には、事前構成済みの「Archive」プールが自動的に使用されます。アーカイブプロセスをスムーズに進行させるためには、適切なラベルが付いたボリュームをストレージデバイスにマウントする必要があります。Backup のアーカイブ機能の詳細は、第 6 章「Backup アーカイブ」を参照してください。
HSM 機能を使用する場合には、マイグレード前のセーブセットとマイグレート後のセーブセットを入れるプールが必要です。マイグレートデータにカスタマイズしたマイグレートプールを関連付けていない場合には、事前構成済みの「Migration」プールが自動的に使用されます。マイグレート前プロセスとマイグレートプロセスをスムーズに進行させるためには、適切なラベルが付いたボリュームをストレージデバイスにマウントする必要があります。Backup の HSM 機能の詳細は、第 8 章「階層型ストレージ管理」を参照してください。
アーカイブデータとマイグレートデータは通常の Backup セーブセットデータとは別のフォーマットで格納されているので、別のボリュームに書き込まなくてはなりません。したがって、アーカイブ、マイグレート前、あるいはマイグレートの操作の際に作成されるクライアントファイルインデックスとブートストラップセーブセットも、やはりアーカイブまたはマイグレートされたセーブセットとは別のボリュームに書き込まれます。これらは、デフォルトでは「Default」プールのボリュームに書き込まれます。クライアントファイルインデックスとブートストラップを「Default」以外のプールに送る必要がある場合は、「例 : クライアントインデックスとブートストラップを別々のプールに送る方法」を参照してください。
「Level」属性に「manual」と指定すると、手動バックアップによるデータを受け取るためのカスタマイズプールを作成できます。ただし、手動バックアップによるデータを、通常のスケジュールされたバックアップとは違う方法でソートします。手動バックアップはスケジュールされたバックアップグループの一部として実行されるのではないため、データにはグループ名が関連付けられていません。このため、手動バックアップを実行するときには 1 つのクライアントのセーブセットデータだけが保存され、そのクライアントのセーブセットに通常関連付けられているグループは、プールの割り当ての基準としては使われません。したがって、手動バックアップによるデータは、このクライアントのセーブセットのデータが通常のスケジュールされたバックアップ操作の際に格納されるプールとは別のプールに送ることができます。
手動バックアップによるデータを受け取るカスタマイズプールを作成していない場合には、「Default」プールが使用されて、手動バックアップのデータの書き込み先となるマウントされたボリュームを「Default」プールから探します。Backup はバックアップされたすべてのデータのボリューム位置を記録しているので、手動でバックアップされたデータがどのボリュームに含まれているかをユーザーが覚えておく必要はありません。データを復旧する必要が生じた時点で、Backup が正しいボリュームを指定して要求します。
手動バックアップの場合には、クライアントインデックスとサーバーブートストラップはバックアップされません。クライアントとサーバーマシンについて通常のスケジュールされたバックアップをまったく行わないと、障害時にデータ復旧に必要な情報を入手できなくなります。