test

Solstice Backup 5.1 管理者ガイド

新しい Backup クライアントの構成

Backup クライアントマシンにクライアントソフトウェアをインストールしたら、Backup サーバーでクライアントリソースを作成し、Backup クライアントごとに適切な構成値を設定します。これらの構成値によって、どのデータをバックアップするか、どのスケジュールに従うか、また、アーカイブなどの追加機能を使用するかどうかが決まります。

新しいクライアントの作成方法

新しい Backup クライアントを作成するには、Backup 管理プログラム (nwadmin) または nsradmin インタフェースで「Clients」リソースを表示します。「Create」オプションを選択し、クライアントマシンのホスト名を入力します。

構成値をカスタマイズしない場合は、新たに作成された Backup クライアントは、変更を保存した時点で、自動的にデフォルトの構成値が割り当てられます (Backup クライアントのデフォルト構成の詳細は、「「Clients」リソース」を参照)。「Save Set」属性のデフォルト設定「All」は、スケジュールされたバックアップと手動バックアップの際に、クライアント上のすべてのファイルがバックアップされるという意味です (クライアントセーブセットの詳細は、「セーブセットとは」を参照)。

「Clients」リソースで構成できる各属性の詳細は、Backup のオンラインヘルプを参照してください。nsradmin インタフェースを使用して Backup リソースの作成、編集、および削除を行う方法については、nsradmin のマニュアルページを参照してください。

各種プラットフォームの Backup クライアント

Backup サーバーは、さまざまなプラットフォームのクライアントをバックアップできます。この節では、クライアントを構成して Backup サーバーへバックアップする際のヒントを示します。

Backup サーバーと異なるオペレーティングシステムのクライアントを使用するためには、該当する ClientPak を購入し、有効にしなければなりません。ClientPak の詳細と、Backup サーバーがバックアップを開始する前に行う各クライアントに対するチェックの詳細は、「Backup によるクライアントライセンスの使用」を参照してください。

Solaris 2.6、AIX 4.2、および HP-UX 10.20 を使用しているクライアントでは、64 ビットファイルシステムがサポートされています。これらのクライアントでは、2G バイトよりも大きいファイルのアーカイブ、バックアップ、ブラウズ、および復旧が可能です。64 ビット対応でないクライアントでは、2G バイトより大きいファイルのブラウズはできますが、復旧はできません。

UNIX クライアント

UNIX 用のすべての Backup クライアントについて、次に示すファイルを手動で更新し、確認しなければなりません。


127.0.0.1 				localhost			loopback
137.69.8.1 				server			server.companyname.com
137.69.8.2 				client 			client.companyname.com

Backup は /etc/hosts ファイルを自動的に構成し、更新しません。手動でこのファイルを編集して、このファイルの情報が正しいことを確認する必要があります。ローカルホストループバックのエントリを削除したりコメントにしたりしないでください。

Windows NT クライアント

Windows NT 用の Backup クライアントでは、次に示すファイルを手動で更新し、確認する必要があります。

Windows 95 クライアント

Windows 95 クライアントでは、次に示すファイルを手動で更新し、確認する必要があります。

NetWare クライアント

NetWare クライアントでは、次に示すファイルを手動で更新し、次の点を確認する必要があります。

Macintosh クライアント

Macintosh クライアントは次の条件を満たしていなければなりません。

ストレージノードのアフィニティ

クライアントリソースとストレージノードのリストとの間の関係は「ストレージノードのアフィニティ」と呼ばれます。このストレージノードのアフィニティは、「Clients」リソースの「Storage Nodes」属性で定義します。ほとんどの Backup クライアントリソースの「Storage Nodes」属性のデフォルト設定は、Backup サーバーです。ストレージノードマシンのクライアントリソースの場合は、「Storage Nodes」属性のデフォルト設定は、そのストレージノードと Backup サーバーになっています。この属性には他のストレージノードの名前を追加できます。Backup サーバーはこの「Storage Nodes」属性の設定内容に従って、どのデバイスに各セーブストリームのデータを書き込むかを決定します。

注意 - 注意 -

サーバーのインデックスとブートストラップセーブセットがバックアップされるときには、そのデータは必ず Backup サーバーに対してローカルなデバイスに書き込まれます。ブートストラップはリモートデバイスにはバックアップできませんが、ブートストラップのクローンはリモートデバイスに書き込むことができます。mmrecov コマンドを使ってブートストラップセーブセットやサーバーのインデックスを復旧する場合には、ローカルデバイスからデータを復旧する必要があります。

バックアップの際には、「Storage Nodes」属性に列挙されているストレージノードマシンに接続されたデバイスだけが、クライアントのデータを受け取れます。操作ごとにストレージノードのリストを個々に指定することはできませんが、「Clients」リソースの「Storage Nodes」属性のストレージノード名は、いつでも追加と削除ができます。

バックアップが失敗し、次のメッセージが表示された場合には、ストレージノードのアフィニティに問題があります。


no matching devices; check storage nodes, devices or pools

ストレージノードのアフィニティに関してよく起こる問題には、次のようなものがあります。

よくある例として、クライアントのアフィニティリストにストレージノードが 1 つしかなく、そのストレージノードに接続されているすべてのデバイスが使用不可能になっている場合が挙げられます。

このような場合には、問題点を修正してから、バックアップを再開する必要があります。問題点を修正するには、次のようにします。

バックアップの種類の指定

「Clients」リソースの「Schedule」属性を使って、各 Backup クライアントを既存のスケジュールに割り当てます。Backup スケジュールには、Backup がいつ、どのレベルのバックアップを実行するかを定義します。使用しているシステムのニーズに合った既存のスケジュールがない場合は、「Schedules」リソースで独自のスケジュールを作成できます。スケジュールの詳細は、「スケジュールの構成」を参照してください。

バックアップの開始の指定

「Clients」リソースの 2 つの属性、「Group」と「Client Priority」を使って、クライアントのスケジュールされたバックアップをいつ開始するかを指定します。

バックアップグループ

バックアップグループによって、スケジュールされたバックアップをいつ開始するかを指定します。各クライアントの「Clients」リソースで、「Groups」属性の使用可能なバックアップグループの中から 1 つまたは複数のバックアップグループを選択します。バックアップグループをカスタマイズして作成するには「Groups」リソースを使用します。バックアップグループの詳細は、「バックアップグループの構成」を参照してください。

クライアントの優先順位

「Clients」リソースの「Client Priority」属性で、そのクライアントのセーブセットのワークリストを完成させるために必要な情報を得るために、関与するクライアントを検索する順序を指定します。「Client Priority」属性は 1 から 1000 までの範囲の値を使用できます。小さい値ほど、高い優先順位となります。

「Client Priority」属性の値が最も小さいクライアントは、Backup サーバーが交信する対象のクライアントリストの先頭に置かれます。「Client Priority」属性で値が指定されていなければ、交信の順序はランダムになります。

「Client Priority」属性はクライアントに交信する順序を指定しますが、クライアントがバックアップを完了する順序は、次に示すさまざまな要因が影響します。

バックアップするデータの指定

「Clients」リソースの「Save Set」属性で、そのクライアントマシンのバックアップするデータを指定します。「Clients」リソースでは複数のセーブセットを指定できます。Backup サーバーは、指定されたセーブセットごとに、クライアントの save プログラムを新しいインスタンスで開始します。

セーブセットとは

セーブセットとは、バックアップの対象となる、1 台のクライアントマシンのファイルのグループのことです。セーブセットには、以下のものを組み込むことができます。

クライアント/セーブセットの一意の組み合わせの使用

マシンにクライアントライセンスが 1 つしかなくても、そのデータの個々の部分を異なるタイミングでバックアップできます。これは、クライアントが大量のデータを保持している場合に便利です。このためには、クライアントマシンのバックアップを、複数のクライアント/セーブセットのバックアップに分けてスケジュールを設定します。大規模なファイルシステムを複数のクライアント/セーブセットのインスタンスとして定義し直すことによって、大規模なクライアントファイルシステムを自動でバックアップでき、さらに、ファイルシステム全体のフルバックアップが一度に行われるのを避けることでシステムの負荷を軽減できます。

クライアント/セーブセットの組み合わせを作成するには

  1. 「Clients」リソースで、1 つのファイルシステムなど、クライアントのデータの一部を「Save Set」属性に指定してクライアントを作成します。

  2. 「Clients」リソースで、同じホスト名で、クライアントのデータの別の部分を「Save Set」属性に指定して別のクライアントを作成します。

    複数のセーブセットを指定する場合は、各セーブセットを別々の行に入力します。

  3. 個々のクライアント/セーブセットのインスタンスに異なるバックアップグループを関連付けて、バックアップの開始時刻をずらします。

  4. 個々のクライアント/セーブセットのインスタンスに異なるスケジュールを設定して、個々のクライアント/セーブセットのインスタンスがそのフルバックアップを異なる曜日に実行するようにします。

    同じセーブセットに複数のクライアントインスタンスを関連付けることができるので、そのセーブセットには複数のバックアップグループやスケジュールを関連付けることができます。

    「Clients」リソースの「Save Set」属性にデフォルトのキーワード「All」が指定されていると、そのクライアントマシンのすべてのローカルファイルシステムは、「Clients」リソースで指定されているグループとスケジュールに従ってバックアップされます。

    同じマシンに対して複数のクライアントリソースを構成すると、割り当てられているブラウズポリシーと保持ポリシーのうち、最も期間の長いものが自動的に使用されます。

    注意 - 注意 -

    core ファイルは、「Clients」リソースの「Save Set」属性に指定がないとバックアップされません。

論理ボリュームのバックアップ

論理ボリュームとは、複数の物理ディスクボリュームにまたがることができる、クライアントマシン上の主 (ディスク) ストレージのことです。論理ボリュームは独自のデバイスアドレスを持っており、ファイルシステムからはディスクパーティションと同じように扱われます。クライアントのデータをバックアップする際に、パフォーマンスを最大限に高めるためには、各クライアントにどれだけのセーブセッションを割り当てればよいかを決める必要があります。競合を避けるためには、1 つの物理ディスク上のバックアップ操作は 1 つに抑えるべきです。Backup では、競合を避けるため、異なる物理ディスクに対して異なるセッションを割り当てます。

割り当てるセーブセッション数を決めるために、Backup サーバーは savefs -p コマンドを使ってバックアップグループの中のクライアントを検索 (照会) し、どのようなデータをバックアップするのか、またそのデータがどこに置かれているのかを調べます。Backup は論理ボリュームが存在するかどうかを調べます。この情報は、次の規則に従って、disk-number と maximum-sessions という 2 つの変数に格納されます。

サーバーは savefs プローブによる出力に基づいて、バックアップグループ内のクライアントに対し、サーバーが並列処理できる最大数の範囲でそのセーブセッションを割り当てます。

  1. 最初に、サーバーは、バックアップグループ内のクライアントごとに 1 つのセーブセッションを割り当てます。

  2. 次に、セーブセッションがまだ残っていれば、各クライアントの物理ディスクごとに 1 つのセーブセッションを割り当てます。

  3. さらにセーブセッションが残っていれば、各クライアントの maximum-sessions とクライアント並列処理の最大数の範囲内で、disk-number の値ごとにセーブセッションを割り当てます。

バックアップデータの保持期間の指定方法

ブラウズポリシーと保持ポリシーを使って、復旧に使用できるデータを保存する期間を指定できます。ブラウズポリシーと保持ポリシーは、クライアントごとに指定できます。

ブラウズポリシーと保持ポリシーとは

Backup サーバーは、(構成されているクライアントリソースの数にかかわらず) クライアントマシンごとに 1 つのファイルインデックスと、すべてのクライアントのデータを追跡するための 1 つのメディアデータベースを保持しています。バックアップが完了するたびに、クライアントファイルインデックスの中に、バックアップされたファイルのエントリが作成されます。メディアデータベースには、各バックアップ操作で処理されたセーブセットとストレージボリュームごとに 1 つのエントリが入ります。

各クライアントファイルインデックスは、単一のクライアントマシンのデータをブラウズできる構造になっています。ユーザーは、復旧セッションの際に、1 つのファイルからファイルシステム全体まで自由に範囲を指定して、Backup でそのデータを再構築し、特定の時点での状態に復元できます。クライアントインデックスによって整合されるこの情報を使って、Backup はレベルに基づいてバックアップデータを組み立てるといった処理を自動的に行い、さらに、ファイル名やディレクトリ名の変更や削除などに対処できます。Backup はブラウズポリシーを使ってデータのライフサイクルを管理し、クライアントファイルインデックスのサイズを自動的に制御できます。

ブラウズポリシーによって、Backup サーバー上のクライアントのファイルインデックスにファイルが保持される期間が決まります。ブラウズポリシーの期間中であれば、ユーザーはバックアップされたデータを Backup の復旧プログラム (nwrecover) の中でブラウズし、個々のファイルまたはファイルシステム全体を選択して復旧できます。ファイルのブラウズポリシーの期限が切れると、Backup はそのファイルのエントリを自動的に削除します。Backup は、これらのエントリを削除することによって、急速に拡大するクライアントインデックスのサイズを管理しています。このエントリは、クライアントのスケジュールされたバックアップの際に、バックアップされるファイル 1 つにつき 1 つずつ格納されます。

メディアデータベースは、ストレージボリュームのセーブセットの位置を追跡できる構造になっています。Backup は保持ポリシーを使って、Backup が管理するデータの寿命を管理しています。エントリがメディアデータベース内に残っている限り、そのデータは復旧可能です。メディアデータベースのエントリを急いで削除しても無意味なので、メディアデータベースの保持ポリシーによってメディアデータベースのエントリが自動的に削除されることはありません。保持ポリシーは、セーブセットのエントリが誤って上書きされない期間を決めるためのものです。

保持ポリシーによって、Backup サーバーのメディアデータベースにセーブセットが保持される期間が決まります。保持ポリシーの期間中であれば、クライアントのバックアップされたセーブセットをメディアから復旧できます。セーブセットは、その保持ポリシーの期限が切れても、再利用可能の対象とはなりません。また、ストレージボリューム上のすべてのセーブセットの保持ポリシーの期限が切れても、そのストレージボリュームに対してラベルの付け直しや上書きはできません。セーブセットまたはストレージボリュームのエントリは、理論的には、保持ポリシーの期限が切れてからも長期にわたってメディアデータベースの中に残ることができます。エントリがメディアデータベースから削除されるのは、ストレージボリュームのラベルが付け直されるか、管理者がエントリを手動で削除した場合に限られます。

ブラウズポリシーの効果

クライアントファイルインデックスにエントリがあるファイルは、Backup の復旧プログラムを使って復旧できます。このプログラムでは、ファイルのブラウズとマーク付けを行なったり、データの復旧を開始したりできます。クライアントファイルインデックスのエントリは、必ずしも、ブラウズポリシーの期限が切れた時点ですぐに削除されるわけではありません。Backup は、ファイルに依存しているすべてのセーブセットのブラウズポリシーの期限が切れるまで、そのファイルのエントリを削除しません。また、一般に、ブラウズポリシーよりも古くなったフルバックアップのエントリは、さらにバックアップサイクル 1 回分の期間が経過するまでは削除されません。この猶予期間により、ブラウズポリシーの期間中の任意の時点の状態にファイルを再構築できます。

次に示す図は、ブラウズポリシーがクライアントファイルインデックス内のデータの使用にどのように影響を与えるかを示しています。スケジュールの詳細は 「スケジュールの構成」を、バックアップレベルの詳細は 「バックアップレベル」を参照してください。

図 5-1 では、バックアップサイクルとブラウズポリシーの両方が 1 週間に設定されています。バックアップサイクルはフルバックアップが実行される間隔です。10 月 2 日の最初のフルバックアップのエントリは、そのフルバックアップに依存するすべての差分バックアップとレベル 5 バックアップの 1 週間のブラウズポリシーの期限が切れるまでは、クライアントファイルインデックスに残っています。10 月 2 日のフルバックアップは、このフルバックアップに依存する差分バックアップとレベル 5 バックアップの期限が切れる 10 月 15 日までは削除されません。

図 5-1 ブラウズポリシーが 1 週間の場合

Graphic

ブラウズポリシーがこのように機能する理由を理解するための例として、10 月 12 日に、10 月 6 日にバックアップした情報を復旧する場合を考えます。6 日に行われたバックアップは、10 月 5 日のレベル 5 バックアップに依存する差分バックアップです。一方、10 月 5 日のレベル 5 バックアップは、10 月 2 日に行われたフルバックアップに依存しています。10 月 2 日に行われたフルバックアップのエントリは、ブラウズポリシーの期間 (1 週間) にバックアップサイクル 1 回分 (1 週間) を加えた期間、つまり、10 月 5 日のレベル 5 バックアップと、フルバックアップに依存するすべての差分バックアップのブラウズポリシーの期限が切れるまでは、クライアントファイルインデックスに残っている必要があります。図 5-1 に示した例では、1 週目のバックアップサイクルのエントリは、10 月 15 日にクライアントファイルインデックスから削除されます。

図 5-2 では、ブラウズポリシーは 2 週間で、バックアップサイクル (1 週間) の 2 倍です。この例では、10 月 19 日に、ユーザーはクライアントファイルインデックスで 10 月 5 日に作成されたバックアップのエントリをブラウズできます。10 月 6 日に行われたバックアップは、10 月 5 日に行われたレベル 5 バックアップに依存する差分バックアップです。一方、10 月 5 日のレベル 5 バックアップは、10 月 2 日に行われたフルバックアップに依存しています。10 月 2 日に行われたフルバックアップと、それに依存する差分バックアップとレベルバックアップは、ブラウズポリシーの期間 (2 週間) にバックアップサイクル 1 回分 (1 週間) を加えた期間だけ、クライアントファイルインデックスに残っている必要があります。この例では、1 週目のバックアップサイクルのエントリは、10 月 23 日まではクライアントファイルインデックスからは削除されません。

図 5-2 ブラウズポリシーが 2 週間の場合

Graphic

保持ポリシーの動作

Backup のメディア保持ポリシーを使って、バックアップされたデータが誤って上書きされない期間を指定します。この保持期間が経過すると、セーブセットの状態は復旧可能から再利用可能に変わります。ただし、セーブセットの状態は、そのセーブセットと、それに依存するすべてのセーブセットの保持ポリシーの期限が切れるまでは、再利用可能には変わりません。Backup は、依存しているセーブセットが同じメディアボリュームに格納されているのか、別のボリュームに格納されているのかにかかわらず、セーブセットの依存関係を追跡しています。セーブセットの保持ポリシーの期限が切れても、セーブセットのエントリがメディアデータベースから削除されるわけではありません。

ボリューム上のすべてのセーブセットの保持ポリシーの期限が切れて、ボリューム上のすべてのセーブセットの状態が復旧可能から再利用可能に変わると、Backup はそのストレージボリュームのモードを再利用可能に変更します。ボリュームには、それぞれ異なる保持ポリシーを持つ複数のバックアップセッションのセーブセットを格納できるので、ボリュームのモードが長期にわたって再利用可能に変わらない可能性があります。再利用可能という言葉は「再利用の対象になりうる」という意味です。ボリューム上のすべてのデータは、セーブセットに対して recover コマンドか、scanner コマンドを使用することによって復旧が可能な状態で残っています。メディアデータベースには、このような再利用可能なセーブセットのすべてのエントリが残っています。

状態が再利用可能に変わるのは、条件が満たされればボリュームの上書きが可能であるという消極的なマークに過ぎません。ボリュームをオートチェンジャに入れるか、スタンドアロンデバイスにマウントして、Devices リソースの自動メディア管理属性を有効にすると、そのボリュームは Backup によってラベルが付け直されて使用できるようになります。ボリュームのラベルが付け直されると、既存のデータは復旧不可能になり、上書きされたセーブセットのエントリはメディアデータベースから削除されます。この自動メディア管理機能の詳細は、「Backup でのラベルを付け直すストレージボリュームの選択方法」を参照してください。

ユーザーが Backup のボリュームインベントリからボリュームを手動で削除した場合も、セーブセットのエントリがメディアデータベースから削除されます。ただし、手動で削除されたボリューム上のデータは、scanner プログラムによる復旧が可能です。scanner プログラムは、クライアントファイルインデックスまたはメディアデータベース、あるいはこの両方のエントリを再作成するために必要な情報を取り出します。クライアントファイルインデックスのエントリが再作成された場合は、適切なアクセス権を持つユーザーが Backup の復旧プログラム (nwrecover) を使ってデータを復旧することができます。メディアデータベースの中のセーブセットのエントリが再作成された場合は、Backup 管理特権を持つユーザーがセーブセット復旧機能を使ってデータを復旧することができます。scanner プログラムの使用方法については、付録 B 「コマンド行リファレンス」 か、scanner プログラムのマニュアルページを参照してください。

図 5-3 に保持ポリシーの動作を示しています。この例では、バックアップサイクルは 1 週間に、保持ポリシーは 3 週間に設定されています。

図 5-3 バックアップサイクルが 1 週間、保持ポリシーが 3 週間の場合

Graphic

1 週目のセーブセットのエントリは、ブラウズポリシーと保持ポリシーの期限が切れても、ボリュームのラベルが付け直されるまでは scanner プログラムを使って復旧できます。ボリューム上のすべてのセーブセットのエントリの状態が再利用可能に変わると、ボリュームモードはフルまたは追加可能から再利用可能に変わり、ボリュームのラベルが付け直されて再利用できるようになります。ボリュームのラベルが付け直されると、そのボリューム上のデータは復旧できなくなります。

ストレージボリュームのモードの詳細は、表 4-3 を参照してください。

スケジュールの詳細は 「スケジュールの構成」を、バックアップレベルの詳細は 「バックアップレベル」を参照してください。

ブラウズポリシーと保持ポリシーによるデータライフサイクルの管理方法

クライアントセーブセットに関連付けられるブラウズポリシーと保持ポリシーによって、クライアントファイルインデックスとメディアデータベースのサイズの拡大と、データが復旧可能な状態にある期間の両方を制御します。図 5-4 は、クライアントファイルインデックスとメディアデータベースでのデータのライフサイクルを示しています。この例では、9 月 1 日から 9 月 7 日までのバックアップサイクルのエントリは、ブラウズポリシー (1 か月) にフルバックアップのサイクル (1 週間) を加えた期間だけクライアントファイルインデックスに残っています。このため、このエントリに依存するすべてのエントリのブラウズポリシーの期限後も復旧可能な状態が保たれます。この例では、9 月 1 日から 9 月 7 日までのバックアップサイクルのファイルインデックスエントリは 10 月 13 日に削除されます。エントリがクライアントファイルインデックスに残っているので、recover プログラムの GUI (nwrecover) を使ってデータをブラウズし、復旧することができます。セーブセットのファイルエントリがクライアントファイルインデックスに残っている間は、ソースセーブセットの状態はブラウズ可能になっています。セーブセットの状態がブラウズ可能から復旧可能になったら、直接ファイルを復旧することはできません。

9 月 1 日から 9 月 7 日までのバックアップサイクルの間にバックアップされた個々のセーブセットの状態は、その保持ポリシーの期限が切れて、さらに、それに依存するすべてのセーブセットの保持ポリシーの期限が切れるまでは、復旧可能になっています。この例では、9 月 1 日から 9 月 7 日までのバックアップサイクルのエントリは、12 月 8 日に復旧可能から再利用可能に変わります。ボリューム上のすべてのセーブセットエントリの状態が再利用可能に変わると、ボリュームそのもののモードがフルまたは追加可能から再利用可能に変わります。

セーブセットの状態が復旧可能または再利用可能になっている間は、セーブセット復旧機能か scanner プログラムを使って、任意のセーブセットをストレージボリュームから復旧できます。また、scanner プログラムを使ってクライアントファイルインデックスの中にセーブセットのエントリを再作成し、GUI から直接にファイルを復旧することもできます。セーブセット復旧機能と scanner プログラムの詳細は、「セーブセットの復旧と読み取り」を参照してください。

図 5-4 クライアントインデックスとメディアデータベースでのデータライフサイクル

Graphic

10 月 13 日には、9 月 1 日から 9 月 7 日までのすべてのデータエントリがクライアントファイルインデックスから削除されます。12 月 8 日には、メディアデータベースの中の 9 月 1 日から 9 月 7 日までのセーブセットエントリが復旧可能から再利用可能の状態に変わります。ボリューム上のすべてのセーブセットの状態が復旧可能から再利用可能に変わると、ボリュームモードが再利用可能に変わります。自動メディア管理機能が有効になっている場合には、ボリュームに自動的にラベルが付けられ、このボリュームがマウントされます。ボリュームのラベルが付け直されると、そのボリューム上のすべての既存のデータは復旧不可能になります。

注意 - 注意 -

同じプールの中でボリュームが再使用できるようにラベルが付け直されても、ボリューム識別名 (ボリュームラベルとして指定されたボリューム名) は変わりません。ただし、ラベルが付け直されると、Backup がボリューム上の既存の全データを見つけ出してアクセスするために必要なデータは破壊されるので、セーブセット復旧機能も scanner プログラムも使用できません。この時点で、ボリュームは新しいデータを受け入れる準備ができています。既存のデータはすべてアクセス不可能になり、上書きされます。

セーブセットの状態値

Backup は、バックアップされた個々のセーブセットに対してバックアップの成否とセーブセットデータの経過日数に基づいた状態を割り当てます。セーブセットの状態は次の場合に変わります。

表 5-1 に、セーブセットの状態の取りうる値を示します。

表 5-1 セーブセットの状態値

状態値 

意味 

説明 

abort

中止 

このセーブセットのバックアップを手動で中止した、または操作の途中でクラッシュが発生した。このセーブセットはただちに再利用の対象となる 

brows

表示可能 

このセーブセット内のファイルは、クライアントファイルインデックスにエントリが残っている。すべてのファイルはインデックスに基づく復旧操作によって復元可能 

inpro

処理中 

このセーブセットは、現在バックアップの処理中である 

recov

復旧可能 

このセーブセット内のファイルは、クライアントファイルインデックスの中に表示可能なエントリとして残っていないが、保持ポリシーの期限はまだ切れていない 

recyc

再利用可能 

このセーブセットと、復旧のためにこのセーブセットに依存しているすべてのセーブセットで、保持ポリシーの期限が切れている 

scann

scanner 実行済み

このセーブセットのクライアントファイルインデックスエントリは scanner プログラムを使って復元された。このエントリは、手動で削除されるまで、クライアントファイルインデックスとメディアデータベースの中に残っている

susp

要確認 

このセーブセットの復旧に失敗した。recover プログラムで、セーブセットのすべてのブロックを読み込むことができなかった。これはテープに不良箇所があった場合などに起こる

ポリシーのカスタマイズ方法

「Policies」リソースを使ってカスタマイズしたブラウズポリシーと保持ポリシーを作成できます。「Policies」リソースで、ポリシーに一意の名前を付け、期間を指定します。定義したポリシーは、「Clients」リソースの「Browse Policy」属性と「Retention Policy」属性の選択項目として表示されます。

セーブセットの復旧と読み取り

セーブセット復旧機能を使用すると、ブラウズポリシーの期限は切れているが、まだメディアデータベースに残っているバックアップデータを復旧できます。セーブセットを復旧するには、コマンド行から recover プログラムを実行し、オプションとしてセーブセット識別番号 (ssid) を指定するか、または Backup の管理プログラム (nwadmin) を使用します。ssid とともに具体的なパスを指定すれば、個々のファイルまたはディレクトリを指定できます。セーブセット復旧機能を実行するアクセス権はスーパーユーザーだけに与えられています。

セーブセット復旧機能は、エントリがオンラインファイルインデックスから削除されているとき (セーブセットのブラウズポリシーの期限が切れているとき) にのみ使用します。セーブセットを復旧するときには、まずフルレベルのバックアップで復旧したあとに、それ以外のバックアップをレベル 1 から 9 の順序で実行し、最後に差分バックアップで復旧します。

メディアデータベースにボリュームのエントリがない場合は、scanner プログラムを使用してクライアントファイルインデックスのエントリやメディアデータベースのエントリを作成し直すことができます。scanner プログラムでは、Backup からの支援なしにストレージボリュームから直接に読み込むことができます。

目的のファイルが格納されているボリュームを見つけるには、ボリュームがまだメディアデータベースに残っている場合は mminfo プログラムを、ボリュームがメディアデータベースにない場合は scanner プログラムを使用します。mminfo プログラムと scanner プログラムを実行すると、ボリュームの内容についての詳細な情報が得られます。この情報には以下のものが含まれます。

クライアントファイルインデックスのセーブセットエントリを再構築するには

ファイルが表示可能でない (セーブセットのブラウズポリシーの期限が切れている) が、そのセーブセットが Backup によってメディアデータベースの中で追跡されている (セーブセットの保持ポリシーの期限が切れていない) 場合には、次の操作を行なって、クライアントファイルインデックスにセーブセットのエントリを復旧できます。

  1. mminfo プログラムを実行します。


    # mminfo -a -v volume-name

  2. mminfo によって得られた出力情報から、目的のファイルを含んでいると思われる ssid を探します。それがブートストラップセーブセット ID でないことを確認します。

  3. 正しい ssid がわかったら、scanner プログラムを使って、ファイルインデックスの中のセーブセットエントリを置き換えます。


    # scanner -i -S save-set-id device-name

  4. Backup の recover プログラムを使って、ファイルに復旧対象のマークを付けます。

    注意 - 注意 -

    セーブセットがボリュームの境界にまたがっている場合は、scanner プログラムを使ってすべてのボリュームから読み込みを行います。これを実行しないと、クライアントファイルインデックスは完全には再構築されず、このセーブセットのファイルをオンラインで復旧できません。

  5. Backup の recover プログラムを使って、ファイルに復旧対象のマークを付けます。

クライアントファイルインデックスのメディアデータベースのセーブセットエントリを再構築するには

ファイルを格納しているセーブセットが表示不可能で、メディアデータベースにそのセーブセットのエントリがない場合には、ブラウズポリシーと保持ポリシーの両方の期限が切れています。クライアントファイルインデックスとメディアデータベースの両方のセーブセットエントリを再構築するには、以下の操作を行います。

    1. 目的のファイルが格納されていると思われるバックアップボリューム上で scanner プログラムを実行します。

      ボリュームに貼られているラベルをもとに推測するか、「ボリューム名を調べるには」の手順を使用します。


      # scanner device-name

    2. scanner プログラムによって得られた出力情報を使って、このボリュームの内容をクライアントファイルインデックスに再入力するべきか、また、再構築しようとしているセーブセットがこのボリューム上にあるかどうかを判断します。

      このセーブセット ID を含むすべてのボリュームを見つけ出す必要があります。

    3. どのボリュームをオンラインインデックスに再入力すべきかがわかったら、scanner コマンドを実行します。


      # scanner -i device-name

      scanner コマンドは、ユーザーがコマンドの終了を指定するまで、新しいボリュームを入力するように求めてきます。インデックスを完全に再構築するためには、この ssid を含んでいるすべてのボリュームに対して scanner コマンドを実行しなくてはなりません。

    4. nwrecover プログラムを使って、復旧しようとしているファイルのファイルインデックスを表示します。

セーブセット全体を Backup サーバーに復旧するには

セーブセット全体をディスクボリュームに直接復旧するには、次のオプションを指定して scanner プログラムを起動します。


# scanner -S save-set-id device-name | uasm -rv

このコマンドは、指定された ssid に関連付けられているすべての情報をボリュームから読み込み、このデータのコピーを、バックアップボリュームに格納されているのと同じように格納します。つまり、バックアップボリュームにクライアントのファイルが含まれていても、これらのファイルは Backup サーバーのハードドライブに復旧されます。

この操作を実行する前に確認したい場合には、uasm コマンドに -n フラグを付けます。この -n フラグを指定すると、scanner からの出力が /dev/null に送られ、セーブセットに含まれているすべてのファイル名のリストが出力されます。

また、rsh コマンド (またはこれに相当するコマンド) を次のコマンドと組み合わせて使用すれば、セーブセットが本来は Backup サーバーではなく Backup クライアントに置かれていた場合に、このセーブセットをクライアントに復旧することができます。


# scanner -S ssid device-name | rsh client "(cd destdir; /pathto/uasm -rv)"

ボリュームから直接ファイルを復旧するには

ボリュームからファイル単体を復旧するには、次のどちらかのコマンドを実行します。


# scanner -S save-set-id device-name | uasm -rv filename

または


# scanner -S save-set-id device-name | uasm -rv -m source=dest filename

uasm コマンドの -m オプションを指定すると、復旧されるファイルが source ディレクトリから dest (宛先) ディレクトリにマップ (再配置) されます。

スケジュールされたバックアップに対する処理命令の追加

「Clients」リソースの「Directive」属性と「Backup Command」属性を使用して、スケジュールされたバックアップにクライアントサイドのデータ処理のための命令を追加できます。

ディレクティブとは

ディレクティブとは、Backup が追加のデータ処理を開始するためにセーブセットデータに適用する特殊なプログラムです。たとえば、圧縮ディレクティブによって、バックアップされるデータの量を減らすことができ、場合によってはフルバックアップの実施日にバックアップボリュームを交換する必要もなくなるかもしれません。ディレクティブは、「Clients」リソースの「Directives」属性に関連付けられている選択可能なオプションとして表示されます。

ディレクティブには、バックアッププロセスを支援し、バックアップの効率を最大限に高め、特殊なファイルを処理するための命令が入ります。クライアントセーブセットに対するスケジュールされたバックアップの際に、Backup は指定されたファイルにディレクティブ命令を適用します。たとえば、「null」ディレクティブを使うと、特定のファイルをバックアップから完全に除外することができます。

カスタマイズしたディレクティブの作成

「Directives」リソースを使ってディレクティブを作成し、これを「Clients」リソースを使って特定のクライアントに適用できます。環境はそれぞれ異なるので、すべてのケースに当てはまるディレクティブの作成規則というようなものはありません。ここでは、管理者の参考となるように、よく行われるカスタマイズの例をいくつか紹介します。

例 : Solaris クライアント上の特定のディレクトリをバックアップするためのディレクティブ

client123 のディレクトリ /aaa/zzz だけを保存する場合を考えます。ここではディレクティブを使って、Backup がディレクトリ /aaa と /zzz の中で、余分に他のファイルやサブディレクトリを検出し、バックアップさせないようにします。このディレクティブは null という UNIX アプリケーション固有のモジュール (uasm) を呼び出します。null を使用すると、指定されたディレクトリ内のファイルは除かれます。+null を使用すると、指定されたディレクトリ内のファイルと、それより下位の指定されたディレクトリ内のファイルは除かれます。/aaa/zzz だけをバックアップするためのディレクティブの内容は、次のようになります。


<< / >>
  uasm: 	aaa
  null: *.?
<< /aaa >>	
  uasm: zzz
<< /aaa/zzz >> 
  +uasm: *.?*

別の例として、root 以外のすべてのマウントされたディスクと、root 以外のディスクの /home および /users ディレクトリをバックアップする場合を考えます。また、これ以外にも cron ファイルとカレンダーデータベースもバックアップします。各クライアントについて、「Save Set」属性の値は「All」になっています。この場合のディレクティブは次のようになります。


<< / >>
  uasm: home users var
  null: *.?*
  +null: core
<< /home >>
  +compression: *.?*
  +null: core
<< /users >> * 
  compression
  +null: core
<< /var >>
  uasm: spool
  null: *.?*
  +null: core
<< /var/spool >>
  uasm: calendar cron
  null: *.?*
  +null: core
<< /var/spool/calendar >>
  +compression: *.?*
  +null: core
<< /var/spool/cron >>
  +compression: *.?*
  +null: core
<< /cdrom >>
  null: *.?*
<< /opt >>
  null: *.?*
<< /tmp >>
  null: *.?*
<< /usr >>
  null: *.?*

ディレクティブの一部に null を使用すると、特定のバックアップの際に、指定したファイル (複数の場合もある) は保存されませんが、Backup が作成するインデックスリストにはそのエントリが追加され、それらのファイルがバックアップ操作に含まれていたことが示されます。指定したファイルはインデックスに含まれているので、そのファイル名はディレクトリ内で表示可能となり、Backup から見たファイルシステムの様子は、実際のファイルシステムとまったく同じになります。つまり、最新のバックアップでは除外されていて、復旧に使われるデータが他のファイルのデータよりも古いものであっても、recover プログラムの GUI には、復旧に使われるファイルとして表示されることになります。

この動作は、ディレクティブに skip という uasm を使った場合の処理とはいくぶん異なります。skip という uasm を使用すると、ブラウザには、実際のファイルシステムに類似のものでなく、実際にバックアップされたデータだけを反映したファイルシステムのビューが表示されます。したがって、技術的な利点の面からも、skip よりも null を使用することをお勧めします。

バックアップコマンド

「Clients」リソースには、追加処理を指定するためのカスタマイズしたバックアップコマンドを入力できます。このカスタマイズしたバックアップコマンドは、スケジュールされたバックアップが開始されるときに、デフォルトの save プログラムの代わりに使用されます。

savepnpc プログラムを使うと、クライアントバックアップ 1 回ごとに一度ずつ前処理コマンドと後処理コマンドを実行することができます。savepnpc プログラムは save プログラムと同様に、ファイルを長期保存用のストレージに保存します。savepnpc は、クライアントに対して最初の保存操作を実行する前に、/nsr/res/<group_name>.res ファイルに含まれている前処理コマンドをすべて実行します。また、クライアント上で最後の保存操作が完了した後に、/nsr/res/<group_name>.res ファイルに含まれている後処理コマンドをすべて実行します。savepnpc の詳細は、「savepnpc 」と savepnpc のマニュアルページを参照してください。

Backup がクライアントファイルシステムのデータをバックアップする方法に影響を与えるような追加プログラムを作成することによって、クライアントバックアップをカスタマイズできます。

たとえば、Backup がバックアップ操作を実行する前にメールサーバーやデータベースを終了し、バックアップが完了したあとにこのメールサーバーやデータベースを再起動するプログラムを作成できます。あるいは、バックアップ操作が開始される前にメッセージ (「backup started at 3:33 a.m.」など) を出力し、クライアントデータのバックアップを実行し、バックアップが完了した時点でメッセージ (「backup completed at 6:30 a.m.」など) を出力するようなプログラムも作成できます。

バックアップコマンドは、そのクライアントに対して定義されている各セーブセットに対して実行されるのであって、クライアントごとに実行されるわけではありません。管理者がセーブセット値として「All」を指定すると、バックアップコマンドのバッチファイルはクライアント上のファイルシステムの数だけ実行されます。カスタマイズしたバックアップコマンドの最も単純な例として、「Save Set」属性に単一のセーブセットを指定して特別なクライアントを作成する手法があります。

使用している環境に最も合ったカスタマイズレベルを考える際には、次の事柄を検討してください。

注意 - 注意 -

savepnpc とは異なり、カスタマイズしたバックアップコマンドの新しいインスタンスは、標準の保存プログラムと同様に、「Save Set」属性に指定されている個々のセーブセットごとに起動されます。データベース用のカスタマイズしたバックアップコマンドで「Client」リソースを作成するときには、この点に注意してください。指定された個々のセーブセットごとに、シャットダウンコマンドが実行されます。

カスタマイズしたバックアップコマンドを作成するには

バックアッププログラムまたはバッチファイルの作成に使用される構文は、以下に示す基準に従っていなければなりません。以下に項目のリストとプログラミングの例を示します。これらの基準に従うことができない場合には、独自のバックアップコマンドは作成しないでください。

プログラムには、次に示す順序でコマンドが含まれていなければなりません。

バックアップの前処理または後処理のコマンドを作成するには、次の操作を行います。

  1. テキストエディタを使用して、Backup の save コマンドが置かれているディレクトリにプログラムファイルを作成します。

  2. 「Clients」リソースの「Backup Command」属性に、バックアッププログラム名を入力します。

  3. 作成したバックアップコマンドが動作することを確認するために、クライアントをバックアップしてみます。

例 : カスタマイズしたバックアップコマンド

次に示すスクリプトは、前処理と後処理を実行するカスタマイズしたバックアップコマンドの例です。このスクリプトは Clear Case VOB (Version Object Base) をロックし、バックアップを実行してから、VOB をロック解除します。


#!/bin/sh
# export the SHELL that we are going to use
SHELL=/bin/sh
export SHELL
# export the correct PATH so that all the required binaries can be
found
case $0 in
/* ) PATH=/usr/atria/bin:/bin:/usr/bin:`/bin/dirname $0`
c=`/bin/basename $0`
;;
* )PATH=/usr/atria/bin:/bin:/usr/bin:/usr/sbin
c=$0
;;
esac
export PATH
# These are the valid statuses which save reports on completion of
the backup
statuses="
failed.
abandoned.
succeeded.
completed savetime=
"
# Perform the PRECMD (Lock VOB)
/usr/atria/bin/cleartool setview -exec
"/usr/atria/bin/cleartoollock -c ¥
  `VOB backups in progress' -vob /cm_data/mis_dev" magic_view >
/tmp/voblock.log 2>&1
# Perform backup on client
save "$@" > /tmp/saveout$$ 2>&1
# cat out the save output
cat /tmp/
saveout$$# search for the backup status in the output reported by save
for i in ${statuses}; do
      result=`grep "${i}" /tmp/saveout$$`
      if [$? != 0]; then
               echo ${result}
      fi
done
# Perform the POSTCMD (Unlock VOB)
/usr/atria/bin/cleartool setview -exec
"/usr/atria/bin/
cleartoolunlock -vob
/cm_data/mis_dev" ¥
    magic_view > /tmp/vobunlock.log 2>&
# make sure to gracefully exit out of this shell script
exit 0

他のクライアントにリモートアクセス権を与える方法

Backup クライアントは、そのファイルを表示または復旧できるのはそのクライアントだけに限定されるように、事前に構成されています。セキュリティが重要な企業では、「Remote Access」属性を空白のままにして、バックアップされたファイルを復旧できるのはそのクライアントだけに限定します。

他のユーザーまたはマシンに、クライアントのファイルを復旧するためのアクセス権を与えるには、「Clients」リソースの「Remote Acess」属性に、ユーザー ID とホスト名 (user@hostname の形式) または netgroup 名 (NIS を使用している場合) を入力します。

リモートアクセス権が有効になっていると、権限を持つユーザーは Backup の復旧プログラムを使って他の Backup クライアントのファイルを表示し、復旧することができます。復旧プログラムで、そのクライアントに移って、目的のファイルを表示または復旧します。

スケジュールされたバックアップの際に、クライアントでバックアップコマンド (save と savefs) を実行するアクセス権を制限するには、「Clients」リソースの「Remote User」属性にユーザー ID を入力します。この属性が空白になっていると、ユーザー名はデフォルトで root になります。