test

Solstice Backup 5.1 管理者ガイド

第 4 章 デバイスとメディアの管理

この章では、Backup サーバーによって行われるデバイス操作とメディア操作について説明します。この章は次の節で構成されています。

デバイスの構成

デバイスとは、バックアップや復旧などの操作の際に、ストレージボリュームとの間でデータの読み書きを行うドライブのことです。「Devices」リソースには、個々のデバイスの属性が含まれています。デバイスの構成方法は、そのデバイスがスタンドアロンなのか、あるいはオートチェンジャやサイロに含まれているのかによって異なります。

Backup サーバーにストレージデバイスを認識させるためには、各ストレージデバイスを個別に構成する必要があります。

ストレージデバイスとしてテープドライブを使用する場合には、非巻き戻し型式のデバイスを使用します。これは、各バックアップの終了時にバックアップボリュームにファイルマークが書き込まれ、このファイルマークの位置に基づいて、データがボリュームに追加されるためです。デバイスがデータを巻き戻すとファイルマークの位置がわからなくなり、書き込まれているデータが次のバックアップ処理の際に上書きされます。これらのデバイスのパス名は、/dev/rmt/Ombn のように、Berkeley Storage Device(BSD) のセマンティクス規則に従っていなくてはなりません。この例では、パス名の中の b が、この規則の条件を満たしています。

ファイルデバイスを使用する場合には、ファイル名だけでなく、他のデバイスタイプの場合と同様にディレクトリパスとして入力する必要があります。Solaris サーバーでは /tmpfs というパスは使用できません。

Backup がサポートしているストレージデバイスとメディアタイプ

Backup がサポートしているストレージデバイスと、それらに対応するバックアップメディアを次に示します。

スタンドアロンデバイスの構成

Backup サーバーまたはストレージノードにスタンドアロンデバイスを接続している場合には、Backup サーバーで「Devices」リソースを表示し、そのリソースの属性の設定値を入力または変更します。

オートチェンジャデバイスの構成

オートチェンジャやサイロなどのマシンは複数のデバイスから構成されています。複数のデバイスから構成されるマシンのデバイスを構成するためには、そのマシンがオートチェンジャかサイロかに応じて、いくつかの手順が必要です。

オートチェンジャ内のデバイスを構成するには、Backup サーバーまたはストレージノードマシンに Backup デバイスドライバをインストールし、これを有効にしたあとに、jb_config プログラムを使ってオートチェンジャを構成し、「Devices」リソースでオートチェンジャの個々のデバイスを定義します。オートチェンジャの詳細は、第 7 章「オートチェンジャモジュール」を参照してください。

サイロ内のデバイスを Backup 用に構成するには、まず Backup サーバーまたはストレージノードマシンに Backup のサイロサポートモジュールをインストールし、これを有効にしたあとに、jb_config プログラムを使ってサイロとそのデバイスを構成します。サイロ内のデバイスの変更や削除には、「Devices」リソースは使用しません。サイロの詳細は、第 10 章「サイロサポートモジュール」を参照してください。

ハードウェア圧縮とソフトウェア圧縮

データをネットワーク上で移動したり、テープに書き込んだりする前に、Backup クライアントマシンによってバックアップの過程でデータを圧縮できます。ソフトウェア圧縮を行うには、「Clients」リソースで圧縮ディレクティブを選択するか、あるいはカスタマイズしたバックアップコマンドに compressasm を追加します。compressasm を追加することによって、一般には 2:1 の圧縮率を達成できます。ソフトウェア圧縮は、ネットワーク上で移動されるデータの量が減るというパフォーマンス上の利点に加えて、テープに不良箇所がある場合には一部のハードウェア圧縮に比べて機能の面で優れています。

テープに不良箇所があるために生じる EOT (テープの終わり) エラーに対処するために、Backup では固定サイズの後書きバッファを使用しています。Backup は、次のテープを要求するときに、後書きバッファの内容も新しいテープに書き出します。書き出されていないデータのサイズが Backup のバッファよりも大きい場合は、EOT の処理は行われません。後書きバッファは、圧縮に対応していないテープドライブに対応できるように、有限サイズになっています。また、この後書きバッファは、ドライブのバッファからテープに書き込むときにデータ圧縮するタイプのテープドライブでは使用できますが、ドライブのバッファにデータをコピーするときにデータ圧縮するタイプのドライブでは使用できません。ドライブのバッファは、バイト換算で 1.5 倍から 3 倍の比率でデータを圧縮し、ときにはこれよりもはるかに高い圧縮率を実現します (一部のドライブでは 10:1 の圧縮率を持つ)。この 10:1 という圧縮率に対応するためには、後書きバッファのサイズは、非常に大きくなければなりません。しかし、実際に使用されるメモリーとスワップ空間を考えると、実際には不可能です。

自分の環境にどの圧縮方式が合っているかを検討する際には、次の事柄を念頭に置いてください。

ストレージノード、リモートデバイス、および複数のネットワークインタフェース

オートチェンジャやサイロなどのローカルおよびリモートのデバイスに対する操作の大部分は、サーバーの Backup 管理プログラムから制御できます。ただし、リモートオートチェンジャに対するリセットなどの一部の操作では、ストレージノードマシンで nsrjb コマンドか jb_config プログラムを使用しなければならない場合もあります。データ転送操作においては、Backup サーバーはリモートデバイスをローカルデバイスと同じように使用します。

注意 - 注意 -

リリース 4.2 以降の Backup クライアントは、バックアップ、アーカイブ、および HSM (階層型ストレージ管理) 機能にリモートデバイスを使用できます。これより前の Backup クライアントでは、リモートデバイスに対してデータをバックアップできません。

この節ではネットワークインタフェースについても説明しています。デフォルトのネットワークインタフェースを変更することもできます。また、異なるネットワークインタフェースを使用している複数のクライアントを、同じストレージノードにまとめることができます。

リモートデバイスの構成

スタンドアロンのリモートデバイスは、Backup サーバーに接続されているスタンドアロンデバイスを構成するのと同じ方法で、制御元の Backup サーバーの管理セッションで構成します。個々のデバイスを作成するときには、デバイス名の前に rd= とストレージノードのホスト名を追加します。たとえば、rd=omega:/dev/rmt/1mbn は、omega という名前のストレージノードマシン上に /dev/rmt/1mbn という名前のデバイスを作成します。具体的な方法については、オンラインヘルプで、構成対象のデバイスの項を参照してください。

オートチェンジャまたはサイロのリモートデバイスを構成するには、次の 2 つの手順で行います。まず、制御元サーバーの「Server」リソースの「Administrator」属性に、ストレージノードが root@hostname という形式で入力されていることを確認します。hostname はストレージノードのホスト名です。次に、ストレージノードマシンで jb_config プログラムを実行し、オートチェンジャまたはサイロ内の各デバイスを定義します。このプログラムの構文とオプションについては、「jb_config」か、jb_config のマニュアルページを参照してください。

jb_config プログラムが終了したら、「Administrator」属性からストレージノードのホスト名を削除できます。後から新しいオートチェンジャを追加する場合には、ストレージノードのホスト名を「Administrator」 属性に追加してから jb_config プログラムを実行し直す必要があります。

複数のネットワークインタフェース

デフォルトインタフェース以外のインタフェースを使用する場合には、サーバーネットワークインタフェース属性を使用します。クライアントのサーバーネットワークインタフェース属性よりも優先して使用したいインタフェースを入力します。

save を実行するときには、ストレージノード上に複数のネットワークインタフェースが定義されていてもかまいません。ストレージノードのインタフェースは「Storage Nodes」属性で指定します。この属性を指定すると、複数のクライアントが同じストレージノードに対して異なるネットワークインタフェースを使用できるようになります。

メディア管理

この節では、Backup のメディア管理機能の概念について説明します。メディア管理機能は、GUI 版の Backup 管理プログラム (nwadmin)、nsradmin インタフェース、または nsrmm コマンドを使って構成できます。個々の属性の詳しい説明はオンラインヘルプにあります。これらの Backup インタフェースの詳細は、nsradmin と nsrmm のマニュアルページを参照してください。

プール

プールとは、Backup がデータの書き込み先として使用する特定のメディアの集合のことです。Backup では、プールを使ってデータのソートと格納を行います。各プールの構成設定は、どのデータをどのボリュームに書き込むかを Backup に指示するためのフィルタの役割を果たしています。

Backup は、プールとラベルテンプレートを使って、各ボリュームにどのようなデータが含まれているかを追跡します。ラベルテンプレートの詳細は、「ストレージボリュームのラベル付け」を参照してください。

Backup でのプールの使用方法

プールを構成することによって、どのボリュームにデータを書き込むかを決めます。個々のプール構成には、そのプールに関連付けられているボリュームに書き込まれるデータが満たさなければならない基準が含まれています。プールに入れるセーブセットを指定するときには、具体的なセーブセット名で指定することも、正規表現による照合を使ってセーブセットのグループを特定のプールに送ることもできます。正規表現による照合の使用例については、「例 : クライアントインデックスとブートストラップを別々のプールに送る方法」を参照してください。正規表現による照合の詳細は、nsr_regexp のマニュアルページを参照してください。

スケジュールされたバックアップが実行されるときには、最初に、セーブセットとプール構成が照合されます。セーブセットがプール構成の基準に合致すると、そのプールのラベル付きボリュームにセーブセットが送られます。

次に、正しくラベル付けされたボリュームがストレージデバイスにマウントされているかどうかが確認されます。ストレージデバイスに正しくラベル付けされたボリュームがマウントされていれば、そのボリュームにデータが書き込まれます。ストレージデバイスに正しくラベル付けされたボリュームがマウントされていない場合には、Backup は該当するボリュームをマウントするように指示を出し、そのボリュームがマウントされるまで待ちます。

Backup のプールタイプ

Backup には、各種のデータを分類するために、事前構成済みのプールタイプが用意されています。1 つのプールの中で、次に示すタイプのデータを混在させることはできません。

特にプールを指定した場合を除いて、バックアップデータは「Default」プールに送られ、アーカイブデータは「Archive」プールに送られます。クローンのバックアップデータは「Default Clone」プールに送られ、クローンアーカイブデータは「Archive Clone」プールに送られます。

Backup でのプール基準によるデータのソート方法

Backup を構成するときには、プールを追加作成し、プールのタイプと次に示す 4 つの基準を任意に組み合わせて、データをソートできます。

「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 は次に示すプール選択基準を使用します。

  1. 「Group」 (最も高い優先順位)

  2. 「Client」

  3. 「Save set」

  4. 「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 が正しいボリュームを指定して要求します。

注意 - 注意 -

手動バックアップの場合には、クライアントインデックスとサーバーブートストラップはバックアップされません。クライアントとサーバーマシンについて通常のスケジュールされたバックアップをまったく行わないと、障害時にデータ復旧に必要な情報を入手できなくなります。

ストレージデバイスとプール構成によるデータのソート

プールを構成して、ソートしたデータを複数のストレージデバイスに割り振ることができます。このとき、データを入れるメディアを特別に指定したり、特定のプールからのデータを受け取るストレージデバイスを特別に指定したりできます。

特定のデバイスに送られるバックアップデータ用のプール

プールを特定のストレージデバイスに関連付けることができます。たとえば、フルバックアップをオフサイトで保管するために光ディスクに書き込む場合などです。データを特定のストレージデバイスに送る方法は 2 つあります。

複数のメディアタイプに書き込まれるバックアップデータ用のプール

ストレージデバイスにマウントされたボリュームに、そのプールに関連付けられているラベルが付いている場合には、異なるメディアタイプ (たとえば磁気ディスクとテープなど) の複数のボリュームにデータを書き込むことができます。

ストレージボリュームのラベル付け

Backup では、各ストレージボリュームに、1 つのプールに対応する一意の内部ラベルを付けて初期化します。バックアップやその他の操作の際に、特定のボリュームが属するプールをそのラベルによって識別できます。Backup では、ラベルテンプレートを使用して、ボリュームごとに一意の内部ラベルを作成します。

Backup はラベルテンプレートとプール構成設定を使用して、メディアボリューム上のデータのソート、格納、および追跡を行います。データを復旧する必要が生じると、Backup は必要なデータが入っている特定のボリュームのボリューム名とシーケンス番号をユーザーに示します。

Backup でのラベルテンプレートの使用方法

Backup では、特定のデータセットが特定のプールに書き込まれます。Backup が、特定のボリュームが正しいプールに属していることを認識するためには、ボリュームに、正しいプールに関連付けるための内部識別ラベルを付けなくてはなりません。ボリュームラベルの内容は、「Label Templates」リソースの中で作成した特定のラベルテンプレートに定義されている規則に従います。ユーザーは、ラベルテンプレートを「Pools」リソースの中の特定のプールに関連付けます。データを特定のプールに関連付けていない場合には、事前構成済みの「Default」プールと、それに対応する「Default」ラベルテンプレートが使用されます。図 4-1 に、プール構成において、関連付けられたラベルテンプレートを使ってボリュームにラベルを付ける方法を示します。「Pools」リソースでカスタマイズしたテンプレートを使用するためには、プールを構成する前に、それに対応するラベルテンプレートを構成しておく必要があります。

図 4-1 Backup がラベルテンプレートを使ってボリュームにラベルを付ける方法

Graphic

ラベルテンプレートのカスタマイズ方法

ラベルテンプレートをカスタマイズするには、「Label Template」リソースを表示し、次に示す属性の値を指定します。

表 4-1 ボリュームラベルの数値シーケンスの例

要素のタイプ 

フィールド 

結果として得られる数値シーケンス 

ラベルの総数 

数値の範囲 

001-100

001, 002, 003,...100

100 

文字列 

数値の範囲 

SalesFull

001-100

SalesFull.001,...

SalesFull.100

100 

小文字の範囲 

数値の範囲 

aa-zz

00-99

aa.00,...aa.99,

ab.00,...ab.99,

ac.00,...ac.99,

:

az.00...az.99,

ba.00,...ba.99

:

zz.00,...zz.99

67,600 (262 x 102)

バックアップメディアストレージシステムの拡張に備えて、ラベルテンプレートには余裕を持たせます。たとえば、テープ 10 本分のテンプレートを作成して、ラベルが足りなくなるよりも、テープ 100 本分のテンプレートを作成して、その一部だけを使用する方が望ましいといえます。テンプレートの数値シーケンスの終わりに達すると、開始値に戻ります。たとえば、表 4-1 では、67,600 番目のラベルである zz.99 の次の 67,601 番目のラベルは aa.00 になります。

ラベルテンプレート要素の使い方

Backup には、事前構成済みのプールに対応して事前構成済みのラベルテンプレートが用意されています。ユーザーが独自のテンプレートを作成する場合には、そのシステム編成に合わせて、必要な数の要素を「Fields」属性に入れることができます。ただし、2、3 個の要素にとどめておいて、テンプレートをできるだけ単純なものにするようにお勧めします。たとえば、経理部門向けにラベルテンプレートを作成する際には、ストレージシステムのサイズとメディアデバイスの能力に応じて、ラベルテンプレートをカスタマイズするいくつかの方法があります。表 4-2 に、要素を使ってラベルを作成する例を示します。

表 4-2 ラベルテンプレート要素

システム編成のタイプ 

フィールド (要素) 

 

区切り文字 

結果として得られるボリュームラベル 

シーケンシャル 

AcctFull

001-100

ピリオド 

AcctFull.001

(合計で 100 個のラベル)

ストレージ指向 (たとえば、5 段の棚があるストレージラックが 3 つあり、各棚に 100 個のテープがある場合) 

1-3

1-5

001-100

ダッシュ 

1-1-001

このラベルは、棚 1 のラック 1 にある最初のテープのラベルである

(合計で 1,500 個のラベル)

2 面からなるメディア (光ドライブなど) 

AcctFull

000-999

a-b

下線 

AcctFull_000_a (サイド 1)

AcctFull_000_b (サイド 2)

(合計で 2,000 個のラベル)

ストレージ管理操作 (ラベル付けとマウント)

ボリュームの内部ラベルには、Backup がストレージメディアの追跡と認識に使用する一意の名前が付いています。メディアデータベースの中で、ボリュームはそのボリュームラベルによって参照されます。このメディアデータベースレコードを使用して、データのバックアップや復旧に必要なボリュームが決められます。

すべてのボリュームはいずれかのプールに属しています。各プールにはラベルテンプレートが関連付けられています。ボリュームは、このラベルテンプレートの規則に従ってラベル付けされます。ラベルテンプレートにより、ユーザーが使用したボリュームの数を記録しなくても、ボリュームに一貫性のある名前とラベルを付けることができます。ユーザーは、Backup 製品に用意されている事前構成済みのプールと事前構成済みの (関連付けられた) ラベルテンプレートを使用することも、プール、ラベルテンプレート、およびプールとテンプレートの関連付けを独自に作成することもできます。独自のラベルテンプレートをカスタマイズすることで、データストレージの編成をより細かく制御できます。

ボリュームに新しい内部ラベルを付けたり、再利用するボリュームにラベルを付け直したりすると、元のラベルのボリュームに格納されている既存のデータは復旧不可能になります。

ボリュームの選択とマウントに関する Backup の基準

スケジュールされたバックアップまたは手動バックアップが実行されるときに、Backup は適切なプールから、書き込むべきデータを入れるボリュームを探します。Backup で使用できるストレージボリュームには、スタンドアロンデバイスにマウントされているボリュームのほかに、自動メディア管理機能を使って、またはオートチェンジャかサイロを使ってアクセスできるボリュームがあります。

適切なボリュームがマウントされていないときにファイルをバックアップしようとすると、「Pending」ディスプレイに次のようなメッセージが表示されて、書き込み可能なボリュームをマウントするように指示されます。


media waiting: backup to pool `Default' waiting for 1 writable
backup tape or disk

データ復旧が開始されると、バックアップされたデータが入っているボリュームをマウントするように求めるメッセージが次のように「Pending」ディスプレイに表示されます。


media waiting: recover waiting for 8mm 5GB volume-name

ファイルの復旧に複数のボリュームが必要な場合には、「Pending」ディスプレイにすべてのボリュームが復旧に必要な順序で表示されます。さらに、復旧プロセスの過程で、必要なボリュームが一度に 1 つずつ表示されます。

Backup が使用するストレージデバイスに複数のボリュームがマウントされている場合、Backup は次の階層関係を使って、データの書き込み先のボリュームを選択します。

ボリュームにラベルを付けるには

ボリュームラベルは Backup が使用する一意の内部コードで、そのボリュームを Backup で使用できるように初期化し、ストレージボリュームを特定のプールの一部として識別するためのものです。ボリュームにラベルを付けるには、次の操作を行います。

  1. Backup ストレージデバイスに、ラベルの付いていない、または再利用可能なボリュームを入れます。

  2. Backup を使ってボリュームにラベルを付けます。Backup 管理プログラムか nsrmm コマンドを使用します。

    次の 3 つのオプションがあります。

    • ラベルを付けるボリュームに対してプールを選択しないと、「Default」プールに関連付けられているラベルテンプレートが自動的に使用されます。

    • テンプレートに関連付けられないラベル名を作成するには、「Label」リソースの「Volume Name」属性を編集し、一意のラベル名を入力します。

    • ボリュームにラベルを付けるときに「Manual Recycle」属性を有効にしても、保持ポリシーに従ってボリュームに再利用可能のマークが自動的に付けられることはありません。ボリュームを再利用可能としてマークできるのは管理者だけです。

    Backup は、ボリュームにラベルを付ける際に、まずそのボリュームにラベルが付いていないことを確認します。次に、「Volume Name」属性に指定されている名前を使って、ボリュームにラベルを付けます。これは、選択プールに関連付けられているラベルテンプレートによって決まる次のシーケンシャルラベルか、ユーザーが入力して上書きしたボリューム名です。

    同じプールにある再利用可能なボリュームにラベルを付け直した場合、ボリュームのラベル名とシーケンス番号は同じままですが、ボリューム上の元のデータにはアクセスできなくなり、そのボリュームは新しいデータに使用できるようになります。

    ボリュームにラベルが付いてデバイスにマウントされると、そのボリュームはデータを受け取る準備ができたことになります。Backup ラベルはマシンが読める内部的な形式に過ぎないので、各ボリュームに内部ボリュームラベルと同じ名前のラベルを貼っておくことをお勧めします。オートチェンジャでバーコードラベルを使用する方法については、「オートチェンジャでのバーコードラベルの使用方法」を参照してください。サイロでバーコードラベルを使用する方法については、「サイロ内のボリュームへのラベル付け」を参照してください。

ボリュームをマウントし、マウントを解除するには

ボリュームをマウントするコマンドを実行した時点で、または Backup が自動メディア管理機能によってボリュームをマウントした時点で、ストレージデバイスにロードされているボリュームは、Backup からのデータを受け取るための準備ができています。たとえば、テープがマウントされている場合には、デバイスの読み書きヘッドがテープの空白箇所の先頭に置かれ、書き込みの準備ができています。

デバイスにボリュームをマウントするには、Backup 管理プログラムかコマンド行を使用します。

ボリュームにラベルを付けてマウントすると、Backup 管理プログラムの中で、「Devices」リソースのデバイスのパス名の横にボリューム名が表示されます。

スタンドアロンデバイスを使用して無人バックアップを行う場合は、無人にする前に、ラベルが付けられたボリュームをデバイスにマウントしておく必要があります。

注意 - 注意 -

Backup では非巻き戻し型式のデバイスしか使用できません。巻き戻し可能なデバイスを使用すると、読み取り/書き込みヘッドの位置がボリュームの先頭に直されて、以前にバックアップしたデータが上書きされてしまいます。

リモートデバイスのタイムアウトの設定

リモートデバイスのストレージノードに対するマウント要求をタイムアウトさせ、別のストレージノードに保存することもできます。リモートデバイスに対するマウント要求のタイムアウトを変更するには、「Devices」リソースの「Save Mount Timeout」属性と「Save Lockout」属性を設定します。「Save Mount Timeout」属性に指定されている時間 (分単位) 内にマウント要求が受け入れられないと、ストレージノードは「Save Lockout」属性に指定されている時間 (分単位) だけ保存データを受信できなくなります。「Save Mount Timeout」属性のデフォルト値は 30 分です。「Save Lockout」属性のデフォルト値はゼロで、その場合、ストレージノードのデバイスは保存データのためのマウント要求を受信し続けます。

注意 - 注意 -

「Save Mount Timeout」属性は、保存要求の対象となる最初のボリュームだけに適用されます。

ボリューム名を調べるには

ボリュームに貼られたラベルが剥がれてしまったり、読めなくなったりした場合には、Backup 管理プログラムかコマンド行を使って、ボリューム名を調べることができます。

Backup でのラベルを付け直すストレージボリュームの選択方法

バックアップデータは、特定のプールのボリュームに送られます。データを書き込む準備ができると、Backup はアクティブなデバイスを監視し、適切なプールに属するボリュームを探し出します。

プールの中に、マウントされた追加可能なボリュームが 1 つしか存在しない場合には、データはそのボリュームに送られます。

同じプールの 2 つのボリュームがデバイスにマウントされていると、Backup は次の要因を考慮して、ボリュームを選択します。

Backup が適切なプールからマウントされたボリュームを見つけられないと、マウントするように要求されます。自動メディア管理機能が有効になっていない場合、または スタンドアロンデバイスしか使用できない場合は、ボリュームがマウントされ、バックアップが開始できるようになるまで、繰り返しマウント要求が表示されます。

自動メディア管理

自動メディア管理により、Backup はストレージデバイスにロードされているメディアを自動的に制御できます。「Devices」リソースで自動メディア管理機能が有効になっている場合に、ラベルが付いていないと判断されたボリュームに自動的にラベルが付けられ、このボリュームがマウントされ、上書きされます。また、デバイスにロードされているボリュームを自動的に再利用できるようにします。自動メディア管理機能は、「Devices」リソースのスタンドアロンデバイスに対してのみ有効です。オートチェンジャ内のデバイスに対して自動メディア管理機能を有効にする方法については、「オートチェンジャデバイスによる自動メディア管理」を参照してください。

Backup は、次の条件が満たされたときに、ボリュームにラベルが付いていないと判断します。

ボリュームの密度が異なると、自動メディア管理機能によってラベルが付け直されることがあるので、まだ有効な値を持っているデータを誤って上書きしてしまう可能性があります。このため、Backup ボリュームが異なる密度のデバイス間で共有されるときには、特に注意が必要です。

自動メディア管理機能が有効になっていない場合には、ラベルの付いていないメディアは無視され、バックアップの書き込み先としては考慮されません。

スタンドアロンデバイスに対して自動メディア管理機能が有効になっている場合に、バックアップ時にボリュームに空きがない場合、次のように処理されます。

  1. 書き込み可能なボリュームを挿入するように通知されます。同時に空き領域のない検証済みのボリュームをマウント解除が必要となります。

  2. Backup はデバイスを監視し、デバイスに別のボリュームが挿入されるのを待ちます。

  3. ボリュームが挿入されたことが検出されると、そのボリュームにラベルが付いているかどうかがチェックされます。ラベルが付いていれば、Backup によってそのボリュームがマウントされます。このボリュームがデータの書き込み先の候補となりうるかどうかがチェックされます。書き込み可能な場合には、書き込み操作が続行されます。書き込めない場合には、Backup は書き込み可能なボリュームが挿入されるのを待ってから、バックアップ処理を続行します。

  4. ボリュームが再利用可能で、必要なプールのメンバーである場合、次に書き込み可能なボリュームが必要になった時点で、そのボリュームが再利用されます。

  5. ボリュームにラベルが付いていない場合は、保存のために次の書き込み可能なボリュームが必要となった時点で、そのボリュームにラベルが付けられます。

一般に、自動メディア管理機能が有効になっている場合に、スタンドアロンドライブからいっぱいになっていないボリュームがマウント解除されると、60 分経過後に、自動的にそのボリュームが再度ドライブにマウントされます。この 60 分という時間は、管理者またはオペレータが、ボリュームのマウント解除後にアンロード操作を行うために必要とみなされる時間です。

注意 - 注意 -

Backup では、自動メディア管理機能が有効になっている場合には、別のアプリケーションによってラベル付けされたボリュームはラベルの付け直しの対象と見なされます。ボリュームのラベルが変更されると、それまでに格納されていたデータは失われます。

ストレージボリュームの状態

さまざまなレポートとウィンドウに、Written、%Used、Location、および Mode などのパラメータを使って、ストレージボリュームの状態が報告されます。この節では、ボリュームに関するレポートに頻繁に使われる用語の定義を示します。

Backup 管理プログラムで表示されるボリューム名は、ボリュームラベルの名前と同じです。ボリューム名の末尾には、次の記号が表示されることがあります。

Written の値は、ボリュームに書き込まれた正確な値を示しています。

%Used の値は、ボリュームの総容量の推定値に基づいています。この推定値は、デバイスリソースの「Media Type」に指定されている値から得られます。Backup では、ボリュームへの書き込みを行うかどうかを決めるために %Used の値は使用しません。ボリュームが 100% 使用されているとマークされていても (%Used の値が 100% であるということは、Written の値がボリュームの推定値以上であることを示す)、ボリュームが「full」とマークされるまで、ボリュームへの書き込みが続行されます。メディアの終わりに達するか、書き込みエラーが検出された時点で、ボリュームに「full」のマークが付きます。

ストレージボリュームの位置は、「Volumes」リソースに定義した文字フィールドを示し、使用している環境内での意味のある物理的位置を表しています (例 : 2nd shelf, Cabinet 2, Room 42)。

表 4-3 に、Backup で使用できるストレージボリュームモードとその定義を示します。

表 4-3 ストレージボリュームモード

モードの値 

意味 

説明 

appen

追加可能 

このボリュームには空き領域がある。このボリュームが属しているプールの受け入れ基準を満たすデータを追加できる 

man

手動再利用 

このボリュームは自動再利用の対象からは外されている。このモードは手動でのみ変更できる 

(R)

読み取り専用 

このボリューム上のセーブセットは読み取り専用である。このモードは手動でのみ変更できる 

recyc

再利用可能 

このボリュームは自動再利用の対象となる (ボリュームを上書きする前に、ラベルを付け直す必要がある) 

一般に、ストレージボリュームは、そのボリューム上にあるすべてのセーブセットが「再利用可能」の状態にならないと再利用できません。セーブセット状態の詳細は、「セーブセットの状態値」を参照してください。

セーブセットのステージング

セーブセットのステージングとは、データをあるストレージメディアから別のストレージメディアに移動し、データを元の位置から削除するプロセスのことです。データがファイルデバイスに格納されている場合は、その領域は解放され、その分のディスク領域は他の用途に使用できるようになります。セーブセットのステージングにより、バックアップ、アーカイブ、またはマイグレートによるセーブセットを移動できます。ファイルデバイスタイプにバックアップされたセーブセットで、光ディスクボリュームやテープボリュームなどのより保存期間の長いストレージにデータを移動する場合には、ステージングを行うことをお勧めします。

「Staging」リソースのポリシーを構成して、設定した条件が満たされた時点で Backup に自動ステージングを実行させることができます。また、nsrstage プログラムを使えば、ステージングを手動で実行できます。

nsrstage コマンドを発行すると、指定したメディアのクローンボリューム上に、指定したセーブセットのクローンが作成されます。セーブセットがファイルデバイスタイプ上に格納されている場合は、元の場所からセーブセットが削除され、そのセーブセットが占有していた領域が解放されます。セーブセットの位置はメディアデータベースの中で記録されています。データのステージングが行われても、セーブセットの保持ポリシーは変更されません。

コマンド行を使ってセーブセットのステージングを行うには、シェルプロンプトで nsrstage コマンドを入力します。たとえば、あるセーブセットに対してステージングを行うには、次のコマンドを入力します。


# nsrstage -s server -b pool -m -S save-set-ID

nsrstage プログラムの構文とオプションについては、nsrstage(1m) のマニュアルページを参照してください。

ステージングポリシーを設定または変更するには、nsradmin コマンドを使用するか、nwadmin プログラムの GUI で「Customize」リソースを使用します。「Stage」リソースの詳細は、オンラインヘルプを参照してください。

クローン作成

クローン作成とは、ストレージボリュームのセーブセットの完全な複製を、クローンボリューム上に作成するプロセスのことです。バックアップ、アーカイブ、またはマイグレートによるセーブセットデータのクローンを作成できます。セーブセットのクローン作成は (バックアップ、アーカイブ、またはマイグレート操作の一部として) 自動的に行うことも、別の時点で手動で行うこともできます。

クローン作成は、信頼性を高めたいときやデータに手軽にアクセスできるようにしたいときに行います。たとえば、クローンをオフサイトに保管する、データを別の場所に送る、バックアップしたデータを検証するといった目的に使用できます。

クローン作成は 2 つの手順で行います。Backup によってデータがソースボリュームから復旧されたあとに、このデータをクローンボリューム (タイプが「clone」のプールボリューム) に書き込みます。クローン作成には、ソースボリュームの読み込み用と新たに作成されたクローンデータの書き込み用に少なくとも 2 つのアクティブデバイスが必要です。クローン作成の際には、データがソースボリュームからクローンボリュームに複製されます。クライアントまたはサーバーに格納されているデータはいっさい関与しません。Backup では、1 ボリュームにつきセーブセットのクローンを 1 つしか格納できないので、セーブセットのクローンを 3 つ指定すると、各クローンは別々のボリュームに書き込まれます。

自動クローン作成 (スケジュールされたグループバックアップ操作に関連付けられたクローン作成) では、すべてのバックアップ操作が完了したあとに行われます。スケジュールされたバックアップのあとに発行されるセーブグループ完了レポートにも、各セーブセットのクローン作成操作の成否が報告されます。

クローンデータが書き込まれるデバイスの位置は、Backup サーバーの「Clients」リソースの「Storage Nodes」属性の内容によって決まります。ストレージノードと Backup サーバーの名前はいつでも追加または削除できますが、バックアップデータを受け取るストレージノードのリストとは別に、クローンデータを受け取るストレージノードのリストを指定することはできません。

グループのバックアップが終わったあとにクローンを作成する場合、クローン作成はボリュームごとに手動で行うか、あるいはスクリプトとバッチファイルを組み合わせてコマンド行から行います。クローン作成を手動で行うと、レポートは生成されません。

データのクローン作成の際には、ストレージメディアの容量に応じて、必要なクローンボリュームの数が増減することがあります。クローン作成操作によって、クライアントファイルインデックスとメディアデータベースの両方にエントリが残るので、これによって追跡が可能です。追跡できるかどうかによって、クローン作成によって生成されたものか、オペレーティングシステムまたはハードウェアデバイスによるコピー操作によって生成されたものかを区別できます。

スケジュールされたバックアップ操作が完了してからクローン作成を開始するには、「Group」構成のなかでクローン作成を有効にします。個々のセーブセットに対してクローンを作成する場合、または 1 つのストレージボリュームに対してクローンを作成する場合は、nwadmin の GUI の「Save Set Clone」ウィンドウか「Volume Clone」ウィンドウ、あるいはコマンド行で nsrclone プログラムを使用します。

特定のボリュームに対してクローン作成を指定すると、指定したボリューム上のセーブセットがソースデータとして使用されます。

特定のセーブセットのクローンを指定すると、そのセーブセットがすでにクローンを持っているかどうかが調べられます。セーブセットのクローンが複数存在する場合には、通常は、手動でマウントしなければならないボリュームではなく、すでにオートチェンジャの中に入っているボリューム上のセーブセットのクローンがソースデータとして選択されます。必要に応じて、コマンド行オプションを使って、ソースとして使用するセーブセットクローンを明確に指定できます。

クローン操作を手動で実行する場合は、完了レポートは生成されません。nsrclone プログラムが生成するメッセージは、管理プログラムの GUI のメッセージウィンドウに表示され、Backup メッセージファイルの /nsr/logs/messages にも記録されます。

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

ストレージノードのクライアントのリソースと、そのストレージノードクライアントからクローンセーブセットを受け取れるストレージノードのリストとの間の関係は、「クローンストレージノードのアフィニティ」と呼ばれます。データは、元のセーブセットが格納されているメディアから、指定されたクローンストレージノードにコピーされます。このクローンストレージノードのアフィニティは、ストレージノードの Client リソースにある「Clone Storage Nodes」属性で定義します。あるストレージノードクライアントの「Clients」リソースにある「Clone Storage Nodes」属性を変更すると、そのストレージノードクライアントに対して構成されているすべての「Clients」リソースで、この属性が変更されます。

「Clone Storage Nodes」属性を使って、ストレージノードのリモートデバイスに対して指定したネットワークインタフェースとは別のネットワークインタフェースを、そのストレージノードのクローンを作成するときに使用できます。

サーバーは、「Clone Storage Nodes」属性に指定されているホスト名をそのまま使用します。「Devices」リソースで構成されているリモートデバイス名の前にホスト名を付けて使用するわけではありません。

Backup サーバーは、ボリュームのクローンを作成する際に、そのストレージノードクライアントの「Clone Storage Nodes」属性の値を調べます。「Clone Storage Nodes」属性に「Null」が指定されている場合には、サーバーの「Clone Storage Nodes」属性に指定されている値を使用します。この属性にも「Null」が指定されている場合には、サーバーの「Storage Nodes」属性を使用します。

従来のクローン機能との互換性が保たれていて、サーバーの Storage Node 属性に従います。

各ストレージノードのクローンの受け取り先を個別に指定するには、ストレージノードに対して構成されている「Clients」リソースの「Clone Storage Nodes」属性に、クローンの受け取り先とするストレージノードのホスト名を追加します。この属性に列挙されているエントリのうち、正常に機能している有効なデバイスを持つ最初のエントリが、そのストレージノードからのクローンデータの受け取り先として選択されます。

すべてのストレージノードのクローンを同じ宛先に送るには、ストレージノードに対して構成する「Clients」リソースの「Clone Storage Nodes」属性には何も指定せずに、Backup サーバーの「Clone Storage Nodes」属性だけを構成します。この方法で、クローンの宛先を 1 か所で管理できます。

ストレージノード上のリモートデバイスにあるメディアを宛先にしてクローンが作成されるセーブセットのファイルインデックスとメディアデータベースのエントリは、Backup サーバー上にそのまま残ります。したがって、サーバーにローカルに接続されているデバイスのメディア上に存在するすべてのクローンセーブセットと同じブラウズポリシーと保持ポリシーが適用されます。

ボリュームのクローン作成と複製

ボリュームのクローンを作成する時には、そのボリュームは単に複製されるわけではありません。ボリューム上のすべてのセーブセットが完全に作成し直されるため、クローンボリューム上の占有領域はソースボリューム上の占有領域と正確に一致しない場合があります。

管理者によっては、障害復旧に備えるために、Backup ボリュームの完全コピー (複製) を作るべきであると考えることもあるでしょう。このようなやり方は、一般には推奨できませんが (UNIX では tcopy コマンドを使用)、特定の環境では効果があります。コピーコマンドを使用する場合は、まずコピー先のボリュームが、Backup のソースボリュームと同じバイト数を保持できることを確認しなければなりません。また、複製されたボリュームはサーバーのメディアデータベースに挿入されないため、Backup はそのボリュームについては何も認識できないことに注意してください。自動メディア管理機能が有効になっている場合に、Backup が管理しているオートチェンジャにそのボリュームを入れたままにしておくと、そのボリュームはラベルを付け直す対象としてみなされ、有効な Backup ラベルがないために、スケジュールされたバックアップ処理で使用される可能性があります。

同様に、アーカイブボリュームの完全コピーも作成できます。ただし、各アーカイブセットに関連付けられている注釈は、ボリュームそのものではなく、Backup サーバーのメディアデータベースに格納されている情報です。このため、アーカイブされたセーブセットの複製ボリュームには注釈は含まれていません。メディアデータベースから元のアーカイブセーブセットのエントリが削除されると、それを記述している注釈も失われます。

クローン作成とデータ追跡の情報

クローン作成操作によってクライアントファイルインデックスにエントリが挿入されるわけではありません。クローンセーブセットは、メディアデータベースを介してのみ追跡されます。クローン操作の際には、クローンセーブセットの位置が、メディアデータベースの中の既存のセーブセットのエントリに追加されます。つまり、各セーブセットクローンは、ソースのセーブセットと同じ ssid を共有します。ソースのセーブセットが持つすべての特性は、クローンセーブセットにも当てはまります。ソースのセーブセットがブラウズ可能であれば、クローンもブラウズ可能です。ソースのセーブセットがブラウズポリシーの期限を越えていれば、クローンは復旧可能な状態になっています。

クローンプールに属するボリュームも、メディアデータベースの中のボリュームエントリによって追跡されます。すべてのセーブセットがメディアデータベース内の同じセーブセットエントリを共有しているため、以下の処理は「ボリューム単位」ではなく「セーブセット単位」で実行されることになります。

注意 - 注意 -

特定のクローンボリュームを再利用する目的で、そのクローンボリュームのモードを手動で recyc に変更する場合には、ボリュームのモードが再利用可能になるのは、そのボリューム上のすべてのセーブセットが再利用可能になったときです。したがって、ボリュームのモードを recyc に変更すると、実際にはクローンボリューム上のすべてのセーブセットの状態が recyc に変更されます。セーブセットはメディアデータベース内の同じエントリを共有しているので、「オリジナル」のセーブセットと「クローン」のセーブセットの間には実質的な違いはありません。その結果、再利用可能になったボリュームだけでなく、それ以外のすべてのボリューム上にあるすべてのセーブセットが、ただちに再利用の対象となります。

特定のクローンボリュームを再利用したいが、データが誤って失われるのを防ぐために、他のボリューム上にあるセーブセットのインスタンスは残しておきたい場合には、まずデータ保護するボリュームのモードを man_recyc に変更します。これにより、Backup はそのボリュームを自動的に再利用できなくなります。これで、再使用したいボリュームを安全に recyc モードに変更できます。

同様に、クローンボリュームをパージすると、実際にはそのクローンボリューム上に (全体または一部が) あるすべてのセーブセットに関連付けられているすべてのファイルエントリが、クライアントファイルインデックスから削除されます。

クローンボリュームを削除すると、Backup インデックス管理プログラム nsrim によって、クローンボリューム上にある各セーブセットのエントリがメディアデータベースの中で検索されます。nsrim プログラムは、このエントリに対して、特定のセーブセットのクローンの位置に関する情報を削除の対象としてマークします。このアクションは個々のセーブセットのエントリに対して実行されます。さらに、nsrim はデータベースの中で、特定のクローンボリューム (そのボリューム ID 番号によって識別される) のエントリを削除の対象としてマークします。

クローン作成のパフォーマンス

一般に、バックアップ操作の一部として実行されるボリューム書き込みと、クローン作成操作の一部として実行されるボリューム書き込みは、同じ速度で実行されます。しかし、クローン作成操作がスケジュールされたバックアップの一部として自動的に要求される場合には、それ以降に行われる別のスケジュールされたバックアップ処理でのパフォーマンスが低下する可能性があります。Backup では一般に、1 つのグループのスケジュールされたバックアップ処理を完了させてから、別のグループに対するスケジュールされたバックアップ処理を開始します。ただし、Backup では自動クローン作成が完了した時点ではなく、バックアップ操作が完了した時点をもってグループバックアップ処理が終了したと見なしています。このため、前のグループのクローン操作の実行中に次のグループのバックアップ処理が開始されると、nsrmmd のリソースや特定のボリューム上で競合が生じる可能性があります。この問題を避けるためには、自動クローン作成は行わずに、バックアップが完了したあとのオフピークの時間帯に実行させるジョブの一部として、クローン操作をあとから単独で行います。この場合には、nsrclone に ssid のセットを渡します。

クローン作成と復旧

クローンボリュームが復旧操作に使用されるのは、Backup が特定のセーブセットの復旧を試みたときに、元のセーブセットのボリュームが削除されている場合か、元のセーブセットが「suspect」としてマークされている場合です。

クローンボリュームに対して scanner プログラムを実行すれば、クライアントファイルインデックス、メディアデータベース、またはこの両方のエントリをいつでも再構築できます。いったんエントリが再度作成されれば、通常の復旧操作を行うことができます。scanner プログラムを使ってデータを復旧する方法については、『Solstice Backup 5.1 障害復旧ガイド』を参照してください。