Backup の階層型ストレージ管理 (Hierarchical Storage Management, HSM) は、ネットワークのストレージリソースを効率よく管理するための、Solaris Backup クライアント用のオプションモジュールです。HSM により、古いデータやアクセス頻度の低いデータの使用可能性を損なうことなく、高速で新しいデータにアクセスできます。HSM を使用するためには、Backup サーバー上で HSM モジュールが有効になっており、クライアントマシンがマイグレートクライアントとして構成されている必要があります。
この章は次の節で構成されています。
HSM 機能により、管理者が指定する 1 組のポリシーに基づいて、ローカルディスクと別のストレージメディアとの間で自動的にデータが移動します。マイグレートとは、クライアントからリモートのマイグレートストレージデバイスであるマイグレート記憶領域にファイルを移動させる処理のことです。呼び戻しとは、リモートのストレージデバイスからクライアントの元の場所にファイルを戻す処理のことです。HSM によって、古いデータやアクセス頻度の低いデータを利用できない状態にして、新しいデータに速くアクセスできるようにすることによって、ネットワークのストレージ資源を管理できます。マイグレートファイルへのアクセスに少し時間がかかる点を除けば、マイグレートと呼び戻しの処理全体はユーザーからは認識されません。
HSM はマイグレートクライアントとマイグレート記憶領域との間でファイルを移動させるもので、マイグレートサーバーによって管理されます。マイグレートクライアントは、ネットワーク上の、マイグレートするデータを格納しているシステムです。マイグレートサーバーは、ネットワーク上の、マイグレートサービスを提供するシステムです。マイグレート記憶領域はマイグレートサーバーに接続されており、ディスク、テープ、または光ディスクのストレージメディアで構成されます。
このデータ管理の方針は、管理者が定義する上限値 (high water mark) と下限値 (low water mark) によって決まります。上限値は、自動的にマイグレートが開始されるときのしきい値条件で、下限値は、自動的にマイグレートが停止するときのしきい値条件です。条件を満たすファイルがすべてマイグレートされるまで、あるいは下限値に達するまで、マイグレート処理は続けられます。
ファイルのマイグレートは、管理者が定義した基準によって決定される一種の「清掃」作業です。Backup は、割り当てられた基準に従って、マイグレートの候補となるファイルのリストを生成します。これらの候補を決定する上で最もよく使われるパラメータは、アクセスの頻度です。各マイグレートクライアントについてマイグレートサービスの有効/無効を切り替えることができます。システムファイル、共有ライブラリ、および Backup が使用するすべての実行可能ファイルとデータファイルは、常にマイグレート処理の対象からは除外されます。
ファイルのマイグレートは、システムの要件に応じて自動あるいは手動で行えます。管理者は、基準を定義し、個々のマイグレートクライアントにそれぞれの基準を割り当てるだけです。Backup が各クライアントについて、これらの基準を満たすファイルを自動的にマイグレートします。ユーザーまたはアプリケーションがマイグレートされたファイルにアクセスした時点で、Backup によってそのファイルが自動的に呼び戻されます。
ファイルがマイグレートされると、クライアントコンピュータ上にあった元のファイルは、ストレージメディア上のマイグレートファイルの位置を指すスタブファイルに置き換えられます。このスタブファイルは UNIX のシンボリックリンクで、置き換えられたファイルに関して次の 2 つの目的のための情報が格納されています。
マイグレートされたファイルのプレースホルダとして、そのファイルがローカルディスク上に存在しているかのように処理するためのもの
新しい位置へのポインタとして、HSM ソフトウェアによって、マイグレートされたファイルを探し出してローカルディスクに呼び戻すためのもの
ファイルがマイグレートされ、スタブファイルに置き換えられたあとも、ユーザーはそのスタブファイルに対して、ファイルシステム上の他のファイルとまったく同じ操作を実行できます。スタブファイルに対しては、移動、名前の変更、または読み取り/書き込みアクセスが不要なあらゆる操作を適用できます。
HSM が使用する「Migration」リソースの値を設定することによって、マイグレートの開始と停止を決定するクライアントファイルシステムの容量についての基準を指定できます。nwadmin プログラムの GUI を使って「Clients」メニューで「Migration Setup」を選択します。各マイグレートクライアントについて、次の条件を指定します。
クライアントファイルシステムが指定された上限値に達すると、Backup HSM アプリケーションによって、定義された基準に合致するファイルが自動的にマイグレートされます。
上限値と下限値に加えて、マイグレートの候補となるファイルが満たさなければならない基準を 1 つ以上設定する必要があります。複数の基準を設定した場合には、指定されたすべての基準を満たすファイルがマイグレートの候補となります。たとえば、クライアントファイルシステムが 70% になったときに、過去 60 日間にアクセスがなく、大きさが 2 K バイト以上の /home ディレクトリ内のファイルを自動的にマイグレートするというようなポリシーを設定できます。管理者が設定できるマイグレート基準には、次のものがあります。
前回のアクセス時間 - ファイルが最後にアクセスされてからの経過時間
最小ファイルサイズ - マイグレートの対象と見なされるファイルの最小サイズ。これよりも小さいファイルは、マイグレートを行なってスタブファイルで置き換えても、十分なディスク領域は得られない
ファイル所有者 - マイグレートの対象と見なされるファイルの所有者名。すべての所有者を対象にしたい場合は、このテキストボックスは空にしておく。owner_name 以外のすべての所有者を対象にしたい場合は、このフィールドに -owner_name と入力する
ファイルグループ - マイグレートされるファイルへのアクセス権を持つグループ名。group_name 以外のすべてのグループを対象にしたい場合は、このフィールドに -group_name と入力する
マイグレート対象外のファイル - マイグレートの対象から外すファイル。ファイルのエントリは完全パス名で指定し、UNIX シェルのワイルドカード文字を使用できる
「Migration」リソースでマイグレートクライアントのためのマイグレートポリシーを指定すると、Backup は次の方法でファイルをマイグレートします。
Backup サーバーが定期的にスケジュールされたバックアップを実行する際に、バックアップグループ内の各クライアントを調べて、マイグレート対象のファイルがないかどうかを調べます。スケジュールされたバックアップの際に事前マイグレートコマンドの nsrpmig によって、マイグレートクライアントファイルシステムの中でマイグレートの基準を満たすファイルが探し出されます。
事前マイグレート処理ではリソースを大量に使用します。マイグレートクライアントを含んでいるグループに対してスケジュールされたバックアップを行う場合には、システムがあまり使用されない時間帯に開始するようにします。
マイグレートの基準を満たすファイルが事前マイグレートされます。この事前マイグレートの際には、ファイルは Backup の格納場所 (マイグレートボリューム) にコピーされますが、元のファイルはクライアントマシンに残ったままです。
クライアントファイルシステムが上限値に達すると、nsrexecd デーモンがマイグレートコマンドの nsrmig を起動し、マイグレート処理が自動的に行われます。nsrmig コマンドは事前マイグレートされたファイルを調べて、これがマイグレートの基準をまだ満たしているかどうかを確認します。事前マイグレートされたファイルが依然としてマイグレートの対象となっていれば、nsrmig コマンドは次の操作を行います。
クライアントファイルシステム上の元のファイルを一時的な名前に変更する
クライアントファイルシステム上に、マイグレートメディア上のマイグレートファイルを指すスタブファイルを作成する
クライアントファイルシステムから元のファイルを削除する
マイグレート処理は下限値に達するまで続行されます。マイグレート基準を満たすファイルの数が少ない場合には、下限値にまで達しないことがあります。
マイグレートレポートが管理者に対して電子メールで送信されます。
Backup は、マイグレートファイルのエントリをクライアントインデックスの中に作成します。ただし、これらのエントリは復旧プログラムの GUI には表示されません。Backup はこれらのエントリを使って、マイグレートファイルとクライアントファイルシステムの中のスタブファイルとの間の関連を追跡し、呼び戻しの際にもこれを利用します。マイグレートファイルはユーザーの要求に従って呼び戻せなくてはならないので、マイグレートされたデータのインデックスエントリは、Backup クライアントに対して設定される自動データ再利用ポリシーの対象からは除外されます。Backup がクライアントファイルシステムから削除されたファイルを処理する方法については、「HSM による名前変更または削除されたファイルの処理」を参照してください。
システムファイル、共有ライブラリ、および Backup が使用するすべての実行可能ファイルとデータファイルは、常にマイグレート処理の対象から除外されます。次に示すファイルはマイグレートされません。
/、/usr、/opt、および /var の各ファイルシステムのすべてのファイル
.so で終わるすべてのファイル
Backup が使用するすべてのファイル (実行可能ファイルとデータファイル)
2 G バイトを超えるファイル
また、特定のファイルまたはファイルのグループをマイグレート対象から除外できます。たとえば、スーパーユーザーが所有するファイルを自動マイグレート処理から除外できます。
ユーザーまたはアプリケーションがマイグレートファイルを読み取り、書き込み、または属性の変更のためにアクセスすると、Backup によって、そのファイルが自動的にスタブファイルの位置に呼び戻されます。呼び戻しが開始されてから、ファイルが開かれます。呼び戻し操作が終了すると、制御がユーザープログラムに戻ります。このため、ユーザーはファイルが元の位置に完全に呼び戻されるまで、読み取りや書き込みの遅れを感じることがあります。ただし、アクセスに要する時間が長くなるということを除けば、呼び戻しのプロセス全体はユーザーからは認識されません。アクセスにかかる時間は、マイグレートメディアの使用可能性、デバイス速度、およびネットワーク速度に依存します。
ローカルハードディスクに、ファイルを呼び戻すための十分な空き領域がなければ、Backup からその通知が表示されます。Backup には事前構成済みの HSM 通知が用意されています。通知の使用方法については、「イベント通知」を参照してください。
HSM はバックアップ、アーカイブ、およびセーブセットのステージングという 3 つの機能を補足するものです。HSM により、システム管理者はネットワークリソースを効率よく管理し、さらには、ハードウェアストレージのコストを削減できます。すべての Backup 機能においては、データはメディアに格納されます。ただし、それぞれのメディアは独自の用途を持っています。表 8-1 は、バックアップ、HSM、セーブセットのステージング、およびアーカイブの各操作の目的を比較し、これらの機能が連係して完全なストレージ管理ソリューションを提供している様子を示しています。
表 8-1 バックアップ、HSM、セーブセットのステージング、およびアーカイブの比較
|
バックアップ |
HSM |
セーブセットのステージング |
アーカイブ |
---|---|---|---|---|
目的 |
データの誤削除、障害による消失等の防御 |
ネットワークのストレージリソースの節約 |
データを異なるストレージメディア間の移動 |
オンラインのストレージスペースの節約 |
格納されるファイル |
ファイルシステム全体 |
頻繁にアクセスされないファイル |
バックアップ、マイグレート、またはすべてのアーカイブファイル |
稀にしかアクセスされないファイル |
頻度 |
定期的 |
ポリシーベース |
ポリシーベース |
プロジェクトの終了時 |
方法 |
自動 |
自動または手動 |
自動または手動 |
手動 |
元のファイル |
元の場所に残る |
スタブが残る (ファイルの呼び戻しが可能) |
新しいストレージメディアに移動する |
通常は削除される |
ファイルをクライアントに戻すための方法 |
オンラインのデータが損傷したか、誤って削除された場合に、管理者によって復旧される |
ユーザーがファイルにアクセスすると、自動的にわからないうちに呼び戻される |
オンラインのデータが損傷したか、誤って削除された場合に、管理者によって復旧される |
ユーザーが必要なときに、管理者によって取り出される |
ファイルがマイグレートされると、元のクライアントファイルシステム上にはスタブファイルが残ります。このスタブファイルは、マイグレートされたファイルの新しい位置を指す UNIX のシンボリックリンクです。Backup が作成するスタブファイルはシンボリックリンクなので、NFS (ネットワークファイルシステム) クライアントでは NFS マウントされたディレクトリ上のファイルに対して事前マイグレートやマイグレートはできません。
しかし、NSF クライアントは NFS マウントされたディレクトリから既にマイグレートされているファイルを呼び戻さなければならない場合もあります。Backup では、次のように構成することで、この操作が可能になります。
NFS サーバーが、Backup クライアントソフトウェアを実行しており、Migration Setup が構成されている Solaris マシンである
NFS クライアントが、Backup クライアントソフトウェアを実行しており、Migration Setup が構成されている Solaris マシンである
NFS サーバーと NFS クライアントの両方が、同じ Backup サーバーのクライアントとして構成されている
NSF クライアントが適切なユーザー/グループを持っており、NFS マウントされたディレクトリに対する書き込み特権を持っている
NFS サーバーが、その Backup クライアントリソースの中で、NFS クライアントをリモートアクセスユーザーとして指定している
図 8-1 は、この構成シナリオを示しています。
このシナリオでは、ホスト Oak は HSM モジュールが有効になっている Backup サーバーで、そのクライアントのリストには Elm と Pine が指定されています。ホスト Elm では、Backup クライアントソフトウェアが実行されており、Migration Setup が構成されているNFS サーバーで、したがって Backup マイグレートクライアントになっています。Pine は Elm から NFS サービスを受け取る NFS クライアントです。Pine でも、Backup クライアントソフトウェアが実行されており、Migration Setup が構成されています。したがって Backup マイグレートクライアントになっています。
Pine が、Elm からマイグレートされたファイルを呼び戻すためには、Elm の Backup クライアントリソースの「Remote Access」属性に Pine が指定されていなくてはなりません。呼び戻し操作によって、マイグレートされたファイルは、マイグレート記憶領域から Elm 上のスタブファイルの位置に呼び戻されます。この操作はユーザーからは認識されずに行われます。
NFS クライアントがこれらの構成基準を満たしていない場合には、rlogin コマンドを使って NFS サーバーにログインし、適当な読み取りまたは書き込み操作をファイルに対して行えば、そのファイルを呼び戻すことができます。マイグレートファイルは元の位置に自動的に呼び戻されます。
HSM ソフトウェアは、Backup サーバーの配布メディアに含まれているオプションモジュールです。HSM ソフトウェアを有効にするためには、Backup サーバーにイネーブラコードを入力する必要があります。Backup サーバーソフトウェアで HSM 機能を 30 日間だけ評価する方法については、『Solstice Backup Release Supplement』を参照してください。
HSM モジュールを購入すると、HSM の機能を有効にするためのイネーブラコードが記載されているイネーブラ証明書が添付されています。ソフトウェアの有効化と登録は、次の 3 つの手順で行います。
「イネーブラコードの入力」の指示に従って、Backup サーバーにイネーブラコードを入力します。
HSM ソフトウェアをライセンスセンターに登録します。ソフトウェアの有効期間である 45 日以内にソフトウェアをライセンスセンターに登録してください。ライセンスセンターで登録フォーム受領後、HSM ソフトウェア用の認証コードが送付されます。
Backup サーバーに認証コードを入力します。このコードを入力すると、HSM ソフトウェアは永久的に有効になります。サーバーに認証コードを入力する方法については、「ソフトウェアを登録し認証を受けるには」を参照してください。
Backup サーバー上で HSM が有効になると、その Backup サーバーのすべてのクライアントをマイグレートクライアントとして構成できます。
Backup サーバー上で HSM を有効にしたら、その Backup サーバーが管理しているすべてのクライアントをマイグレートクライアントとして構成できます。ファイルのマイグレートが正しく行われるように、次の構成作業を実行します。
マイグレートクライアントのためのグループの作成
マイグレートデータのためのマイグレートプールリソースの構成
各マイグレートクライアントのマイグレートクライアントリソースの構成
マイグレートクライアントのためのグループを作成する必要があります。このグループの開始時刻によって、自動の事前マイグレート処理が実行される時刻が決まります。Backup がマイグレートクライアントとセーブセットを含んでいるグループのバックアップを行うと、基準を満たしているファイルが事前マイグレートされます。事前マイグレートは自動的に行われるので、上限値と下限値で制御することはできません。Backup が自動的に事前マイグレートを行うためには、ファイルがグループの一部として事前マイグレートされている必要があります。
事前マイグレート処理においてはリソースを大量に使用するので、他のシステムの稼働が少ない時間帯にグループの開始時刻を指定しなければなりません。バックアップグループの構成方法については、「バックアップグループの構成」を参照してください。
マイグレートファイルはマイグレートタイプのプールに書き込まれます。このマイグレートタイプのプールは、バックアップタイプやアーカイブタイプとは別のプールです。これらのプールタイプでは、いずれも異なる形式でデータが書き込まれるので、バックアップデータとマイグレートデータまたはアーカイブデータを同じプールの中に混在させることはできません。HSM が Backup サーバー上で有効に設定されると、「Migration」と「Migration Clone」という 2 つのプールリソースが使用可能になります。マイグレートデータには、この 2 つのプールリソースと、これらに対応するラベルテンプレートを使用します。必要に応じて、マイグレートクライアントに対して複数のマイグレートプールリソースを作成できます。nwadmin プログラムの GUI を使って、次の操作を行います。
「Media」メニューで「Pools」を選択して、「Pools」リソースを表示させます。
「Migration」プールを選択するか、新しいプールリソースを作成し、その「Type」属性に「Migration」を指定します。
マイグレートクライアントのために作成したマイグレートグループを選択します。
設定内容を適用します。
マイグレートグループに対するスケジュールされたバックアップの際に、事前マイグレートの基準を満たすデータが、このマイグレートプールに書き込まれます。自動メディア管理を有効にしているか、オートチェンジャを使用している場合は、Backup によって、このプールのラベル付きボリュームが自動的にマウントされます。
各マイグレートクライアントについて、各ファイルシステムについて、または両者の組み合わせについて、「Migration Client」リソースを使用して設定します。
「Migration Client」リソースを設定する前に、マイグレートサービスを利用する各クライアントまたは各ファイルシステムについて、「Client」リソースまたは「Client/save set combination」リソースを構成しておく必要があります。詳細は、「新しいクライアントの作成方法」と、「クライアント/セーブセットの一意の組み合わせの使用」を参照してください。
マイグレートサービスを利用するマシンが、HSM が有効になっている Backup サーバーのクライアントとして構成されていることを確認します。
クライアント上で nsrexecd が実行されていることを確認します。
「Clients」メニューで「Migration Setup」を選択して、「Migration」リソースを表示させます。
「Migration」リソースの各フィールドに入力して、マイグレートポリシーを設定します。
マイグレートクライアントに対して指定できる基準の詳細は、「マイグレートポリシー」を参照してください。
これらの基準を満たすクライアントとセーブセットが、自動的にマイグレートされる事前マイグレート処理の対象となります。事前マイグレートによって、ファイルが格納場所にコピーされ、元のファイルはクライアントのローカルディスクに残ります。事前マイグレート処理は、Backup がマイグレートクライアントを含んでいるグループをバックアップしたときに実行されます。これは自動的に行われるので、上限値と下限値によって制御することはできません。自動的に事前マイグレート処理を行うためには、ファイルをグループの一部として事前マイグレートしておく必要があります。マイグレート処理は、上限値に達するか、クライアントファイルシステムがいっぱいになった時点で行われます。この際に、事前マイグレートされたファイルはクライアントファイルシステムから削除され、マイグレートファイルに関する情報を含んでいるスタブファイルが残ります。
この節では、マイグレートクライアントとマイグレートファイルの管理に関する注意事項を示します。
ファイルのマイグレートが行われたあと、Backup でクライアントファイルシステムのバックアップを行うと、クライアントマシン上に残っているスタブファイルだけがバックアップされます。スタブファイルがバックアップされても、マイグレートファイルは呼び戻されません。マイグレートデータのスタブファイルを含んでいるファイルシステムを復旧すると、スタブファイルだけがローカルディスクに復旧され、マイグレートデータは呼び戻されません。
ファイルをクライアントのローカルディスクに呼び戻すには、クライアントマシン上でそのファイルを開きます。Backup によってファイルがマイグレート記憶領域から自動的に呼び戻されます。マイグレートファイルが入っているメディアが現在マウントされていなければ、Backup から管理者に通知されます。
マイグレートクライアント上でスタブファイルを誤って削除した場合は、削除してから 60 日以内であれば、バックアップメディアからスタブファイルを復旧できます。スタブファイルを復旧しても、呼び戻しは行われません。スタブファイルが 60 日を超えても復旧されなければ、Backup によってマイグレートファイルのエントリがクライアントインデックスから削除され、データはこれ以上追跡できません。
すべてのデータを確実に復旧できるようにするためには、定期的にマイグレートメディアのクローンを作成します。Backup ではクライアントコンピュータ上のスタブファイルだけをバックアップし、マイグレートデータそのものはバックアップしないため、クローンファイルだけが、そのファイルの唯一のコピーとなることがあります。マイグレートプロセスの完了後に自動的にクローンを作成するためには、マイグレートクライアントのために作成したグループリソースで「Migration Clone」プールを選択します。マイグレートデータのクローンは、「Migration Clone」タイプのプールのボリュームに書き込まれなくてはなりません。詳細は、「「Migration」プールと「Migration Clone」プールの使用」を参照してください。
マイグレートファイルに対してバックアップによる保護をさらに強化するには、マイグレートクライアントに対してスーパーフルバックアップを定期的に実行します。スーパーフルバックアップでは、セーブセットの最新のフルバックアップのクローンと、すべてのマイグレートセーブセットのクローンが作成されるので、クライアント上にはスタブファイルが、マイグレート記憶領域にはデータファイルが保存されることになります。スーパーフルバックアップを実行するには、Backup サーバーでスーパーユーザーになり、シェルプロンプトで次のコマンドを入力します。
# nsrclone -c client-name -N save-set-name |
マイグレートデータは Backup サーバーによって管理され、プール、クローン作成、自動メディア検証などの通常のすべてのストレージ管理機能の対象となります。しかし、マイグレートファイルはユーザーがいつでも呼び戻せなくてはならないので、マイグレートデータは、Backup サーバーが自動的にデータを再利用するためのポリシーの対象からは除外されます。つまり、Backup は、スタブファイルがクライアントマシン上に存在する限り、マイグレートファイルの位置をクライアントインデックスとメディアデータベースによって追跡しています。ただし、マイグレートされたスタブファイルのバックアップには、Backup サーバーのデータ再利用ポリシーが適用されます。詳細は、「HSM による名前変更または削除されたファイルの処理」を参照してください。
スタブファイルがクライアントファイルシステムに存在する限り、マイグレートされたファイルは迅速に呼び戻せなくてはなりません。このため、スタンドアロンのテープドライブはマイグレート先として適していません。マイグレートメディアとしてはオートチェンジャかサイロを使用してください。
マイグレートボリュームとは、マイグレートされたデータを保持しているメディアのことです。マイグレートデータの格納には、事前構成されている「Migration」ボリュームプールを使うか、マイグレート記憶領域として使用する独自のマイグレートプールを作成できます。また、マイグレートデータの送信先のボリュームのクローンを自動的に作成することもできます。マイグレートデータは通常のバックアップデータとは異なる形式で書き込まれるので、マイグレートデータは「Migration」タイプのプールに関連付けられたストレージボリュームにしか書き込めません。マイグレートボリュームのクローンは、「Migration Clone」タイプのプールのストレージボリュームにしか書き込めません。Backup には、マイグレートデータのために「Migration」と「Migration Clone」という名前の事前構成済みのプールが用意されています。
マイグレートデータの形式は通常のバックアップデータとは異なるため、別のボリュームプールに書き込まなくてはなりません。このデータ形式の違いのために、事前マイグレート操作またはマイグレート操作の際に作成されたクライアントインデックスとブートストラップセーブセットは、マイグレートセーブセットと同じボリュームには書き込めません。ユーザーの環境でボリュームプールがどのように構成されているかにもよりますが、通常は「Default」プールのボリュームに書き込まれます。クライアントインデックスとブートストラップを「Default」プール以外のボリュームプールに送る必要がある場合は、「例 : クライアントインデックスとブートストラップを別々のプールに送る方法」を参照してください。
セーブセットのステージング機能を使って、マイグレートファイルをストレージメディア間で移動させることができます。たとえば、ファイルをファイルデバイスタイプにマイグレートしておいて、あとからセーブセットのステージング機能を使って、このマイグレートファイルを光ディスクに移すことができます。Backup は新しいストレージメディア上のマイグレートファイルの位置を追跡し、このファイルをスタブファイルの位置に呼び戻します。マイグレートデータの物理的な位置の変化は、ユーザーからは認識されません。バックアップ、HSM、セーブセットのステージング、およびアーカイブ操作の比較については、表 8-1 を参照してください。
バックアップデータのステージングには「Clone」タイプのプールのボリュームを使わなければならないように、マイグレートデータのステージングには「Migration Clone」タイプのプールのボリュームを使う必要があります。たとえば、マイグレートデータのステージングポリシーを設定するときには、事前構成済みの「Migration Clone」プールを使用できます。
特定のマイグレートセーブセットを「Migration Clone」プールに手動でステージングするには、次のコマンドを入力します。
# nsrstage -s server-name -b Migration Clone -m -S save-set-ID |
セーブセットのステージング機能の詳細は、「セーブセットのステージング」を参照してください。nsrstage プログラムの構文とオプションについては、nsrstage のマニュアルページを参照してください。
コマンド行を使って、手動でマイグレートクライアントのファイルを事前マイグレートまたはマイグレートできます。たとえば「Migration Attention」の通知が出されたときなど、ファイルシステムに空き領域がなくなったときは、手動によるマイグレートを行います。まず、nsrpmig コマンドを使ってファイルを事前マイグレートし、次に、nsrmig コマンドを使ってファイルをマイグレートします。マイグレートするファイルが大きいほど、それだけローカルディスクスペースを解放できるので、その効果も大きくなります。
ファイルをマイグレートするためには、その前に事前マイグレートが行われている必要があります。
ファイルを手動で事前マイグレートするには、次のコマンドを入力します。
# nsrpmig -s server-name -b pool -g group path |
-b と -g の両オプションは、省略してもかまいません。省略すると、「Migration」リソースのデフォルトの設定値が使われます。
パスを指定しないと、現在使用中のディレクトリが使われます。
ファイルを事前マイグレートしたあとに手動でマイグレートするには、次のコマンドを入力します。
# nsrmig -s server-name path |
パスを指定しないと、現在使用中のディレクトリが使われます。ファイルシステムの容量が、「Migration」リソースで指定されている下限値に達するまでマイグレートが続けられます。
上記の 2 つのコマンドの詳細は、nsrpmig と nsrmig のマニュアルページを参照してください。
nsrhsmck (HSM 整合性チェックコマンド) が、毎晩 2:00 a.m. に、HSM 管理下のファイルシステムの整合性を自動的に確認して修正します。
HSM 管理下のファイルシステムの整合性を手動で確認することもできます。この整合性の確認と修正には nsrhsmck コマンドを使いますが、マイグレートファイルのスタブ名が変更されている場合、あるいはスタブがクライアントのファイルシステムから削除されている場合にこのコマンドを使って対処することもできます。nsrhsmck コマンドの基本構文は、次のとおりです。
# nsrhsmck -cdfv -s server-name path |
nsrhsmck コマンドを実行する場合は、コマンド行にパスを指定します。そこで指定されたパスにあるファイルとインデックスエントリに対してだけ、整合性の確認が行われます。
クライアントマシンでスタブ名を変更すると、Backup によってそのマイグレートされたファイルを元のディスクに呼び戻すことはできません。手動でファイルを呼び戻すには、nsrhsmck -f コマンドを使ってクライアントのファイルインデックスを更新し、変更後の名前を登録してください。
クライアントマシンからスタブを削除した場合は、バックアップメディアに保存されているスタブファイルを復旧してから実際のファイルを呼び戻します。
マイグレートファイルを削除する場合は、ローカルディスクからそのファイルのスタブを削除し、次に nsrhsmck -d コマンドを使って、削除するファイルのインデックスエントリに、削除の可能性あり、というマークを付けます。60 日を経過したら、nsrhsmck -c コマンドを使って、有効期限の切れたエントリをクライアントのファイルインデックスから削除します。Backup は、もはやこのマイグレートファイルを追跡していないので、このファイルを呼び戻すことはできません。
HSM のファイルインデックスからエントリが削除される前に、Backup によって、ディスクからそのファイルが本当になくなっているかどうかが確認されます。削除の可能性ありというマークを付けられたファイルが、そのエントリが削除される前にまだディスクに残っていると、エントリの削除の可能性ありというマークは消されます。
Backup 管理プログラムの「Migration Control」リソースには、HSM サービスを受けるように構成されているクライアントの一覧と、最近 7 日間に行われたすべてのマイグレート処理の統計情報が表示されます。
HSM 処理についてのレポートは、次に示すコマンド行命令を使って作成できます。詳細は、各コマンドのマニュアルページを参照してください。
nsrinfo コマンド - セーブセット内のファイルを一覧表示する
mminfo コマンドまたはクローン作成ブラウザ - 過去 24 時間にどのセーブセットがマイグレートされたかを調べる
nsrmig -n コマンド - 実際にファイルをマイグレートせずに、マイグレート対象のファイルのレポートを作成する
nsrpmig -n コマンド - 実際にファイルを事前マイグレートせずに、事前マイグレート対象ファイルのレポートを作成する
「Migration Completion」通知をカスタマイズするには、この通知用に構成されているリソースを変更します。デフォルトでは、マイグレート完了の通知は、上限値に達するなどのマイグレートイベントが起こった時点で電子メールによってスーパーユーザーに送られます。詳細は 「イベント通知」を参照してください。