(57)【要約】      （修正有）【課題】ボリュームベースのＣＤＰ上のファイルを保護し、ファイルと、データベースアプリケーションによって管理されるデータベースとの間のデータ整合性を復元する。【解決手段】ホスト１０と、ストレージサブシステム３０とを含む。ストレージサブシステム３０は、データベーステーブルとデータファイルを別々に格納するための複数のボリュームを含むことが可能である。また、ストレージサブシステムは、ストレージボリュームの内容を保護するボリュームベースのＣＤＰも含む。ストレージサブシステムは、ファイルボリュームとデータベースボリュームの間のデータ整合性を管理する、本発明の整合性マネージャ２８をさらに含む。整合性マネージャ２８は、ストレージシステム管理者が、ボリュームセットを、特定の時点に存在していた所定の状態に復元するコマンドを発行した際に、動作する。【選択図】図２
2007334877.tif 000002
【特許請求の範囲】
【請求項１】
ａ．第１のジャーナルに関連付けられたファイルシステムボリュームと、第２のジャーナルに関連付けられたデータベースボリュームとの間のボリューム依存関係を作成すること、
ｂ．ファイルに関連するメタデータを、前記データベースボリュームに関連するデータベースに格納すること、
ｃ．前記ファイルシステムボリュームの中の前記ファイルに更新データを書き込むこと、
ｄ．前記ファイルシステムボリュームの中の前記ファイルを閉じること、
ｅ．前記ファイルを閉じるオペレーションを表す第１のマーカを前記第１のジャーナルに挿入すること、
ｆ．前記データベースボリュームに関連する前記データベースの中で整合状態オペレーションを実行すること、および
ｇ．前記整合状態オペレーションを表す第２のマーカを前記第２のジャーナルに挿入することを含むコンピュータ実施方法。
【請求項２】
前記作成されたデータ依存関係に関する情報をデータ依存関係テーブルの中に格納することをさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項３】
前記格納されるメタデータに関する情報を含むレコードを前記第２のジャーナルに挿入することをさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項４】
前記更新データに関する情報を含むレコードを前記第２のジャーナルに挿入することをさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項５】
前記メタデータは、前記ファイルの名前、パス、またはバージョンを含む、請求項１に記載のコンピュータ実施方法。
【請求項６】
前記整合状態オペレーションは、データベースコミットオペレーションである、請求項１に記載のコンピュータ実施方法。
【請求項７】
ｉ．ボリューム復元要求を受信すること
ｉｉ．前記第１のジャーナルの中で前記第１のマーカを探索し、前記第２のジャーナルの中で前記第２のマーカを探索すること、および
ｉｉｉ．前記探し出された前記第１のマーカおよび前記第２のマーカに基づき、前記ファイルシステムボリュームおよび前記データベースボリュームを復元することをさらに含む、請求項１に記載のコンピュータ実施方法。
【請求項８】
前記受信されるボリューム復元要求は、復元されるべきファイルの少なくとも１つの属性を含み、前記第１のマーカおよび前記第２のマーカは、復元されるべき前記ファイルの前記少なくとも１つの属性を含む、請求項７に記載のコンピュータ実施方法。
【請求項９】
前記ファイルシステムボリュームと前記データベースボリュームの間の前記依存関係の存在をチェックすることをさらに含む、請求項７に記載のコンピュータ実施方法。
【請求項１０】
前記依存関係の存在を前記チェックすることは、ボリューム依存関係テーブルを調べることを含む、請求項９に記載のコンピュータ実施方法。
【請求項１１】
前記ファイルシステムボリュームを復元することは、ファイルシステム復元イメージを作成して、前記作成されたファイルシステム復元イメージを仮想論理ユニットにマップすることを含む、請求項７に記載のコンピュータ実施方法。
【請求項１２】
前記データベースボリュームを復元することは、データベース復元イメージを作成して、前記作成されたデータベース復元イメージを仮想論理ユニットにマップすることを含む、請求項７に記載のコンピュータ実施方法。
【請求項１３】
発見要求を受信して、前記受信された発見要求に応答して、前記データベース復元イメージにマップされた前記仮想論理ユニットに関する情報を提供することをさらに含む、請求項１２に記載のコンピュータ実施方法。
【請求項１４】
前記データベースボリュームの或る時点のコピーを第１のベースボリュームの中に作成し、前記ファイルシステムボリュームの或る時点のコピーを第２のベースボリュームの中に作成することをさらに含み、
前記ファイルシステムボリュームを復元することは、前記第１のジャーナルの少なくとも一部分を前記第１のベースボリュームに適用し、前記第２のジャーナルの少なくとも一部分を前記第２のベースボリュームに適用することを含む、請求項７に記載のコンピュータ実施方法。
【請求項１５】
ボリューム依存関係を作成することは、前記ファイルシステムボリュームをマスタボリュームとして指定し、前記データベースボリュームをスレーブボリュームとして指定することを含む、請求項１に記載のコンピュータ実施方法。
【請求項１６】
前記第１のマーカおよび前記第２のマーカは、前記ファイルの少なくとも１つの属性を含む、請求項１に記載のコンピュータ実施方法。
【請求項１７】
ａ．第１のジャーナルに関連付けられたファイルシステムボリュームと、第２のジャーナルに関連付けられたデータベースボリュームとの間のボリューム依存関係を作成すること、
ｂ．ファイルに関連するメタデータを、前記データベースボリュームに関連するデータベースに格納すること、
ｃ．前記ファイルシステムボリュームの中の前記ファイルに更新データを書き込むこと、
ｄ．前記ファイルシステムボリュームの中の前記ファイルを閉じること、
ｅ．前記ファイルを閉じるオペレーションを表すマーカをジャーナルに挿入すること、
ｆ．前記ファイルを更新すること、および
ｇ．前記データベースボリュームに関連する前記データベースの中で整合状態オペレーションを実行することを含むコンピュータ実施方法。
【請求項１８】
ｉ．前記データベースにおけるトランザクションを表すトランザクション識別子を含むボリューム復元要求を受信すること、
ｉｉ．前記ファイルシステムボリュームと前記データベースボリュームの間の依存関係の存在を検証すること、
ｉｉｉ．前記受信されたデータベーストランザクション識別子を使用して、前記データベースの或る時点のバージョンを復元すること、
ｉｖ．前記データベースから、前記ファイルの最後のバージョンの少なくとも１つの属性を読み取ること、
ｖ．前記少なくとも１つの属性を含む前記第１のマーカを前記第１のジャーナルの中で探索すること、および
ｖｉ．前記探し出された前記第１のマーカに基づいて前記ファイルシステムボリュームを復元することをさらに含む、請求項１７に記載のコンピュータ実施方法。
【請求項１９】
前記ファイルシステムボリュームの或る時点のコピーをベースボリュームの中に作成することをさらに含み、
前記ファイルシステムボリュームを復元することは、前記ジャーナルの少なくとも一部分を前記ベースボリュームに適用することを含む、請求項１８に記載のコンピュータ実施方法。
【請求項２０】
ボリューム依存関係を作成することは、前記ファイルシステムボリュームをマスタボリュームとして指定し、前記データベースボリュームをスレーブボリュームとして指定することを含む、請求項１７に記載のコンピュータ実施方法。
【請求項２１】
前記ファイルシステムボリュームを復元することは、ファイルシステム復元イメージを作成して、前記作成されたファイルシステム復元イメージを仮想論理ユニットにマップすることを含む、請求項１７に記載のコンピュータ実施方法。
【請求項２２】
発見要求を受信し、前記受信された発見要求に応答して、前記ファイルシステム復元イメージにマップされた前記仮想論理ユニットに関する情報を提供することをさらに含む、請求項２１に記載のコンピュータ実施方法。
【請求項２３】
ａ．ｉ．ジャーナルマネージャと、
ｉｉ．ファイルシステムボリュームと、
ｉｉｉ．データベースボリュームと、
ｉｖ．前記ファイルシステムボリュームの或る時点のコピーを含む第１のベースボリュームと、
ｖ．前記データベースボリュームの或る時点のコピーを含む第２のベースボリュームと、
ｖｉ．第１のジャーナルと、
ｖｉｉ．第２のジャーナルとを含むストレージサブシステムと、
ｂ．ｉ．前記ファイルシステムボリュームの中にファイルを格納するように動作可能なファイルシステムと、
ｉｉ．前記データベースボリュームの中に、前記ファイルに関連するメタデータを格納するデータベースと、
ｉｉｉ．１．データベースの中に、ファイルに関連するメタデータを格納し、２．前記ファイルシステムの中の前記ファイルに更新データを書き込み、３．前記ファイルシステムボリュームの中の前記ファイルを閉じ、４．整合状態オペレーションを実行するように動作可能なアプリケーションと、
ｉｖ．１．前記ファイルシステムボリュームと前記データベースボリュームの間の依存関係を作成し、２．前記ファイルを閉じるオペレーションを表す第１のマーカを前記第１のジャーナルに挿入し、３．前記整合状態オペレーションを表す第２のマーカを前記第２のジャーナルに挿入するように動作可能なエージェントとを含むホストとを含むコンピュータ化されたストレージシステム。
【請求項２４】
前記ストレージサブシステムは、前記ファイルシステムボリュームおよび前記データベースボリュームを整合性のあるように回復するように動作可能な整合性マネージャをさらに含む、請求項２３に記載のコンピュータ化されたストレージシステム。
【請求項２５】
前記アプリケーションは、前記ファイルシステムボリュームおよび前記データベースボリュームを整合性のあるように回復するように動作可能な整合性マネージャをさらに含む、請求項２３に記載のコンピュータ化されたストレージシステム。
【請求項２６】
管理者から復元要求を受け取るように動作可能なコンソールをさらに含む、請求項２３に記載のコンピュータ化されたストレージシステム。
【請求項２７】
ａ．ファイルシステム復元イメージを含むファイルシステム復元ボリュームと、
ｂ．データベース復元イメージを含むデータベース復元ボリュームとをさらに含む請求項２３に記載のコンピュータ化されたストレージシステム。
【請求項２８】
前記ファイルシステム復元ボリュームは、第１の仮想論理ユニットにマップされ、前記データベース復元ボリュームは、第２の仮想論理ユニットにマップされる、請求項２３に記載のコンピュータ化されたストレージシステム。
【請求項２９】
ａ．ｉ．ジャーナルマネージャと、
ｉｉ．ファイルシステムボリュームと、
ｉｉｉ．データベーステーブルスペースを格納するデータベースボリュームと、
ｉｖ．前記ファイルシステムボリュームの或る時点のコピーを含むベースボリュームと、
ｖ．ジャーナルとを含むストレージサブシステムと、
ｂ．ｉ．前記ファイルシステムボリュームの中にファイルを格納するように動作可能なファイルシステムと、
ｉｉ．前記データベースボリュームの中に、前記ファイルに関連するメタデータを格納するデータベースと、
ｉｉｉ．１．ファイルに関連するメタデータをデータベースの中に格納し、２．前記ファイルシステムの中の前記ファイルに更新データを書き込み、３．前記ファイルシステムボリュームの中の前記ファイルを閉じ、４．整合状態オペレーションを実行するように動作可能な、整合性マネージャを含むアプリケーションと、
ｉｖ．１．前記ファイルシステムボリュームと前記データベースボリュームの間の依存関係を作成し、２．前記ファイルを閉じるオペレーションを表すマーカを前記ジャーナルに挿入するように動作可能なエージェントとを含むホストとを含むコンピュータ化されたストレージシステム。
【請求項３０】
管理者から復元要求を受け取るように動作可能なコンソールをさらに含む、請求項２９に記載のコンピュータ化されたストレージシステム。
【請求項３１】
前記アプリケーションは、データベーストランザクション識別子を含む復元要求を受信し、前記受信されたデータベーストランザクション識別子によって識別される状態に、前記ファイルシステムボリュームおよび前記データベースを整合性のあるように回復するように動作可能な整合性マネージャをさらに含む、請求項２９に記載のコンピュータ化されたストレージシステム。
【請求項３２】
ファイルシステム復元イメージを含むファイルシステム復元ボリュームをさらに含む、請求項２９に記載のコンピュータ化されたストレージシステム。
【請求項３３】
前記ファイルシステム復元ボリュームは、仮想論理ユニットにマップされる、請求項２９に記載のコンピュータ化されたストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータデータを保護することに関し、より詳細には、継続的データ保護のためのシステムおよび方法に関する。
【背景技術】
【０００２】
ボリュームベースのＣＤＰ（継続的データ保護）技術は、ユーザアプリケーションからのすべての書き込みＩＯ（入出力）オペレーションを特別なジャーナルの中に格納することによって、２４時間休みなしのユーザデータ保護を提供する。ＣＤＰジャーナルは、ユーザデータを格納するのに使用される１次ストレージとは独立のストレージシステム上に格納される。最新のＣＤＰシステムは、アプリケーションチェックポイントなどの、様々なアプリケーションイベントを記録することができる。当業者にはよく知られているとおり、アプリケーションチェックポイントにおいて、或る時点におけるアプリケーションの状態全体が、ストレージデバイス上に保存されており、したがってアプリケーションが、後に、保存された状態情報を使用して、同一の時点から再開されることが可能である。
【０００３】
例示的なストレージベースのＣＤＰシステムが、参照により全体が本明細書に組み込まれている、米国特許出願公開第２００４／０２６８０６７  Ａ１号で説明されている。そのシステムは、コピーオンライトジャーナリング能力を提供し、すべてのジャーナルレコードおよびスナップショットレコードに関して一意のシーケンス番号を保持する。
【０００４】
また、いくつかの市販の製品も存在する。最も普及した企業用ＣＤＰ製品の１つが、ＲＥＶＩＶＯ  ＣＰＳ  １２００ｉ（ｈｔｔｐ：／／ｗｗｗ．ｒｅｖｉｖｉｏ．ｃｏｍ／ｉｎｄｅｘ．ａｓｐ？ｐ＝ｐｒｏｄ＿ＣＰＳ＿１２００ｉ）である。この製品は、ホスト上のＩＯオペレーションをミラーリングして、そのＩＯ情報をＣＤＰ機器に転送する。すると、機器は、ミラーリングされたＩＯオペレーションに関する情報を受信し、それらのＩＯをジャーナルとして格納する。ジャーナルレコードには、後の復元を可能にする索引付け情報でマークが付けられる。
【０００５】
アプリケーション動作を検出することができる別の利用可能な市販のＣＤＰ製品が、ＸＯＳｏｆｔのＥｎｔｅｒｐｒｉｓｅ  Ｒｅｗｉｎｄｅｒ（ｈｔｔｐ：／／ｗｗｗ．ｘｏｓｏｆｔ．ｃｏｍ／ｄｏｃｕｍｅｎｔａｔｉｏｎ／ＥｎｔｅｒｐｒｉｓｅＲｅｗｉｎｄｅｒ＿Ｕｓｅｒ＿Ｇｕｉｄｅ．ｐｄｆ）である。この製品は、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ（登録商標）などの、様々なユーザアプリケーションに関連する様々なイベント（例えば、チェックポイント）を検出することができる。検出されたイベントは、前述の製品によってＣＤＰオペレーションを最適化するのに使用される。
【０００６】
当業者には理解されるとおり、ファイル管理機能を提供する多数のＤＢ（データベース）アプリケーションが、存在する。前述のボリュームベースのＣＤＰ技術は、各データベースの中に格納されたデータを保護するのに使用されることが可能である。しかし、データベースデータ保護の文脈におけるＣＤＰ技術の使用には、２つの大きな課題がある。第１に、既存のＣＤＰシステムは、ホスト上のソフトウェアエラーまたはハードウェアエラーなどの、ユーザエラーおよび／またはシステム障害からの、非常に限られたデータファイル保護しか提供しない。第２に、復元オペレーション中、データベースの状態とデータファイルの間における整合性を保つのが、しばしば困難である。というのは、ストレージシステムの中に格納されたデータベースアプリケーションファイルは、データベースの現在のオペレーション状態を必ずしも正確に反映しているとは限らない可能性があるからである。
【０００７】
したがって、既存のＣＤＰソリューションは、以上の制限の１つまたは複数に悩まされている。したがって、ＣＤＰのための新たな技術が、必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の方法は、継続的データ保護のための従来の技術に関連する、以上およびその他の問題の１つまたは複数を実質的に未然に防ぐ方法およびシステムを対象とする。
【課題を解決するための手段】
【０００９】
本発明の概念の一実施形態によれば、ファイルシステムボリュームとデータベースボリュームの間のボリューム依存関係を作成することを含むコンピュータ実施方法が、提供される。ファイルシステムボリュームは、第１のジャーナルに関連付けられ、データベースボリュームは、第２のジャーナルに関連付けられる。本発明の方法は、ファイルに関連するメタデータを、データベースボリュームに関連するデータベースに格納すること、ファイルシステムボリュームの中のファイルに更新データを書き込むこと、ファイルシステムボリュームの中のファイルを閉じることをさらに含む。方法は、ファイルを閉じるオペレーションを表す第１のマーカを第１のジャーナルに挿入すること、データベースボリュームに関連するデータベースの中で整合状態オペレーションを実行すること、および第２のマーカを第２のジャーナルに挿入することをさらに含む。挿入される第２のマーカは、整合状態オペレーションを表す。
【００１０】
本発明の概念の別の実施形態によれば、ファイルシステムボリュームとデータベースボリュームの間のボリューム依存関係を作成することを含む、コンピュータ実施方法が、提供される。前述のファイルシステムボリュームは、第１のジャーナルに関連付けられ、データベースボリュームは、第２のジャーナルに関連付けられる。本発明の方法は、ファイルに関連するメタデータを、データベースボリュームに関連するデータベースに格納すること、ファイルシステムボリュームの中のファイルに更新データを書き込むこと、ファイルシステムボリュームの中のファイルを閉じること、ファイルを閉じるオペレーションを表すマーカをジャーナルに挿入すること、ファイルを更新すること、およびデータベースボリュームに関連するデータベースの中で整合状態オペレーションを実行することをさらに含む。
【００１１】
本発明の概念のさらに別の実施形態によれば、コンピュータ化されたストレージシステムが、提供される。本発明のストレージシステムは、ストレージサブシステムと、ホストとを含む。ストレージサブシステムは、ジャーナルマネージャと、ファイルシステムボリュームと、データベースボリュームと、ファイルシステムボリュームの或る時点のコピーを格納する第１のベースボリュームと、データベースボリュームの或る時点のコピーを格納する第２のベースボリュームと、第１のジャーナルと、第２のジャーナルとを含む。ホストは、ファイルシステムと、データベースと、アプリケーションと、エージェントとを含む。ファイルシステムが、ファイルシステムボリュームの中にファイルを格納するのに対して、データベースは、そのファイルに関連するメタデータをデータベースボリュームの中に格納する。アプリケーションは、ファイルに関連するメタデータをデータベースの中に格納し、ファイルシステムの中のファイルに更新データを書き込み、ファイルシステムボリュームの中のファイルを閉じ、整合状態オペレーションを実行するように構成される。エージェントは、ファイルシステムボリュームとデータベースボリュームの間の依存関係を作成し、ファイルを閉じるオペレーションを表す第１のマーカを第１のジャーナルに挿入し、整合状態オペレーションを表す第２のマーカを第２のジャーナルに挿入する。
【００１２】
本発明の概念のさらに別の実施形態によれば、コンピュータ化されたストレージシステムが、提供される。本発明のストレージシステムは、ストレージサブシステムと、ホストとを含む。ストレージサブシステムは、ジャーナルマネージャと、ファイルシステムボリュームと、データベーステーブルスペースを格納するデータベースボリュームと、ファイルシステムボリュームの或る時点のコピーを格納するベースボリュームと、ジャーナルとを含む。ホストは、ファイルシステムボリュームの中にファイルを格納するファイルシステムと、そのファイルに関連するメタデータをデータベースボリュームの中に格納するデータベースと、整合性マネージャおよびエージェントを含むアプリケーションとを含む。アプリケーションは、ファイルに関連するメタデータをデータベースの中に格納し、ファイルシステムの中のファイルに更新データを書き込み、ファイルシステムボリュームの中のファイルを閉じ、整合状態オペレーションを実行する。エージェントは、ファイルシステムボリュームとデータベースボリュームの間の依存関係を作成し、マーカをジャーナルに挿入する。本発明の概念によれば、挿入されるマーカは、ファイルを閉じるオペレーションを表す。
【００１３】
本発明に関連するさらなる態様は、或る程度、以下の説明で示され、或る程度、その説明から明白となるか、または本発明の実施によって知ることができる。本発明の諸態様は、以下の詳細な説明、および添付の特許請求の範囲において特に指摘される諸要素、ならびに様々な要素および態様の組合せを使用して実現され、達せられることが可能である。
【００１４】
以上および以下の説明はともに、単に例示および説明を目的とし、特許請求の範囲に記載される発明またはその発明の応用を限定することは全く意図していないことを理解されたい。
【００１５】
本明細書に組み込まれ、本明細書の一部を成す添付の図面は、本発明の諸実施形態を例示し、説明とともに、本発明の技術の諸原理を説明し、例示する役割をする。
【発明を実施するための最良の形態】
【００１６】
以下の詳細な説明では、同一の機能的要素が同様の符号で示される、添付の図面を参照する。前述の添付の図面は、限定としてではなく例として、本発明の諸原理と合致する特定の諸実施形態および諸実装形態を示す。それらの実装形態は、当業者が、本発明を実施できるように十分に詳細に説明され、また、本発明の趣旨および範囲を逸脱することなく、他の実装形態が利用されてもよいこと、および様々な要素の構造上の変更および／または代用が行われてもよいことを理解されたい。したがって、以下の詳細な説明は、限定的な意味で解釈されるべきではない。さらに、説明される本発明の様々な実施形態は、汎用コンピュータ上で実行されるソフトウェアの形態で、専用ハードウェアの形態で、またはソフトウェアとハードウェアの組合せで実施されてもよい。
【００１７】
本発明の概念は、ボリュームベースのＣＤＰ上のファイルを保護するための、かつファイルと、データベースアプリケーションによって管理されるデータベースとの間のデータ整合性を復元するための方法およびシステムを含む。本発明の概念の実装形態の利点の１つは、管理者が、ファイルを閉じるオペレーションの後にジャーナルボリューム上に格納されるマーカを挿入することにより、特定のファイルを保護することができることである。ファイルとデータベースの間のデータ整合性は、復元ポイントが、ファイル属性を使用して指定された場合でさえ、達せられる。
【００１８】
本明細書で説明される本発明の３つの例示的な実施形態が、以上の目的とともに、その他の目的も達することができる。発明の概念が実施されることが可能な１つの例示的なシステム構成は、ホストと、ストレージサブシステムとを含む。ストレージサブシステムは、データベーステーブルとデータファイルを別々に格納するための複数のボリュームを含むことが可能である。また、ストレージサブシステムは、ストレージボリュームの内容を保護するボリュームベースのＣＤＰも含む。本発明の概念によれば、ストレージサブシステムは、ファイルボリュームとデータベースボリュームの間のデータ整合性を管理する、本発明の整合性マネージャも含む。整合性マネージャは、ストレージ管理者またはアプリケーション管理者などの管理者が、ボリュームセットを、過去の特定の時点に存在していた所定の状態に復元するコマンドを発行した際に、動作する。
【００１９】
最初に、以下の説明で使用されるいくつかの用語を定義する。具体的には、ＬＵ（論理ユニット）という用語は、ストレージサブシステム上で実行されるＳＣＳＩコマンドを使用して、ホストから格納されたデータにアクセスするのに使用されるユニットを指す。論理ユニットは、少なくとも１つの論理デバイスにマップされる。
【００２０】
ＬＵＮ（論理ユニット番号）は、各論理ユニットを識別する番号である。ＬＵＮは、ＳＣＳＩコマンドにおいてターゲット論理ユニットを指定するのに使用される。各ＬＵは、ポートを識別するＷＷＮ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ）と、ポートに接続されたストレージデバイスを識別するＬＵＮとのセットを使用してアドレス指定される。
【００２１】
ＬＤＥＶ（論理デバイス）またはボリュームは、ストレージサブシステムの中にデータを格納することができるストレージ領域である。ＬＤＥＶは、少なくとも１つの物理的ディスクから成る。
【００２２】
復元イメージは、データの復元バージョンを格納するＬＤＥＶである。復元イメージは、データの或る時点のコピーにジャーナルデータを適用することによって得られる。
【００２３】
仮想ＬＵは、論理ユニットに関連する論理デバイスが存在しているかどうかにかかわらず、ホストからアクセス可能な論理ユニットである。
【００２４】
マーカは、ホストのエージェントからストレージサブシステムに送信されるレコードである。
【００２５】
ヘッダ／フッタ情報は、ホストから受信されたデータおよびマーカ情報を含む、ジャーナルの中に格納されるメタデータレコードである。
【００２６】
第１の実施形態
本発明の概念の第１の実施形態は、データベースとファイルの間でデータ整合性を管理する、ストレージサブシステム上に展開された本発明のＣＤＰの能力を実施する。説明される実施形態の特徴の１つは、マーカを挿入することにより、ストレージシステム管理者が、ファイルを保護することができるようにする。挿入されるマーカは、対応するファイルを閉じるオペレーションが完了した後、ジャーナルボリュームに書き込まれる。格納されたマーカは、それらが、ファイルに関する属性によって指定される復元ポイントを指定する場合でさえ、アプリケーションの下で、ファイルと、関連するデータベースとの間のデータ整合性を確実にする。
【００２７】
（物理的構成）
図１は、本発明の概念の実施形態が実施されることが可能なシステム内のハードウェア構成要素、およびそれらの構成要素間の相互接続を例示する概略図を示す。図示されるシステム実施形態は、１つまたは複数のストレージサブシステムに結合された少なくとも１つのホスト１０を含む。ホスト１０は、標準のワークステーション、またはパーソナルコンピュータの形態で実施されることが可能なコンピュータハードウェア上で実行されるＯＳ（オペレーティングシステム）を含む。ホスト１０は、ＣＰＵ１１と、メモリ１２と、内部ディスク１３とを有する。また、ホストは、ＦＣ（ファイバチャネル）スイッチまたはイーサネット（登録商標）スイッチ５００に接続するように動作可能なＨＢＡ（ホストバスアダプタ）１４も含むことが可能である。
【００２８】
各ホストは、ストレージサブシステム３０によって提供される別個のＬＵ（論理ストレージユニット）上にアプリケーションデータを格納することができる。本発明の概念の一実施形態では、ストレージサブシステム３０は、以下の詳細に述べる諸能力を有する。具体的には、ストレージサブシステムは、ＳＣＳＩ−２コマンドセットまたはＳＣＳＩ−３コマンドセットを使用して、ストレージサブシステムのＬＵ内にデータを格納することができる。ストレージサブシステム３０は、１つまたは複数のＲＡＩＤ  ＣＴＬ（コントローラ）２０と、いくつかのストレージディスクドライブ（ディスク）３１を組み込むことが可能である。
【００２９】
各ＲＡＩＤコントローラ２０は、１つまたは複数のプロセッサとともに、メモリデバイスも含むことが可能である。さらに、ＲＡＩＤコントローラ２０は、ＲＡＩＤコントローラ２０をＳＡＮ（ストレージエリアネットワーク）および／またはストレージディスクドライブ３１に接続するのに使用されるイーサネット（登録商標）ポート２１およびＦＣポート２２などの、１つまたは複数のＮＩＣ（ネットワークインタフェース）を含むことが可能である。ＲＡＩＤコントローラ２０は、ホスト１０から受け取られたＳＣＳＩ  Ｉ／Ｏオペレーションを処理し、ストレージサブシステム３０内で提供されるいくつかのストレージディスクドライブ３１を利用して、様々なＲＡＩＤ構成をサポートすることができる。
【００３０】
コントローラ２０は、好ましくは、キャッシュ目的でデータを格納するのに利用されるＮＶＲＡＭ（不揮発性ランダムアクセスメモリ）を含む。ＮＶＲＡＭの中に格納されたデータは、例えば、停電に起因する損失から保護されることが可能である。本発明の一実施形態では、ＮＶＲＡＭは、バッテリを電源とするダイナミックＲＡＭ（ランダムアクセスメモリ）として実施される。
【００３１】
ＲＡＩＤコントローラ２０は、ストレージサブシステム３０が、ＷＷＮ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ）アドレス指定変換を使用してアドレス指定可能なＦＣポートを介してアクセス可能であるようにする。当業者には周知のとおり、ＷＷＮアドレスは、ＳＣＳＩ世界においてターゲットストレージデバイスのＩＤを指定し、ＦＣポート上のＬＵＮから成る。
【００３２】
ストレージサブシステム３０は、ストレージサブシステム３０に内部接続されることが可能な管理コンソール２３をさらに含む。管理コンソール２３は、ＷｅｂベースのＰＣまたはワークステーションなどの、汎用コンソールからアクセス可能であってもよく、ストレージサブシステムを管理するのに使用されることが可能である。内部コンソール２３は、ストレージサブシステム３０の維持管理者によって主に使用されることが可能である。コンソール４０２は、ストレージ管理者によって使用されることが可能であり、ストレージサブシステム３０から遠隔に配置されることが可能である。コンソール４０２は、ネットワークスイッチまたはネットワークハブ５０１からアクセス可能であってもよい。
【００３３】
論理構成
図２は、本発明のシステムの実施形態の様々なソフトウェア構成要素の例示的な論理構成、およびそれらのソフトウェア構成要素間の論理上の相互接続を例示する図を示す。
【００３４】
ホスト
ホスト１０は、ＯＳ（オペレーティングシステム）（図２に示されていない）の制御下で動作することができ、アプリケーション１６を実行することができる。さらに、ホスト１０は、ＤＢ（データベース）１７、ＦＳ（ファイルシステム）１８、およびエージェント１９を組み込むことができる。前述のＯＳは、ＵＮＩＸ（登録商標）、ＭＩＣＲＯＳＯＦＴ  ＷＩＮＤＯＷＳ（登録商標）、ＳＵＮ  ＳＯＬＡＲＩＳ、ＩＢＭのＺ／ＯＳまたはＡＩＸであることが可能である。当分野の技術者には理解されるとおり、ホスト１０上で実行されるＯＳの厳密な性質は、本発明の概念に不可欠ではない。アプリケーション１６は、ＳＡＰ、ＷＥＢＬＯＧＩＣ、ＰＥＯＰＬＥＳＯＦＴ、ＯＲＡＣＬＥ、ＣＲＭ（Ｃｕｓｔｏｍｅｒ  Ｒｅｌａｔｉｏｎａｌ  Ｍａｎａｇｅｍｅｎｔ、またはＰＡＣＳ（Ｐｉｃｔｕｒｅ  Ａｒｃｈｉｖｉｎｇ  ａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）などのデータベースベースのアプリケーションである。アプリケーション１６は、それ自体、ＤＢ１７の一部分であってもよい。その場合、アプリケーション１６は、ＤＢＭＳ（データベース管理システム）モジュールの１つまたは複数の内部に組み込まれることが可能である。
【００３５】
データベース１７は、ＯＲＡＣＬＥ、ＤＢ２、ＭＳ  ＳＱＬ、ＳＹＢＡＳＥ、ＩＮＦＯＲＭＩＸなどの汎用ＤＢＭＳであることが可能である。当分野の技術者には理解されるとおり、ＤＢＭＳシステム１７の詳細は、本発明の概念に不可欠ではない。
【００３６】
ファイルシステム１８は、ＵＦＳ（Ｕｎｉｘ（登録商標）  Ｆｉｌｅ  Ｓｙｓｔｅｍ）、ＮＴＦＳ、ｅｘｔ２／３などの汎用ファイルシステムであることが可能である。エージェント１９は、ストレージサブシステム３０と通信するように構成される。本発明の一実施形態では、エージェントとストレージサブシステムの間の通信は、エージェントが、ＳＣＳＩコマンドセットを使用して、ストレージサブシステム３０のストレージデバイス群を制御することができるようにする技術を使用して、実施されることが可能である。ＳＣＳＩコマンドを使用してストレージサブシステム３０を制御するための前述した技術は、参照により全体が本明細書に組み込まれている、欧州特許出願第１２４６０５０号で詳細に説明されている。図２に示される本発明のシステムの実施形態のエージェント１９（ＲＭ）は、欧州特許出願第１２４６０５０号に記載のＲＭＬＩＢと概ね均等であるのに対して、ＣＭＤ  ＤＥＶ（コマンドデバイス）２７は、欧州特許出願第１２４６０５０号に記載のＣＭと概ね均等であることに留意されたい。
【００３７】
エージェント１９は、ストレージサブシステム３０上に展開されたＣＤＰを制御する、いくつかのＡＰＩ（アプリケーションプログラミングインタフェース）を有する。図５は、エージェント１９のいくつかの例示的なＡＰＩのリストを示す。図示されるＡＰＩにおける各ファンクションコールは、特定のインスタンス番号を要求する。インスタンスは、エージェント１９とＣＭＤ  ＤＥＶ２７の間で通信パスが確立された後、作成される。各ファンクションコールは、ストレージサブシステム３０と通信するために、前述の、提供されたインスタンス番号を使用する。図５に示される特定のファンクションを、以下に詳細に説明する。
【００３８】
ＶｏｌｕｍｅｓＤｅｐｅｎｄｅｎｃｙファンクションは、ボリューム回復中にデータ整合性をもたらすために、第１のボリュームと第２のボリュームの間の、指定された属性に関する依存関係を作成する。このファンクションのオペレーションは、２つのボリュームを有するストレージサブシステムの文脈で、最もよく説明することができる。その２つのボリュームのいずれかが、ファイルシステムをホストする。他方のボリュームは、データベースをホストする。ファイルシステムをホストする第１のボリュームと、データベースをホストする第２のボリュームとの間の、ファイルのバージョンに関する依存関係が存在する。依存関係情報は、マーカ属性としてジャーナルに挿入されるだけでなく、コントローラ２０の内部メモリの中に格納もされる。前述のマーカ属性の詳細を、以下に詳細に説明する。ファイルシステムボリュームが、ファイルを格納し、ファイルは、何らかの時点で、「閉じる」システムコールによって閉じられる。閉じられたファイルは、バージョン４を有する。ファイルが閉じられたことは、ファイルシステムジャーナルの中で、ファイルを閉じるオペレーションに対応するマーカによって反映される。ファイルが、ファイルシステムによって閉じられた後、対応するデータベースジャーナルボリュームは、閉じられたファイルに対応するコミットマーカも格納する。その後、将来の或る時点で、管理者が、ボリュームセットを復元するよう、システムに指示する。本発明のシステムは、依存関係の存在を確認し、ジャーナルマーカを使用して、ファイルシステムとデータベースをともに、ファイルの同一のバージョン４に対応する整合性のある状態に回復する。
【００３９】
ＶｏｌｕｍｅｓＤｅｐｅｎｄｅｎｃｙファンクションコールは、依存関係を作成するよう、整合性マネージャに要求する。依存関係は、マスタボリュームおよびスレーブボリュームのＬＤＥＶ番号、ならびにデータ整合性を可能にする属性を鍵として指定することによって作成される。そのような属性の例には、限定としてではなく、ファイルのパス、ファイル名、およびバージョンが含まれる。ＶｏｌｕｍｅｓＤｅｐｅｎｄｅｎｃｙファンクションコールが、適切なパラメータで実行されると、整合性マネージャ２８は、図１２に示されるボリューム依存関係テーブル１７０に、適切なレコードを挿入する。テーブルは、依存関係名カラム１７１と、マスタＬＤＥＶ番号カラム１７２と、スレーブＬＤＥＶ番号カラム１７３と、属性カラム１７４ないし１７６を含み、以上のカラムは、整合性マネージャ２８が、マスタボリュームとスレーブボリュームの間でデータ整合性を保つ際に、データ整合性に関する鍵となる。マスタＬＤＥＶが、親ボリュームと呼ばれるのに対して、マスタＬＤＥＶからの依存関係を有するスレーブＬＤＥＶは、子ボリュームと呼ばれる。
【００４０】
ＩｎｓｅｒｔＭａｒｋｅｒファンクションは、特定のＬＵ（論理ユニット）に関連するユーザ固有のＬＤＥＶ（論理デバイス）を表すマーカを作成する。ＩｎｓｅｒｔＭａｒｋｅｒファンクションの入力パラメータには、フィールドおよび値が含まれる。この実施形態におけるフィールドパラメータの例には、アプリケーションによって実行されることが可能なアクション（コミット、または閉じること）、ならびにパス、ファイル名、またはファイルバージョンが含まれる。フィールドパラメータは、トランザクション識別子、ＭＤ−５やＳＨＡ−１などのハッシュ、またはアプリケーションの状態を表す他の種類の識別子を保持することが可能である。アクションフィールドに対応する値パラメータは、コミット、または閉じることであることが可能であり、パスフィールドに対応する値には、／ｕ０３／ｆｉｌｅｓなどのディレクトリパスが含まれることが可能である。前述のファンクションの値パラメータの他の例には、ファイル名、および１からカウントされるファイルバージョン番号が含まれる。
【００４１】
ＬｉｓｔＭａｒｋｅｒファンクションは、このファンクションのユーザ固有のパラメータと合致する、ジャーナルの中のすべてのマーカのリストを生成する。このファンクションが、ストレージサブシステム上で実行されると、後段で詳細に説明するジャーナルマネージャが、マーカをジャーナルから、それらのマーカの属性と一緒に読み取る。ジャーナルに対するパフォーマンス上の影響を最小限に抑えるため、マーカは、キャッシュメモリの中に格納されることが可能である。このファンクションによってもたらされる結果には、マークが付けられた時刻、およびマーカに関連する属性が含まれる。
【００４２】
ＳｅａｒｃｈＭａｒｋｅｒファンクションは、ユーザ固有の属性を使用して特定のマーカを探索するよう、ストレージサブシステムのジャーナルマネージャに指示する。探索される属性は、ジャーナルレコードのヘッダの中に位置する。ストレージサブシステムは、マーカが見つかったかどうかの指示を含め、探索の結果を戻し、マーカが見つかった場合、マーカのシーケンス番号とともに、フィールド、および関連する値を含む、探索された属性を戻す。
【００４３】
ＣｒｅａｔｅＶｉｒｔｕａｌＬＵファンクションは、ストレージサブシステム内で仮想ＬＵを作成するよう要求する。仮想ＬＵを、以下に詳細に説明する。
【００４４】
ＤｅｌｅｔｅＶｉｒｔｕａｌＬＵファンクションは、指定されたポートから既存の仮想ＬＵを削除するよう、ストレージサブシステムに要求する。仮想ＬＵの削除の後、ストレージサブシステムは、図４に示されるＬＵ／ＬＤＥＶマッピングテーブルのＤＥＶカラム５６から、その仮想ＬＵ、およびそのポートに対応するエントリを削除する。
【００４５】
ＭａｐＩｍａｇｅＴｏＶＬＵファンクションは、復元イメージを作成するよう、ストレージサブシステムに要求する。このコマンドを受け取ると、ジャーナルマネージャは、以下に詳細に説明する、属性によって指定される復元イメージを作成する。イメージは、ファイルを閉じる／ファイルコミットオペレーションに関連する属性によって指定されたジャーナルマーカまで、ベースボリュームにジャーナルエントリを適用することによって作成される。復元イメージが作成された後、ストレージサブシステムは、作成された復元イメージを仮想ＬＵの１つにマップする。復元イメージが作成された後、ジャーナルマネージャは、その復元イメージに対応するＬＤＥＶ番号を、図４に示されるマッピングテーブルの中の、適切なＬＵに関するＤＥＶカラム５４に挿入する。
【００４６】
ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓファンクションは、ボリューム依存関係によってリンクされる、マスタボリュームとスレーブボリュームに関する復元イメージセットの作成を要求する。このファンクションのオペレーションシーケンスを、図１４に関連して以下に詳細に説明する。ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓが、呼び出された後、整合性マネージャ２８は、マスタデータボリュームおよびスレーブデータボリュームに対応するジャーナルボリューム上の指定された属性のマーカの存在を確認する（図１４のステップ１４５および１４８）。マーカ属性は、ファイルのパス、ファイル名、およびバージョンを格納することができる。マーカの存在が確認された後、整合性マネージャ２８は、既存のマーカ属性を指定して、マスタボリュームおよびスレーブボリュームに関する復元イメージを作成するよう、ジャーナルマネージャに要求する。この作成要求は、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用する（図１４のステップ１４９および１５１）。したがって、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓファンクションの役割は、マスタジャーナルボリューム上、およびスレーブジャーナルボリューム上で属性を見出し、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションを使用して、見つかった属性によって指定されるマスタ復元イメージおよびスレーブ復元イメージを作成するよう、ＪＮＬマネージャに要求することである。
【００４７】
ＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵファンクションは、仮想ＬＵ（論理ユニット）から復元イメージをアンマップすることを要求する。ＪＮＬマネージャは、図４に示されるテーブルのＤＥＶカラム５４の中の、復元イメージに関するＬＤＥＶ番号を削除する。
【００４８】
ＵｎＭａｐＩｍａｇｅｓＦｒｏｍＶＬＵｓファンクションは、ＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵファンクションコールを使用して、作成された仮想ＬＵ（論理ユニット）グループから復元イメージをアンマップすることを要求する。
【００４９】
本発明の或る実施形態では、説明したファンクションのためにコマンドラインインタフェースが、提供される。そのようなコマンドラインファンクションコールのパラメータは、前述したパラメータと同一である。
【００５０】
ストレージサブシステム３０
本発明の一実施形態では、ストレージサブシステム３０の様々なモジュールは、ＣＴＬ（コントローラ）２０上で実行される、別々のマイクロコードモジュールとして実施される。前述のマイクロコードソフトウェアは、光メディア、フロッピー（登録商標）ディスク、およびその他の取り外し可能なストレージデバイスからインストールされることが可能である。マイクロコードは、パリティグループマネージャ、およびＬＤＥＶマネージャ（論理デバイスマネージャ）（図示せず）を含むことが可能である。論理デバイスマネージャは、１つまたは複数の物理ディスクドライブを含み、ポート２２を介してアプリケーションプログラムによってアクセス可能な論理ストレージユニットを提供するために、ＬＤＥＶ（論理デバイス）を作成するように構成される。最後に、マイクロコードは、以下に詳細に説明する、ＪＮＬ（ジャーナル）マネージャ２６を実施するのに使用されることが可能である。
【００５１】
パリティグループマネージャ（図示せず）
パリティグループマネージャは、マイクロコードで実施され、当業者には周知のＲＡＩＤ０／１／２／３／４／５／６技術を使用して、物理ディスクドライブからパリティグループを作成し、管理するように構成される。当技術分野で周知のとおり、ＲＡＩＤ６技術は、ＲＡＩＤ５技術に基づくが、デュアルパリティ保護を含む。
【００５２】
作成されたパリティグループが、図３に示されるＬＤＥＶ（論理デバイス）構成テーブル４０の中にリストアップされている。前述のテーブルは、ストレージサブシステム３０内の各パリティグループを識別するパリティグループ番号カラム４１と、使用可能容量サイズカラム４２と、ＲＡＩＤ構成カラム４３と、構成ディスクカラム４４とを含む。容量サイズカラム４２は、各ＲＡＩＤグループの総計の容量に関する情報を格納する。ＲＡＩＤ構成カラム４３は、対応するパリティグループを作成するのに使用されるＲＡＩＤ技術のタイプを格納するのに対して、構成ディスクカラム４４は、ＲＡＩＤグループを形成するすべての物理ディスクドライブを識別する。
【００５３】
論理デバイスマネージャ（図示せず）
コントローラ２０内に存在するＬＤＥＶマネージャは、論理デバイス構成の構造を管理する。ＬＤＥＶ（論理デバイス）は、ホストから受信されたデータを格納し、受信された入力／出力オペレーションに応答して、格納されたデータをホストに供給することができる、ＬＵ（論理ユニット）に関連する論理ストレージ領域を提供する。ＬＤＥＶは、ＲＡＩＤパリティグループの一部分を含む。ストレージシステム管理者は、ＬＤＥＶを定義し、対応するストレージメディアの初期フォーマットを実行する。さらに、管理者は、ＬＤＥＶにＬＤＥＶ番号を割り当てる。論理デバイスとパリティグループの間のマッピングは、図３に示されるＬＤＥＶ構成テーブル４０の中に格納される。このテーブルは、パリティグループ番号カラム４１と、論理デバイス番号カラム４５とを含む。ＬＤＥＶ番号カラム４５は、各パリティグループに関して、そのパリティグループの中に含まれるストレージサブシステムの論理デバイス群を識別する。それぞれのそのようなＬＤＥＶに関して、テーブルは、ＬＤＥＶの開始アドレスを表す開始ＬＢＡ（論理ブロックアドレス）カラム４６、およびＬＤＥＶの終了アドレスを表す終了ＬＢＡカラム４７を格納する。最後に、サイズカラム４８が、ＬＤＥＶのサイズを与える。パリティグループを含むストレージメディアの初期フォーマットは、ストレージシステム管理者によって要求される。フォーマットデータのデフォルトの値は、０である。フォーマットデータは、コンソール２３または４０２を介して、管理者によって、ＮＵＬＬ、または他の任意の文字に変更されることが可能である。
【００５４】
ポート２２
ポート２２は、図１に示されるコントローラ２０内に存在する。ポート２２は、ＬＵ（論理ユニット）を介してＬＤＥＶへのアクセスを可能にし、ＳＡＮ５００内の関連するＷＷＮへのアクセスを可能にする。図４は、ＬＵとＬＤＥＶの間の例示的なマッピングテーブルを示す。マッピングは、ＬＵＮ（論理ユニット番号）カラム５３およびＬＤＥＶカラム５４を使用して実行される。ハードウェアポートカラム５１の中の各レコードは、図１に示されるポート２２の１つに対応する。各ポート２２は、テーブルのカラム５２の中にリストアップされる一意のＷＷＮに関連する。ＷＷＮは、ホストによって、ポートに向けられた入力／出力要求の中に含められる。複数のＬＵが、各ポート２２に割り当てられることが可能である。各ＬＵは、カラム５２の中のＷＷＮと、カラム５３の中のＬＵＮとのペアによって識別される。ＦＣ−ＳＣＳＩプロトコル規格に基づき、ポートに関連付けられることが可能な論理ユニットの最大数は、２５６である。各ＬＵは、ホスト１０からのデータを格納するのに使用されるＬＤＥＶにマップされる。そのマッピング情報に基づき、コントローラ２０は、コントローラ２０のポート２２上でＳＣＳＩコマンドを受信し、カラム５２のＷＷＮと、カラム５３のＬＵＮとのセットを、カラム５４のＬＤＥＶ識別子に変換して、適切なＬＤＥＶにアクセスする。
【００５５】
いくつかの論理ユニットは、ＣＭＤデバイスとして構成されることが可能である。ＬＵが、コンソール２３または４０２を介して管理者によってＣＤＭデバイスとして定義されると、図４に示されるテーブルのＣＭＤ  ＤＥＶカラム５５の中のレコードが、チェックされる。ストレージ管理者は、ＬＵを作成し、コンソール２３または４０２を使用して、作成されたＬＵをＣＭＤ  ＤＥＶとして指定する。
【００５６】
ストレージ管理者は、各ＬＵを仮想ＬＵとして構成して、ＬＵが、関連するＬＤＥＶ、または関連する復元イメージを有さない場合でも、ホストが、ＬＵを利用できるようにすることができる。管理者が、ＬＵを仮想ＬＵとして設定すると、ストレージサブシステム３０は、テーブル５０のカラム５６の中のＶＬＵビットをオンにする。このモードでは、ストレージサブシステムは、ＬＵへのＬＤＥＶの割り当てにかかわらず、常に、ホストがＬＵを利用できるようにする。
【００５７】
仮想ＬＵ（図示せず）
最初、特定のポートに関連する仮想ＬＵは、いずれのＬＤＥＶにもマップされていない。しかし、仮想ＬＵは、関連する論理ユニット番号を有し、したがって、適切なポート番号、および仮想ＬＵの前述した論理ユニット番号を指定するファンクションコールを使用して、ホストによってアクセスされることが可能である。したがって、ホストは、従来のＳＣＳＩコマンドを使用して仮想ＬＵにアクセスすることができる。仮想ＬＵに向けられたＳＣＳＩ照会を受信した後、ストレージサブシステム３０のコントローラ２０は、対応するＬＤＥＶが、マップされていないものと考えて、通常の応答を発行する。例えば、仮想ＬＵにアドレス指定されたサイズ照会は、最大ストレージシステム定義サイズを戻す。他方、ＬＵが、全くＬＤＥＶを有さず、ＳＣＳＩ読み取り／書き込みオペレーションが、その仮想ＬＵに向けられた場合、コントローラ２０は、ＳＣＳＩ条件を使用してエラーメッセージで応答する。
【００５８】
ＣｒｅａｔｅＶＬＵファンクションが呼び出されると、ジャーナルマネージャは、図４に示されるマッピングテーブルのカラム５６に、ＶＬＵに対応するエントリを挿入する。このエントリは、適切なＬＵＮおよびポート番号に対応するテーブルロウに挿入される。ベースボリュームにジャーナルを適用することによって構築される復元イメージが、仮想ＬＵにマップされている場合、その仮想ＬＵに向けられたボリュームサイズ照会は、その仮想ＬＵにマップされたＬＤＥＶのサイズを戻す。ＳＣＳＩ読み取り／書き込みオペレーションが、その仮想ＬＵに向けられた場合、読み取りオペレーションは、そのボリュームに対して行われることが可能である。
【００５９】
さらに、仮想ＬＵ機能は、デバイス番号の順序を固定するのに役立つ。というのは、或るオペレーティングシステムは、新たなＬＵが接続されたデバイス名をシャッフルするからである。仮想ＬＵを使用して、正しい、または所望される順序が、復元されることが可能である。図４に示されるテーブルは、図２に示されるエージェント１９のアプリケーションプログラミングインタフェースによって、特に、前述したＭａｐＩｍａｇｅＴｏＶＬＵコールおよびＵｎＭａｐＩｍａｇｅＦｒｏｍＶＬＵコールによって管理される。ストレージシステム管理者は、コンソール２３または４０２を使用して、仮想ＬＵを設定または設定解除することができる。
【００６０】
ＭａｐＩｍａｇｅＴｏＶＬＵが、復元イメージを作成するように呼び出されると、復元イメージは、図４に示されるテーブルのＶＬＵカラム５６の中で定義される仮想ＬＵの１つにマップされ、ターゲットボリュームに接続された同一のポートに関連付けられる。マスタＬＤＥＶおよびスレーブＬＤＥＶを含むターゲットボリュームは、図１２に示される依存関係テーブル１７０の中に表されている。
【００６１】
ジャーナルマネージャ２６
ジャーナルマネージャは、ターゲットＬＤＥＶに関するＡｆｔｅｒ  ＪＮＬ（ジャーナル）を管理し、アプリケーションマーカオペレーションをサポートする。Ａｆｔｅｒ  ＪＮＬ機構の詳細な説明を、以下に提供する。しかし、その前に、ボリューム構成について説明する。
【００６２】
構成
ＬＤＥＶ上に存在し、データを格納するターゲットボリュームと、Ａｆｔｅｒ  ＪＮＬ機構に関連するボリューム群との間のマッピングが、図６に示されるＣＤＰ構成テーブル６０の中に含まれる。このテーブルは、ターゲットＬＤＥＶ番号カラム６１を含む。テーブル６０のカラム６２の中の値は、Ａｆｔｅｒ  ＪＮＬ  ＣＤＰモードが有効にされているかどうかを指定する。保護モードが、有効にされる場合、関連するＣＤＰボリューム情報６４も、テーブル６０の中に格納される。具体的には、カラム６５は、ベースＬＤＥＶに関する情報を格納し、カラム６６は、ＪＮＬ  ＬＤＥＶを識別する。Ａｆｔｅｒ  ＪＮＬ機構が、有効にされる場合、ベースＬＤＥＶカラム６５およびＪＮＬ  ＬＤＥＶカラム６６が、指定される。前述のカラムの中の情報は、コンソール２３または４０２を介してストレージシステム管理者によって提供される。
【００６３】
Ａｆｔｅｒ  ＪＮＬ機構
図７は、Ａｆｔｅｒ  ＪＮＬ機構の実施形態の例示的な図を示す。Ａｆｔｅｒ  ＪＮＬ機構は、ストレージサブシステム３０によって受信された、ホストからのすべての書き込みオペレーションの履歴を作成する。図７に示される構成は、ターゲット１次ＬＤＥＶ（１次ＶＯＬ）３２と、ベースＬＤＥＶ（ベースラインＶＯＬ）３４と、ＪＮＬ  ＬＤＥＶ（ＪＮＬボリューム）３３とを含む。１次ＬＤＥＶも、ＣＤＰのためのターゲットボリュームである。ベースボリューム３４は、ジャーナリングが、ジャーナルＬＤＥＶボリューム３３上で開始された時点でとられた、１次ボリュームの中のデータの時点コピーを有する。ベースボリュームの中のデータのその時点コピーは、各ジャーナルオペレーション後に増分され、時点コピーの作成後に凍結される、シーケンス番号によって特徴付けられる。ジャーナルボリュームは、ホストによって実行されるＩ／Ｏオペレーションに関する情報とともに、マーカや属性などの、その他の関連情報も含む。ＣＭＤデバイス（図示せず）は、当業者には周知のＳＣＳＩ帯域内通信プロトコルを使用して、ホスト１０とストレージサブシステム３０の間の通信を可能にする。ジャーナルマネージャ２６は、ジャーナルボリューム上の現在の書き込み位置を識別するジャーナルポインタ７１を有する。ジャーナルポインタの値は、０から始まり、現在の書き込み位置のＬＢＡ（論理ブロックアドレス）を表す。ＪＮＬボリュームが、ＶＴＯＣ（Ｖｏｌｕｍｅ  Ｔａｂｌｅ  ｏｆ  Ｃｏｎｔｅｎｔ）領域またはＭＢＲ（Ｍａｓｔｅｒ  Ｂｌｏｃｋ  Ｒｅｃｏｒｄ）領域などの管理領域を含む場合、論理ブロックアドレスの先頭は、それぞれの管理領域のサイズだけ移動される。
【００６４】
図８は、図７に示されるシステム内のターゲットＬＤＥＶにアドレス指定されたＳＣＳＩ書き込みコマンドを処理するための例示的な手続きを示す。前述の手続きのステップを、以下に詳細に説明する。
【００６５】
手続きは、ステップ９１で始まり、ジャーナルマネージャ２６が、ホスト１０によって送信されたＳＣＳＩコマンドを受信する。図７の手続き１参照。
【００６６】
ステップ９２で、ジャーナルマネージャ２６は、受信されたコマンドが、ＷＲＩＴＥ６、ＷＲＩＴＥ１０のような、ＳＣＳＩ  ＷＲＩＴＥコマンドであるかどうかを調べる。受信されたコマンドが、ＳＣＳＩ  ＷＲＩＴＥコマンドであると判定された場合、オペレーションは、ステップ９３に進む。ＷＲＩＴＥコマンドであると判定されなかった場合、手続きは、ステップ９７に進む。
【００６７】
ステップ９３で、ジャーナルマネージャは、受信されたＳＣＳＩに関連するデータを、ターゲット１次ボリュームに書き込む。図７の手続き２参照。
【００６８】
ステップ９４で、ジャーナルマネージャは、以下に詳細に説明するＨＤ（ヘッダ）情報、受信されたデータ、およびＦＴ（フッタ）情報を、ジャーナルボリューム３３に対するジャーナルポインタによって識別される論理ブロックアドレスから開始して、ジャーナルボリュームに書き込む。図７の手続き３参照。
【００６９】
ステップ９５で、ジャーナルマネージャは、書き込まれたヘッダ、データ、およびフッタの合計サイズだけ、ジャーナルポインタを増加させる。
【００７０】
ステップ９６で、ジャーナルマネージャは、その書き込みオペレーションの結果を、ＳＣＳＩ条件状態を使用して、発信元のホストに戻す。
【００７１】
ステップ９７で、ジャーナルマネージャは、１次ボリューム３２上のＲＥＡＤ６オペレーションなどの、他のＳＣＳＩコマンドを実行する。その後、手続きは、終了する。
【００７２】
ヘッダ／フッタ情報には、ヘッダ／フッタビット、ストレージサブシステム内のＩ／Ｏオペレーションを識別するシーケンス番号、ジャーナルデータ、マーカなどを含むことが可能なヘッダ／フッタのタイプを示すコマンドタイプ情報が含まれる。ヘッダは、ヘッダタイプが、ジャーナルデータまたはマーカである場合、さらなるコマンド情報を含むことが可能である。さらに、ヘッダは、コマンドタイプが、マーカである場合、マーカ属性を格納し、ジャーナルマネージャが、関連するＩ／Ｏ要求を受信した時刻、ホストから受信されたＳＣＳＩコマンドに関する情報、ならびにジャーナルデータの開始アドレスおよびサイズ情報を格納する。最後に、フッタは、関連するヘッダのシーケンス番号を有する。
【００７３】
現在のシーケンス番号は、ヘッダ／フッタ挿入ごとに増分される。シーケンス番号は、最大シーケンス番号に達した場合、０から再開することが可能である。本発明の一実施形態では、ヘッダ／フッタレコードのサイズは、４つの論理ブロックのサイズに相当する２ＫＢである。当分野の技術者には理解されるとおり、ヘッダ／フッタの厳密なサイズは、本発明の概念に不可欠ではなく、他のサイズが使用されてもよい。例えば、より大きいヘッダ／フッタサイズが使用されて、さらなるデータが、ヘッダ／フッタに書き込まれることを可能にしてもよい。
【００７４】
復元オペレーションは、復元イメージを作成するよう、ストレージサブシステムに要求する、ホストによって発行されるＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを呼び出すことによって開始されることが可能である。前述のファンクションコールに応答して、ジャーナルマネージャは、マーカ属性またはシーケンス番号によって指定された復元イメージを作成する。
【００７５】
ホスト１０から、またはコンソール２３または４０２を介してホスト１０から復元命令を受信すると、ストレージサブシステム３０は、シーケンス番号または時刻値によって指定された時点に対応する復元ボリューム３８〜３９を作成する。これは、ベースボリュームの中のデータに、ＪＮＬボリュームの中のレコードを適用することによって達せられる。復元ボリュームが作成されると、ＪＮＬマネージャ２４は、そのボリュームを仮想ＬＵにマップする。マッピングオペレーションより前に、ＪＮＬマネージャ２４は、仮想ＬＵが、別の復元ボリュームにマップされているかどうかをチェックする。別の復元ボリュームが、同一の仮想ＬＵにマップされており、その仮想ＬＵへの前回の読み取り／書き込みアクセスが、過去１分以内に行われている場合、古いマッピングは、保たれ、新たな仮想ＬＵが、最初の復元ボリュームにマップするために使用される。その仮想ＬＵが、マップされていない場合、または前回のアクセスが、古い場合、マップされた復元ボリュームは、アンマップされ、対応するＬＤＥＶが、空きＬＤＥＶプールに戻される。前述の復元手続きを、以下に詳細に説明する。
【００７６】
復元イメージを作成するための手続きは、図９に示されている。
【００７７】
この手続きは、ステップ１０１で始まり、ジャーナルマネージャが、復元命令の中で指定された属性またはシーケンス番号を含むジャーナルヘッダを探索する。そのようなヘッダが探し出された場合、プロセスは、ステップ１０２に進む。必要なヘッダを見つけることができない場合、プロセスは、終了し、エラーが、戻される。
【００７８】
ステップ１０２で、ジャーナルマネージャが、ＬＤＥＶプールからＬＤＥＶ（論理デバイス）を割り当てる。好ましくは、割り当てられるデバイスは、ベースボリュームのサイズと同一のサイズを有する。前述のＬＤＥＶプールは、ストレージサブシステム内のすべての論理デバイスのリストを管理し、使用される論理デバイスと、未使用の論理デバイスをともに適切に追跡する。正しいサイズの利用可能なボリュームを見つけるのに、ジャーナルマネージャは、ＬＤＥＶ管理テーブル４０のカラム４８の中の必要なサイズ情報を調べる。
【００７９】
ステップ１０３で、ジャーナルマネージャは、新たに割り当てられたボリュームに、ベースボリュームのコピーを作成する。前述したとおり、新たなボリュームは、ストレージサブシステム３０のボリュームプールの中の未使用のボリューム群から選択される。コピーオペレーション中、ジャーナルマネージャは、コピーオペレーションの終了まで、そのボリュームに関する書き込みオペレーションを一時停止する。
【００８０】
ステップ１０４で、ジャーナルマネージャは、探し出されたヘッダのポイントまでのジャーナルボリュームからのジャーナルレコードを、ベースボリュームの作成されたコピーに適用する。
【００８１】
最後に、ステップ１０５で、ジャーナルマネージャは、仮想ＬＵ機構を介して、結果のボリュームをエクスポートする。その後、手続きは、終了する。
【００８２】
マーカ
ホストから受信されたＳＣＳＩ  Ｉ／Ｏコマンドを、前述のＡｆｔｅｒ  ＪＮＬ機構に従って処理するより前に、ジャーナルマネージャ２４はまず、受信されたコマンドがＩｎｓｅｒｔＭａｒｋｅｒオペレーションであるかどうかを判定する。このファンクションを実行するための手続きが、図１０に示されている。
【００８３】
この手続きは、ステップ１６１で始まり、ジャーナルマネージャが、コントローラ２０のポート２２上でＳＣＳＩコマンドを受信する。
【００８４】
ステップ１６２で、ジャーナルマネージャは、受信されたＳＣＳＩコマンドが、ＣＭＤデバイスにアドレス指定されているかどうかをチェックする。このチェックは、ファイバチャネルフレームの中のＦＣＰ＿ＬＵＮレコード、見つかる、コマンドのターゲットＬＵＮに基づいて達せられる。ＬＵとＣＭＤデバイスの間の関係の定義は、テーブル５０の中のＣＭＤ  ＤＥＶカラム５５上にリストアップされる。受信されたＳＣＳＩコマンドのターゲットＬＵＮが、ＣＭＤデバイス向けである場合、手続きは、ステップ１６４に進む。受信されたＳＣＳＩコマンドに関連するターゲットＬＵＮが、ＣＭＤデバイスに対応しない場合、手続きは、ステップ１６３に進む。
【００８５】
ステップ１６３で、ジャーナルマネージャは、１次ＬＤＥＶに対するＳＣＳＩコマンドを処理する。ステップ１６３の完了の後、実行は、図８に示される手続きのステップ９０に進み、ステップ９０は、図６に示されるテーブル６０のカラム６２の中の各保護モードをチェックすることを含む。
【００８６】
ステップ１６４で、ジャーナルマネージャは、受信されたＳＣＳＩコマンドが、前述のＡＰＩファンクションに基づくＣＤＰオペレーションを含むかどうかをチェックする。受信されたコマンドが、ＣＤＰオペレーションを含む場合、手続きは、ステップ１６６に進む。コマンドが、ＣＤＰトランザクションを含まない場合、実行は、ステップ１６５に進む。
【００８７】
ステップ１６５で、ジャーナルマネージャは、ＣＭＤデバイスにアドレス指定された他のコマンドを処理する。それらのコマンドには、当業者にはそれぞれ周知である、ＳＨＡＤＯＷＩＭＡＧＥやＴＲＵＥＣＯＰＹのような、ローカルミラー関連、またはリモートミラー関連のオペレーションが含まれることが可能である。前述のＳＨＡＤＯＷＩＭＡＧＥオペレーションは、ローカルミラーオペレーションを管理するための、いくつかの関連する状態を有する。一般的なオペレーション状態には、１次ボリュームと２次ボリュームとから成るボリュームペアを作成すること、そのペアを分割すること、およびそのペアを再同期して、１次ボリュームと２次ボリュームの間で同期データ状態を生じさせることが含まれる。他のコマンドは、前述の状態を変更するように機能することが可能である。ＴＲＵＥＣＯＰＹオペレーションでは、状態およびコマンドは、ＳＨＡＤＯＷＩＭＡＧＥの対応する状態およびコマンドと同様である。しかし、ＴＲＵＥＣＯＰＹは、１次コントローラ上のバッファ、１次ストレージサブシステム上の１次ボリュームと、２次ストレージサブシステム上の１次ボリュームとの間のビットマップなどの、リモートミラー構成を管理するための様々なコマンドをさらに提供する。
【００８８】
ステップ１６６で、ジャーナルマネージャは、受信されたコマンドが、ホスト１０からのＩｎｓｅｒｔＭａｒｋｅｒオペレーションを含むかどうかをチェックする。このケースでは、手続きは、ステップ１６７に進む。オペレーションが、ＩｎｓｅｒｔＭａｒｋｅｒに関するものでない場合、実行は、ステップ１６８に進む。
【００８９】
ステップ１６７で、ジャーナルマネージャは、マーカを、関連する属性を含め、ジャーナルＬＤＥＶの中、またはコントローラ２０のメモリの中に格納する。１つの実装形態では、マーカは、ジャーナルＬＤＥＶの中と、メモリの中とに同時に格納されてもよい。
【００９０】
ステップ１６８で、ジャーナルマネージャは、ＣＤＰに向けられた他のオペレーションを選択し、選択されたオペレーションを実行する。その後、手続きは、終了する。
【００９１】
ステップ１６７で、ジャーナルマネージャは、マーカをジャーナルボリューム上に格納することに留意されたい。ジャーナルにデータを書き込むと、ジャーナルマネージャは、「マーカ」というＣＤＰタイプを示すヘッダおよびフッタ情報も、ジャーナルＬＤＥＶに書き込む。
【００９２】
コンソール（図２に示されていない）
コンソール４０２は、ストレージ管理者が、ＬＡＮ／ＷＡＮ５０１を介してストレージサブシステム３０を管理することを可能にする。コンソール４０２は、ＬＤＥＶを作成するのに役立つＧＵＩ（グラフィカルユーザインターフェース）とともに、ＬＵ（論理ユニット）にＬＤＥＶをマッピングするため、およびＬＤＥＶプールを作成するためのツール群も提供する。当分野の技術者には理解されるとおり、コンソール４０２は、説明した機能に限定されず、その他の管理機能を実行することもできる。
【００９３】
ＳＡＮ（ストレージエリアネットワーク）
ＳＡＮ５０３は、ホスト１０とストレージサブシステム３０の間の論理結合を提供する。ＳＡＮ５０３は、ＦＣアーキテクチャおよび／またはイーサネット（登録商標）アーキテクチャに準拠して動作するスイッチまたはハブに基づいて実施されることが可能である。本発明の一実施形態では、ＳＡＮは、ファイバチャネルスイッチまたはファイバチャネルハブに基づく。本発明の別の実施形態では、ＳＡＮは、イーサネット（登録商標）スイッチまたはイーサネット（登録商標）ハブに基づく。当分野の技術者には理解されるとおり、ＳＡＮ５０３の設計の詳細は、本発明の概念に不可欠ではなく、他の様々なＳＡＮアーキテクチャが、使用されることが可能である。
【００９４】
ローカルエリアネットワークおよびワイドエリアネットワーク
ＬＡＮ／ＷＡＮ（ローカルエリアネットワークおよびワイドエリアネットワーク）は、前述のコンソール４０２とストレージサブシステム３０の間の論理接続を提供する。ＬＡＮ／ＷＡＮは、イーサネット（登録商標）プロトコル、ＦＤＤＩプロトコル、トークンリングプロトコル、または他の同様のネットワーキングプロトコルに準拠して動作するネットワーキングスイッチを使用して、実施されることが可能である。ストレージサブシステム３０は、他のホストからのストレージサブシステム３０へのアクセスを可能にするために、ＬＡＮ／ＷＡＮに接続され、ホストは、管理、およびその他の目的でストレージサブシステム３０にアクセスすることが可能である。
【００９５】
システム構成
本発明のシステムは、まず構成されなければ、使用することができない。本明細書で説明する例示的なシステム構成では、Ａｆｔｅｒ  ジャーナルＣＤＰ機構が、１次ＬＤＥＶの保護のために利用されるものと想定される。当分野の技術者には理解されるとおり、本発明のシステムは、同様に、Ｂｅｆｏｒｅ  ＪＮＬ機構に従って動作してもよい。したがって、ＣＤＰジャーナリング技術の厳密な性質は、本発明の概念に不可欠ではない。
【００９６】
次に、本発明のＣＤＰシステムを構成するための手続きを説明する。本発明のＣＤＰシステムに関する構成手続きは、図２に関連して説明される。最初に、ストレージ管理者が、ターゲット１次ボリュームを、データベース３２に割り当て、さらにファイルシステム３５、ＣＤＭデバイス２７、ベースボリューム３３、３６、およびジャーナルボリューム３４、３７に割り当て、ターゲット１次ＬＤＥＶおよびＣＭＤデバイスをポート２２上の各論理ユニットにマップする。さらに、ストレージ管理者は、コンソール２３または４０２を介してアクセスされることが可能なＣＤＰ構成テーブル６０を使用して、ターゲット１次ボリューム、ベースボリューム、およびジャーナルボリュームの間の関係を作成する。
【００９７】
ストレージ管理者は、コンソール２３または４０２を介して、あるいはエージェント１９を使用することにより、復元イメージのための仮想ＬＵをさらに作成する。サーバ管理者は、その後、ホスト１０にＯＳ（オペレーティングシステム）をインストールし、ターゲットボリュームおよびＣＤＭデバイスを含む論理ユニットを識別する。ＤＢＡ（データベース管理者）またはサーバシステム管理者が、ホスト１０にエージェント１９をインストールし、ＣＭＤデバイスとの通信を確立する。
【００９８】
ＤＢＡまたはアプリケーション管理者が、データベースおよびアプリケーション１６をインストールし、アプリケーション１６は、アプリケーションのファイル格納イベントが生じると、エージェント１９のＡＰＩに対するコールを発行する。
【００９９】
例示的なオペレーション方法
ユーザアプリケーションが、ファイル管理情報を含むメタデータをデータベースの中に格納する。基本的に、アプリケーションは、ファイルに関する閉じるイベントおよびコミットイベントをジャーナルボリュームの中に、マーカに関連する属性として格納する。
【０１００】
データベースのテーブルスペースが、最初に作成される。データベースは、ファイルメタデータを、データベーステーブルの中に格納されるレコードの形態で格納し、管理する。ファイルメタデータには、ファイルシステム内のファイルパス、ならびにファイル名、作成時刻、変更時刻、およびバージョン番号が含まれることが可能である。また、アプリケーション管理者は、ＶｏｌｕｍｅＤｅｐｅｎｄｅｎｃｙファンクションコールを使用して、ファイルシステムボリュームに、マスタボリュームとしてマークを付け、データベースボリュームに、スレーブボリュームとしてマークを付けるボリューム依存関係を作成することもできる。図１１のステップ２３０参照。
【０１０１】
アプリケーションは、ファイルシステム内にファイルを格納する際、図１１に示される以下のステップを実行する。
【０１０２】
ステップ２３１で、アプリケーションは、ファイルに関する新たなメタデータを作成する。
【０１０３】
ステップ２３２で、データベースが、スレーブボリュームとして指定されたデータベースボリューム上の新たなメタデータに関して、テーブルスペースデータを更新する。ジャーナルマネージャは、その更新データをデータベースジャーナル内に格納する。
【０１０４】
ステップ２３３で、アプリケーションが、ファイルシステム内のファイルを開き、その開かれたファイルにファイルデータを書き込む。
【０１０５】
ステップ２３４で、ファイルシステムが、１次ボリュームとして指定された、ファイルシステムデータを格納するボリュームに、更新されたファイルデータを書き込む。同時に、ジャーナルマネージャが、その更新されたデータを、ファイルシステムボリュームに対応するジャーナルに格納する。
【０１０６】
ステップ２３５で、アプリケーション１６が、ファイルシステム１８上のファイルを閉じる。
【０１０７】
ステップ２３６で、ファイルシステムが、待ち状態のすべての書き込み入出力オペレーションをファイルシステムストレージボリュームにフラッシュする。このステップが完了すると、ファイルシステムストレージボリューム、実際に格納されたファイルデータは、ファイルシステム内のファイルの状態を正確に反映し、待ち状態のファイルに向けられた未終了の書き込みオペレーションは、存在しない。
【０１０８】
ステップ２３７で、ファイルシステムが、結果をアプリケーションに戻して、ファイルを閉じるオペレーションが正常に完了したことを確認する。このステップの完了の後、１つまたは複数の同期コマンドが、ファイルシステム上で実行されることが可能である。
【０１０９】
ステップ２３８で、アプリケーションが、属性を有するマーカをファイルシステムジャーナルに挿入する。挿入された属性は、例えば、マスタボリューム上のファイルのバージョンを示す。ファイルバージョンは、０から始まり、順に番号が付けられる。アプリケーションは、ファイルが、作成される、変更される、または削除されるたびに、ファイルのバージョン番号を増分する。
【０１１０】
ステップ２３９で、エージェントが、ＩｎｓｅｒｔＭａｒｋｅｒファンクションコールを使用して、マーカを挿入する。ジャーナルマネージャは、ファイルシステムジャーナル上にマーカを格納する。
【０１１１】
ステップ２４０で、ジャーナルマネージャが、マーカ挿入オペレーションの結果をエージェントに戻す。
【０１１２】
ステップ２４１で、エージェントが、マーカ挿入オペレーションの結果をアプリケーションに戻す。
【０１１３】
ステップ２４２で、アプリケーションが、データベースに、整合状態を求める要求を発行する。整合状態要求の例は、データベース管理システムにおけるコミットコマンドの実行である。
【０１１４】
ステップ２４３で、受信された整合状態要求に応答して、データベースは、待ち状態のすべての入出力書き込みオペレーションをデータベースストレージボリュームにフラッシュする。
【０１１５】
ステップ２４４で、データベースは、整合性のある状態を求める要求の実行の結果をアプリケーションに戻す。
【０１１６】
ステップ２４５で、アプリケーションが、ファイルメタデータと関係するコミットオペレーションに対応するマーカを、スレーブボリュームとして指定されたデータベースに関するマスタボリュームに挿入するよう、エージェントに要求を送信する。マーカに関連する属性は、パス情報、ファイル名、およびファイルのバージョンに関する情報を有する。
【０１１７】
ステップ２４６で、エージェントが、ＩｎｓｅｒｔＭａｒｋｅｒファンクションコールを使用して、マーカをマスタジャーナルに挿入する。
【０１１８】
ステップ２４７で、ジャーナルマネージャが、マーカ挿入の成功の確認をエージェントに戻す。
【０１１９】
ステップ２４８で、エージェントが、マーカ挿入要求の結果を要求側アプリケーションに戻し、その後、前述の手続きが、終了する。
【０１２０】
前述のステップ２３８および２４５の完了の後、データベースのジャーナルボリューム、およびアプリケーションのジャーナルボリュームは、適切なマーカを介して、ファイルを閉じるオペレーション、およびファイルコミットオペレーションを反映することに留意されたい。復元手続き中、ストレージサブシステムが、ジャーナルから読み取られたマーカの内容を使用して、ファイル名およびファイルバージョンによって指定された１次ボリュームの復元イメージセットを作成する。
【０１２１】
さらに、アプリケーションは、ファイルに影響を与えるトランザクションに関する情報を、ストレージサブシステム３０の中に、またはホスト１０に接続されたローカルディスク上に格納されたアプリケーションログの中に格納することができる。格納されたトランザクション情報は、アプリケーション管理者によって、特定の時点におけるアプリケーションの状態を復元するのに使用されることが可能である。それぞれのそのようなログエントリには、コミットの時刻、パス情報、ファイル名、ファイルバージョン、およびＯｒａｃｌｅデータベースの中のＳＣＮ（システム変更番号）のような、トランザクションＩＤが含まれることが可能である。
【０１２２】
復元オペレーション
復元オペレーション中、アプリケーション管理者は、２つの方法のいずれかを使用して、ファイルに関する復元ポイントを指定することができる。第１の方法は、通常のオペレーション中にとられるアプリケーションログに基づく。第２の方法は、エージェントのコマンドラインインタフェース、あるいはコンソール２３または４０２を介して、エージェントのファイル探索機能を使用して、ファイル名およびバージョンを探索することを含む。
【０１２３】
アプリケーション管理者は、ファイルパス、ファイル名、およびファイルバージョンを含め、ファイルに関する情報を所有している場合、コンソール２３または４０２から、エージェント１９を介して、以下の復元オペレーションを実行することができる。前述の復元手続きを、図１３に関連して以下に詳細に説明する。
【０１２４】
復元手続きは、ステップ１４０で始まり、管理者が、属性を指定することにより、作成されたボリューム依存関係に関する復元イメージを作成するよう、整合性マネージャ２８に要求する。指定される属性は、ファイルのパス、ファイル名、およびバージョンに関する情報を包含する。属性には、ファイルの状態を一意に識別するアプリケーショントランザクション識別子が含まれることが可能である。ファイルの指定された時点のバージョンに関して、管理者は、データベースの中に格納されたメタデータ、ファイルを閉じるオペレーション中にコミットが行われた変更などの、ファイルに関連するボリュームセットを復元したいと所望する可能性がある。
【０１２５】
ステップ１４１で、エージェントが、ストレージサブシステム３０のＣＭＤデバイスを介して、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓオペレーションを発行する。
【０１２６】
ステップ１４２で、整合性マネージャ２８が、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓオペレーションを実行する。ステップ１４２ないし１５２は、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓの実行を反映する。次に、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓプロセスのためのステップの時間調整されたシーケンスを詳細に説明する。最初に、ボリューム依存関係テーブル１７０が、指定されたボリュームに関連する依存関係が存在することを示す情報を含むかどうかを、整合性マネージャがチェックする。
【０１２７】
ステップ１４３で、整合性マネージャが、マスタジャーナルボリューム上のフッタレコードにおいて属性を探索するよう、ジャーナルマネージャに要求する。
【０１２８】
ステップ１４４で、ジャーナルマネージャが、結果を整合性マネージャに戻す。
【０１２９】
ステップ１４５で、整合性マネージャが、マスタジャーナル上に属性が存在するか、ジャーナルマネージャから受信された情報をチェックする。属性が存在する場合、プロセスは、ステップ１４６に進む。属性が存在しない場合、整合性マネージャは、エラーを戻す。
【０１３０】
ステップ１４６で、整合性マネージャが、スレーブジャーナルボリューム上に属性マーカが存在するかどうかを検証するために、スレーブジャーナルボリューム上のフッタレコードにおいて属性を探索するよう、ジャーナルマネージャに要求する。
【０１３１】
ステップ１４７で、ジャーナルマネージャは、探索結果を整合性マネージャに戻す。
【０１３２】
ステップ１４８で、整合性マネージャが、スレーブジャーナルボリューム上の属性が存在するか、ジャーナルマネージャから受信された情報をチェックする。属性が存在する場合、プロセスは、ステップ１４９に進む。属性が、存在しない場合、整合性マネージャは、エラーを戻す。
【０１３３】
ステップ１４９で、整合性マネージャが、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵ上にマップするよう、ＪＮＬマネージャに要求する。
【０１３４】
ステップ１５０で、ＪＮＬマネージャが、マスタボリュームがかかわるマッピングオペレーションの結果を整合性マネージャに戻す。
【０１３５】
ステップ１５１で、整合性マネージャが、スレーブボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵにマップするよう、ジャーナルマネージャに要求する。前述のステップ１５１は、図１４に示されるプロセスのステップ１３５と概ね同等であることに留意されたい。
【０１３６】
ステップ１５２で、ジャーナルマネージャが、スレーブボリュームがかかわるマッピングオペレーションの結果を整合性マネージャに戻す。
【０１３７】
ステップ１５３で、整合性マネージャが、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓ要求のステータスを示す結果をエージェントに戻す。
【０１３８】
ステップ１５４で、エージェントが、ボリューム復元要求の結果を、エージェントのアプリケーションプログラミングインタフェースを介して、管理者に戻す。
【０１３９】
ステップ１５５で、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓ要求が、正常に完了した場合、管理者は、発見コマンドを実行して、ストレージサブシステム内で、作成された回復ボリュームを発見する。
【０１４０】
ステップ１５６で、ホストが、ＳＣＳＩ照会コマンドを使用して、ストレージエリアネットワーク上で仮想ＬＵに関連付けられた新たなボリュームを発見する。
【０１４１】
ステップ１５７で、ストレージサブシステムが、発見されたボリューム、およびそれらのボリュームのステータスを管理者に提供する。その後、手続きは、終了する。
【０１４２】
ステップ１５７が、正常に完了した後、管理者は、ｆｓｃｋなどのファイルシステム回復コマンドの実行の後、回復ボリュームにファイルシステムをマウントし、データベースをマウントし（これには、データベース回復がかかわる可能性がある）、次に、アプリケーションを開始することができる。
【０１４３】
図１４は、図１３の時間系列から抽出された、整合性マネージャの詳細なオペレーション手続きを示す。
【０１４４】
この手続きは、ステップ１４１で始まり、整合性マネージャが、管理者によって供給された特定の属性に基づいて復元イメージを作成する要求を受信する。
【０１４５】
ステップ１４２で、整合性マネージャは、指定されたボリュームに影響を与える依存関係が存在するかどうか、ボリューム依存関係テーブル１７０をチェックする。依存関係が存在する場合、手続きは、ステップ１４３に進む。依存関係が、存在しない場合、オペレーションは、ステップ１５９に進む。
【０１４６】
ステップ１４３で、整合性マネージャは、マスタジャーナルボリュームの中のフッタレコードにおいて、管理者によって指定された属性を探索するよう、ジャーナルマネージャに要求する。
【０１４７】
ステップ１４５で、整合性マネージャは、マスタジャーナルボリューム上の指定された属性を含むマーカを探索する。例えば、属性には、パス情報、ファイル名情報、および／またはファイルバージョン情報が含まれることが可能である。具体的には、ジャーナルマネージャは、特定のバージョンのファイルに対する閉じるオペレーションの実行を示す、ジャーナルボリューム上のマーカを探す。必要なマーカが見つかった場合、手続きは、ステップ１４６に進む。マーカが、見つからなかった場合、オペレーションは、ステップ１５９に進む。
【０１４８】
ステップ１４６で、整合性マネージャが、スレーブジャーナルボリュームの中のすべてのフッタレコードにおいて、管理者によって指定された属性を探索するよう、ジャーナルマネージャに要求する。
【０１４９】
ステップ１４８で、整合性マネージャは、指定された属性に対応するマーカが、スレーブジャーナルボリューム上に存在するかどうかを判定する。例えば、属性には、ファイルのパス、ファイル名、および／またはバージョンが含まれることが可能である。マーカが見つかった場合、手続きは、ステップ１４９に進む。マーカが見つからなかった場合、手続きは、ステップ１５９に進む。
【０１５０】
ステップ１４９で、整合性マネージャは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵにマップするよう、ジャーナルマネージャに要求する。復元イメージは、ＬＵＮの小さい順に仮想ＬＵに割り当てられる。十分な数の仮想ＬＵが、利用できない場合、ジャーナルマネージャは、整合性マネージャにエラーを戻し、整合性マネージャも、エラーを戻す。
【０１５１】
ステップ１５１で、整合性マネージャは、スレーブボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その作成された復元イメージを、作成された仮想ＬＵ上にマップするよう、ジャーナルマネージャに要求する。復元イメージは、ＬＵＮの小さい順に仮想ＬＵに割り当てられる。十分な数の仮想ＬＵが、利用できない場合、ジャーナルマネージャは、整合性マネージャにエラーを戻し、整合性マネージャも、エラーを戻す。
【０１５２】
ステップ１５９で、整合性マネージャは、指定されたマーカを見つけることができたために、アプリケーションにエラーを戻す。その後、手続きは、終了する。
【０１５３】
第２の実施形態
本発明の概念の第２の実施形態、整合性マネージャ１１７は、第１の実施形態の場合のよう、ストレージサブシステム３０上ではなく、ホスト１０上に存在する。第１の実施形態の場合と同様に、整合性マネージャは、データベースとファイルの間におけるデータ整合性を管理する能力を提供する。具体的には、整合性マネージャは、管理者が、データベース、および指定された時点における指定されたバージョンを有するファイルを復元できることを確実にする。
【０１５４】
第２の実施形態の論理構成および復元オペレーションの違いを、適宜、第１の実施形態の対応する特徴と比較して、以下に詳細に説明する。
【０１５５】
論理構成
図１５は、本発明の概念の第２の実施形態の論理構成を示す。図１５から見て取ることができるとおり、整合性マネージャ１１７は、ストレージサブシステム３０の中ではなく、ホスト１０の中に存在する。整合性マネージャ１１７は、アプリケーションモジュールの一部として実施されても、アプリケーションの外部のモジュールの中に存在してもよい。さらに、第２の実施形態では、整合性マネージャ１１７は、第１の実施形態のように、ストレージサブシステムではなく、ボリューム依存関係テーブル１７０を保持する。
【０１５６】
前述したとおり、第１の実施形態では、整合性マネージャ１１７は、ＶｏｌｕｍｅＤｅｐｅｎｄｅｎｃｙファンクションを呼び出して、ストレージサブシステム上に格納されたボリューム依存関係テーブル１７０を管理する。第２の実施形態では、ホスト上に存在する整合性マネージャ１１７が、前述のテーブルを直接に管理する。
【０１５７】
オペレーション手続き−通常のオペレーション
最初、データベース管理者またはアプリケーション管理者が、ＶｏｌｕｍｅＤｅｐｅｎｄｅｎｃｙファンクションを使用して、ファイルシステムボリュームとデータベースボリュームの間の依存関係を作成する。この依存関係は、ホスト１０に存在する整合性マネージャ１１７を使用して作成される。当分野の技術者には理解されるとおり、このオペレーションは、図１１に示される手続きのステップ２３０に取って代わる。整合性マネージャは、作成された依存関係構成をボリューム依存関係テーブル１７０の中に保持する。図１５でアプリケーション１６によって実行されるファイルを格納するオペレーションは、図１１に示される手続きのステップ２３１ないし２４７で実行される、対応するオペレーションと同一である。
【０１５８】
オペレーション手続き−復元オペレーション
第２の実施形態では、整合性マネージャ１１７が、ホスト１０上に存在するという事実のため、図１３に示される第１の実施形態の復元オペレーションは、変更される。新たな復元手続きが、図１６に示されている。この手続きは、ステップ２０１で始まり、管理者が、適切な属性値を指定することにより、ボリューム依存関係に関する復元イメージを作成するよう、整合性マネージャに要求する。作成された復元イメージは、仮想ＬＵにリンクされることになる。指定される属性には、復元されるべきファイルのパス、ファイル名、およびバージョンに関する情報が含まれることが可能である。
【０１５９】
ステップ２０２で、整合性マネージャが、図１６に示される手続きのステップ２０２ないし２２０に関連して説明される、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓオペレーションを実行する。最初に、整合性マネージャが、ボリューム依存関係テーブル１７０の中に、指定されたボリュームに関する依存関係が存在するかどうかをチェックする。
【０１６０】
ステップ２０３で、整合性マネージャが、マスタジャーナルボリュームのフッタレコードにおいて、指定された属性を含むマーカを探索するよう、エージェントに要求する。探索は、ＳｅａｒｃｈＭａｒｋｅｒファンクションコールを使用して実行される。
【０１６１】
ステップ２０４で、整合性マネージャからの受信された探索要求に従って、エージェントが、ＳｅａｒｃｈＭａｒｋｅｒファンクションを使用して、マスタボリュームジャーナル上の属性を探索するよう、ジャーナルマネージャに要求する。
【０１６２】
ステップ２０５で、ジャーナルマネージャが、探索結果をエージェントに戻す。
【０１６３】
ステップ２０６で、エージェントが、探索要求の結果を整合性マネージャに戻す。
【０１６４】
ステップ２０７で、整合性マネージャは、受信された探索結果が、必要な属性の存在を示すかどうかをチェックする。属性が存在する場合、プロセスは、ステップ２０８に進む。属性が、存在しない場合、整合性マネージャは、エラーを戻す。
【０１６５】
ステップ２０８で、整合性マネージャは、スレーブジャーナルボリュームのフッタレコードにおいて、指定された属性を含むマーカを探索するよう、エージェントに要求する。探索は、ＳｅａｒｃｈＭａｒｋｅｒファンクションコールを使用して実行される。
【０１６６】
ステップ２０９で、整合性マネージャからの受信された探索要求に従って、エージェントは、ＳｅａｒｃｈＭａｒｋｅｒファンクションを使用して、スレーブボリュームジャーナル上の属性を探索するよう、ジャーナルマネージャに要求する。
【０１６７】
ステップ２１０で、ジャーナルマネージャは、探索結果をエージェントに戻す。
【０１６８】
ステップ２１１で、エージェントは、探索要求の結果を整合性マネージャに戻す。
【０１６９】
ステップ２１２で、整合性マネージャは、受信された探索結果が、必要な属性の存在を示すかどうかをチェックする。属性が存在する場合、プロセスは、ステップ２１３に進む。属性が、存在しない場合、整合性マネージャは、エラーを戻す。
【０１７０】
ステップ２１３で、整合性マネージャは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その作成された復元イメージを、作成された仮想ＬＵにマップするよう、エージェントに要求する。
【０１７１】
ステップ２１４で、整合性マネージャから受信された要求に従って、エージェントは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵにマップするよう、ジャーナルマネージャに要求する。
【０１７２】
ステップ２１５で、ジャーナルマネージャは、復元イメージ作成オペレーションおよびマッピングオペレーションの結果をエージェントに戻す。
【０１７３】
ステップ２１６で、エージェントは、その結果を整合性マネージャに戻す。
【０１７４】
ステップ２１７で、整合性マネージャは、スレーブボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵを使用して、その復元イメージを、作成されたＶＬＵにマップするよう、エージェントに要求する。
【０１７５】
ステップ２１８で、エージェントは、スレーブボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵにマップするよう、ジャーナルマネージャに要求する。
【０１７６】
ステップ２１９で、ジャーナルマネージャは、復元イメージ作成オペレーションおよびマッピングオペレーションの結果をエージェントに戻す。
【０１７７】
ステップ２２０で、エージェントは、その結果を整合性マネージャに戻す。
【０１７８】
[0200]  ステップ２２１で、整合性マネージャ１１７は、復元オペレーションの結果を、エージェントを介して管理者に戻す。
【０１７９】
ステップ２２２で、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓ要求が、正常に完了した場合、管理者は、発見コマンドを実行して、ストレージサブシステム内で、作成された回復ボリュームを発見する。
【０１８０】
ステップ２２３で、ホストは、ＳＣＳＩ照会コマンドを使用して、ストレージエリアネットワーク上で仮想ＬＵに関連付けられた新たなボリュームを発見する。
【０１８１】
ステップ２２４で、ホストは、発見されたボリューム、およびそれらのボリュームのステータスを管理者に提供する。その後、手続きは、終了する。
【０１８２】
ステップ２２４が、正常に完了した後、管理者は、ｆｓｃｋなどのファイルシステム回復コマンドの実行の後、回復ボリュームにファイルシステムをマウントし、データベースをマウントし（これには、データベース回復がかかわる可能性がある）、次に、アプリケーションを開始することができる。
【０１８３】
図１６に示される手続き、および関連するＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓファンクションコールを使用して、ホスト上に展開された、第２の実施形態の整合性マネージャ１１７は、ストレージサブシステム３０のＣＤＰを制御する。ステップ２０３および２０８で、整合性マネージャ１１７は、図１６に表されるとおり、各ボリュームに関するＳｅａｒｃｈＭａｒｋｅｒファンクションコールを使用して、マーカ情報を要求する。ステップ２１３および２１７で、整合性マネージャは、やはり、図１６に表されるとおり、ステップ２０３および２０８で見つかったマーカのシーケンス番号を指定することにより、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、復元イメージの作成を要求する。
【０１８４】
図１７は、図１６の時間系列から抽出された、整合性マネージャの詳細なオペレーション手続きを示す。
【０１８５】
この手続きは、ステップ２０１で始まり、整合性マネージャが、管理者によって提供された特定の属性に基づいて復元イメージを作成する要求を受信する。
【０１８６】
ステップ２０２で、整合性マネージャは、ボリューム依存関係テーブル１７０が、指定されたボリュームに関連する依存関係が存在することを示す情報を含むかどうかをチェックする。その依存関係が、検出された場合、オペレーション手続きは、ステップ２０３に進む。検出されなかった場合、手続きは、ステップ２２５に進む。
【０１８７】
ステップ２０３で、整合性マネージャは、マスタジャーナルボリューム上のフッタレコードにおいて属性を探索するよう、ジャーナルマネージャに要求する。
【０１８８】
ステップ２０７で、整合性マネージャは、マスタジャーナル上の属性が存在するかどうか、ジャーナルマネージャから受信された情報をチェックする。属性が存在する場合、プロセスは、ステップ２０８に進む。属性が存在しない場合、整合性マネージャは、ステップ２２５でエラーを戻す。
【０１８９】
ステップ２０８で、整合性マネージャは、スレーブジャーナルボリューム上に属性マーカが存在するかどうかを検証するために、スレーブジャーナルボリューム上のフッタレコードにおいて属性を探索するよう、ジャーナルマネージャに要求する。
【０１９０】
ステップ２１２で、整合性マネージャは、スレーブジャーナルボリューム上の属性が存在するか、ジャーナルマネージャから受信された情報をチェックする。ステップ２１３に進む。属性が存在しない場合、整合性マネージャは、ステップ２２５でエラーを戻す。
【０１９１】
ステップ２１３で、整合性マネージャは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵ上にマップするよう、ＪＮＬマネージャに要求する。復元イメージは、ＬＵＮの小さい順に仮想ＬＵに割り当てられる。十分な数の仮想ＬＵが、利用できない場合、ジャーナルマネージャは、エラーを戻し、整合性マネージャも、エラーを戻す。
【０１９２】
ステップ２１７で、整合性マネージャは、スレーブボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵ上にマップするよう、ジャーナルマネージャに要求する。復元イメージは、ＬＵＮの小さい順に仮想ＬＵに割り当てられる。十分な数の仮想ＬＵが、利用できない場合、ジャーナルマネージャは、エラーを戻し、整合性マネージャも、エラーを戻す。その後、手続きは、終了する。
【０１９３】
第３の実施形態
本発明の概念の第３の実施形態では、整合性マネージャ１１８は、ホスト１０上に存在し、ファイルシステムを、最初の２つの実施形態の場合のよう、ファイル属性に基づいてではなく、復元されるべきファイルのバージョンに関連するデータベーストランザクション識別子に基づいて復元する。
【０１９４】
データベースが、ロールバックオペレーションまたはロールフォワードオペレーションを実行して、特定の時点におけるデータベーステーブルを復元した場合、データベースによって管理されるファイルシステムも、同一の時点に復元される必要がある。第３の実施形態では、データベースは、最後に更新されたファイルバージョンの属性を、テーブルスペースの中にエントリとして格納する。ファイルが閉じられるといつでも、格納された属性エントリは、更新される。
【０１９５】
第３の実施形態を、第１の実施形態に照らして説明し、その２つの違いを詳細に説明する。最も重要な違いは、論理構成、通常のオペレーションシーケンス、および復元オペレーションシーケンスにある。
【０１９６】
論理構成
第３の実施形態によるシステムの例示的な論理構成が、図１８に示されている。第３の実施形態におけるホストシステム１０の構成は、第２の実施形態の場合と同一である。しかし、ストレージサブシステム３０の構成は、多少異なる。
【０１９７】
具体的には、ストレージサブシステム３０は、ボリュームベースのＣＤＰによって保護されていないデータベースボリューム３２を提供する。ボリューム３２上に存在するデータベーステーブルスペース１８１が、そのテーブルスペース１８１の中に格納された、最後に更新されたファイルバージョンの属性１８２を管理する。格納される属性には、復元されるべきファイルに関するパス、ファイル名、および／またはバージョンが含まれる。
【０１９８】
オペレーション手続き−通常のオペレーション
最初に、図１９のステップ３００で、アプリケーション管理者が、第２の実施形態の場合と同じように、データベースボリュームとファイルシステムボリュームの間の依存関係を作成する。しかし、第３の実施形態では、ＣＤＰは、データベースボリュームを保護しない。第３の実施形態は、データベースの内部テーブルスペース保護機構に依拠するため、ストレージサブシステム３０は、データベースに関する復元情報を保存する必要がない。したがって、エージェントを使用して、適切なマーカを、ＣＤＰのジャーナル、およびデータベースのオンラインジャーナルに挿入する代わりに、アプリケーションは、データベーステーブルの中のファイルメタデータを単に変更し、ＣＤＰのジャーナルではなく、データベースに依拠して、そのメタデータに関する復元能力をもたらすことができる。
【０１９９】
第３の実施形態のオペレーションシーケンスを図１９に示し、以下に詳細に説明する。
【０２００】
ステップ３０１で、アプリケーションが、ファイルに関する新たなメタデータを作成し、作成されたメタデータをデータベーステーブルに書き込む。
【０２０１】
ステップ３０２で、データベースが、管理者によってスレーブボリュームとして指定されるデータベースボリューム上で、その新たなメタデータに関するテーブルスペースデータを更新する。ジャーナルマネージャが、そのメタデータをデータベースジャーナル上に格納する。
【０２０２】
ステップ３０３で、アプリケーションが、ファイルポインタを開き、ファイルデータをファイルシステムに書き込む。
【０２０３】
ステップ３０４で、ファイルシステムが、マスタボリュームとして指定されたファイルシステムボリューム上で、ファイルデータを更新する。ジャーナルマネージャが、その更新されたデータをファイルシステムジャーナル上に格納する。
【０２０４】
ステップ３０５で、アプリケーションが、ファイルを閉じる。
【０２０５】
ステップ３０６で、ファイルシステムが、待ち状態のすべての書き込みオペレーションをファイルシステムボリュームにフラッシュする。
【０２０６】
ステップ３０７で、ファイルシステムが、ファイルを閉じる要求の結果をアプリケーションに戻す。
【０２０７】
ステップ３０８で、アプリケーションが、マーカをマスタジャーナルボリューム（ファイルシステムジャーナルボリューム）に挿入する。挿入されるマーカには、ファイルのバージョンが含まれる。バージョン番号は、０から始まり、順に増分される。アプリケーションは、ファイルの作成時、変更時、および削除時に、バージョン番号を増分する。
【０２０８】
ステップ３０９で、エージェントが、ＩｎｓｅｒｔＭａｒｋｅｒファンクションコールを使用して、対応するマーカをジャーナルに挿入する。ジャーナルマネージャが、その挿入されたマーカをファイルシステム（マスタ）ジャーナル上に格納する。
【０２０９】
ステップ３１０で、ジャーナルマネージャが、マーカ挿入オペレーションの結果をエージェントに戻す。
【０２１０】
ステップ３１１で、エージェントが、マーカ挿入オペレーションの結果をアプリケーションに戻す。
【０２１１】
ステップ３１２で、アプリケーションが、最後に更新されたファイルの属性を更新する。属性には、ステップ３０５で更新されたファイルに関するパス、ファイル名、および／またはバージョンが含まれることが可能である。属性には、関連するデータベーストランザクションを指定するトランザクション識別子が含まれることが可能である。
【０２１２】
ステップ３１３で、データベースが、データベースのテーブルスペース、およびデータベースのジャーナルを更新する。
【０２１３】
ステップ３１４で、アプリケーションが、整合性のある状態の生成を求める要求を行う。コミットオペレーションに先立って、データベースは、バックアップモードに入ることが可能である。整合性のある状態の要求の例には、コミットコマンドの実行が含まれる。
【０２１４】
ステップ３１５で、データベースが、テーブルスペースに影響を与える待ち状態のすべての書き込みオペレーションを、データベーステーブルを格納するストレージボリュームにフラッシュする。
【０２１５】
ステップ３１６で、データベースは、整合性のある状態を求める要求の結果を戻す。待ち状態のすべてのデータ書き込み要求をフラッシュするコミットオペレーションの後、データベースは、バックアップオペレーションモードを抜けることができる。
【０２１６】
復元時に、ストレージサブシステムは、最後に更新されたファイルに関連し、データベースの中に格納された属性、および挿入されたマーカを使用して、指定されたトランザクション識別子によって指定されるとおり、復元ボリューム上で復元イメージセットを作成する。
【０２１７】
オペレーション手続き−復元オペレーション
第３の実施形態のシステムにおける復元オペレーションは、第２の実施形態の対応するオペレーションに多少、似通っている。
【０２１８】
しかし、第２の実施形態に関連して図１３に示されるＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓシーケンスに、いくつかの違いが存在する。具体的には、属性を獲得することを含む、ステップ１４６ないし１４８で実行されるオペレーション、および第２の実施形態のオペレーションシーケンスのステップ１４９ないし１５０が、第３の実施形態において異なる。具体的には、第３の実施形態では、整合性マネージャは、適切なトランザクション識別子によって指定されたポイントにテーブルスペースを復元するロールフォワードオペレーションまたはロールバックオペレーションをデータベースが完了した後、データベースのテーブルスペースからファイル属性を獲得する。その属性情報を使用して、ファイルシステムに関する復元イメージが作成される。
【０２１９】
本発明の第３の実施形態に関する復元手続きのオペレーションシーケンスが、図２０に示されている。
【０２２０】
この復元手続きは、ステップ４０１で始まり、管理者が、トランザクション識別子を指定することにより、依存関係に影響されるボリュームに関する復元イメージを作成するよう、整合性マネージャに要求する。ファイル属性は、復元されるべきファイルのパス、ファイル名、およびバージョンから成る。
【０２２１】
ステップ４０２で、整合性マネージャが、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓオペレーションを実行する。ステップ４０２ないし４１６参照。次に、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓプロセスの時間系列を、図２０に関連して説明する。最初に、ステップ４０２で、整合性マネージャが、ボリューム依存関係テーブル１７０を使用して、指定されたボリュームに関する依存関係が存在するかどうかをチェックする。
【０２２２】
ステップ４０３で、整合性マネージャが、ロールフォワードオペレーションまたはロールバックオペレーション、および指定されたトランザクション識別子を使用して、或る時点のテーブルスペースを復元するよう、データベースに要求する。
【０２２３】
ステップ４０４で、データベースは、テーブルスペース復元オペレーションの結果を戻す。
【０２２４】
ステップ４０５で、整合性マネージャは、ファイルの最後のバージョンに関する属性を取得するよう、データベースに要求する。
【０２２５】
ステップ４０６で、データベースは、属性要求の結果を戻す。
【０２２６】
ステップ４０７で、整合性マネージャは、マスタジャーナルボリューム上のすべてのフッタレコードにおいて、データベースによって提供される必要な属性を含むマーカを探索するよう、エージェントに要求する。探索は、ＳｅａｒｃｈＭａｒｋｅｒファンクションコールを使用して実行される。
【０２２７】
ステップ４０８で、エージェントは、ＳｅａｒｃｈＭａｒｋｅｒファンクションコールを使用して、マスタボリュームのジャーナル上の属性を探索するよう、ジャーナルマネージャに要求する。
【０２２８】
ステップ４０９で、ジャーナルマネージャは、マーカ探索の結果を戻す。
【０２２９】
ステップ４１０で、エージェントは、マーカ探索の結果を整合性マネージャに戻す。
【０２３０】
ステップ４１１で、整合性マネージャは、戻された探索結果に基づき、属性の存在をチェックする。マーカが見つかった場合、プロセスは、ステップ４１２に進む。マーカが見つからなかった場合、整合性マネージャは、エラーを戻す。
【０２３１】
ステップ４１２で、整合性マネージャは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵにマップするよう、エージェントに要求する。
【０２３２】
ステップ４１３で、エージェントは、マスタボリュームに関する復元イメージを作成し、かつ、ＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成された仮想ＬＵ上にマップするよう、ジャーナルマネージャに要求する。
【０２３３】
ステップ４１４で、ジャーナルマネージャは、復元ボリューム作成オペレーションおよびマッピングオペレーションの結果をエージェントに戻す。
【０２３４】
ステップ４１５で、エージェントは、復元ボリューム作成オペレーションおよびマッピングオペレーションの結果を整合性マネージャに戻す。
【０２３５】
ステップ４１６で、整合性マネージャは、ボリューム復元要求の結果を、エージェントを介して管理者に戻す。
【０２３６】
ステップ４１７で、ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓ要求が、正常に完了した場合、管理者は、発見コマンドを実行して、ストレージサブシステム内で、作成された回復ボリュームを発見する。
【０２３７】
ステップ４１８で、ホストが、ＳＣＳＩ照会コマンドを使用して、ストレージエリアネットワーク上で仮想ＬＵに関連付けられた新たなボリュームを発見する。
【０２３８】
ステップ４１９で、ホストは、発見されたボリューム、およびそれらのボリュームのステータスを管理者に提供する。その後、手続きは、終了する。
【０２３９】
ステップ４１９が、正常に完了した後、管理者は、ｆｓｃｋなどのファイルシステム回復コマンドの実行の後、回復ボリュームにファイルシステムをマウントし、データベースをマウントし（これには、データベース回復がかかわる可能性がある）、次に、アプリケーションを開始することができる。
【０２４０】
ＤＭａｐＩｍａｇｅｓＴｏＶＬＵｓオペレーションを使用して、ホスト上に存在する整合性マネージャは、ストレージサブシステム上に展開されたＣＤＰを制御する。整合性マネージャは、指定されたトランザクション識別子に関する復元イメージの作成を管理する。復元イメージの作成のための手続きを図２１に示し、以下に詳細に説明する。
【０２４１】
この手続きは、ステップ４０１で始まり、整合性マネージャが、復元イメージを作成する要求を受信する。
【０２４２】
ステップ４０２で、整合性マネージャは、指定されたボリュームに影響を与える依存関係が存在するかどうかについて、ボリューム依存関係テーブル１７０をチェックする。依存関係が存在する場合、手続きは、ステップ４０３に進む。依存関係が存在しない場合、オペレーションシーケンスは、ステップ４２０に進む。
【０２４３】
ステップ４０３で、整合性マネージャは、ロールフォワードオペレーションまたはロールバックオペレーション、および指定されたトランザクション識別子を使用して、データベースの或る時点のテーブルスペースを回復する。
【０２４４】
ステップ４０５で、整合性マネージャは、ファイルの最後のバージョンに関連する属性をデータベースから取得する。
【０２４５】
ステップ４０７で、整合性マネージャは、マスタジャーナルボリュームのすべてのフッタレコードにおいて、取得された属性を探索するよう、ジャーナルマネージャに要求する。
【０２４６】
ステップ４１１で、整合性マネージャは、指定された属性に対応するマーカが、マスタジャーナルボリューム上に存在するかどうかを判定した。例えば、属性には、ファイルのパス、ファイル名、およびバージョンが含まれることが可能である。整合性マネージャは、マスタジャーナルボリュームにおいて、ファイルの指定されたバージョンに対応する、ファイルを閉じるコマンドのマーカを探索する。マーカが見つかった場合、手続きは、ステップ４１２に進む。マーカが見つからなかった場合、手続きは、ステップ４２０に進む。
【０２４７】
ステップ４１２で、整合性マネージャは、マスタボリュームの復元イメージを作成し、かつ、前述したＭａｐＩｍａｇｅＴｏＶＬＵファンクションコールを使用して、その復元イメージを、作成されたＶＬＵ上にマップするよう、ジャーナルマネージャに要求する。復元イメージが、仮想ＬＵに割り当てられる順序は、昇順である。十分な数の仮想ＬＵが、利用できない場合、ステップ４２０で、ジャーナルマネージャは、エラーを戻し、整合性マネージャも、エラーを戻す。その後、手続きは、終了する。
【０２４８】
例示的なハードウェアプラットフォーム
図２２は、本発明の方法が、実施されることが可能なコンピュータ／サーバシステム２２００の実施形態を示すブロック図である。システム２２００は、コンピュータ／サーバプラットフォーム２２０１と、周辺デバイス２２０２と、ネットワークリソース２２０３とを含む。
【０２４９】
コンピュータプラットフォーム２２０１は、コンピュータプラットフォーム２２０１の全体にわたる様々な部分の間で情報を通信するためのデータバス２２０４または他の通信機構と、情報を処理し、他の計算タスクおよび制御タスクを実行するためにバス２２０１に結合されたプロセッサ２２０５とを含むことが可能である。また、コンピュータプラットフォーム２２０１は、様々な情報、およびプロセッサ２２０５によって実行されるべき命令を格納するためにバス２２０４に結合された、ＲＡＭ（ランダムアクセスメモリ）などの揮発性ストレージ２２０６、または他のダイナミックストレージデバイスも含む。また、揮発性ストレージ２２０６は、プロセッサ２２０５による命令の実行中に一時変数、またはその他の中間情報を格納するために使用されることも可能である。コンピュータプラットフォーム２２０１は、ＢＩＯＳ（基本入出力システム）、および様々なシステム構成パラメータなどの、プロセッサ２２０５のための静的情報および命令を格納するためにバス２２０４に結合された読取り専用メモリ（ＲＯＭまたはＥＰＲＯＭ）２２０７、またはその他のスタティックストレージデバイスをさらに含むことが可能である。磁気ディスク、光ディスク、またはソリッドステートフラッシュメモリデバイスなどの永続ストレージデバイス２２０８が、情報および命令を格納するために提供され、バス２２０１に結合される。
【０２５０】
コンピュータプラットフォーム２２０１は、コンピュータプラットフォーム２２０１のシステム管理者またはユーザに情報を表示するために、バス２２０４を介して、ＣＲＴ（陰極線管）、プラズマディスプレイ、またはＬＣＤ（液晶ディスプレイ）などのディスプレイ２２０９に結合されることが可能である。英数字キー、およびその他のキーを含む入力デバイス２２１０が、情報およびコマンド選択をプロセッサ２２０５に通信するためにバス２２０１に結合される。別のタイプのユーザ入力デバイスが、方向情報およびコマンド選択をプロセッサ２２０４に通信するため、およびディスプレイ２２０９上でカーソルの動きを制御するための、マウス、トラックボール、またはカーソル方向キーなどの、カーソル制御デバイス２２１１である。通常、この入力デバイスは、デバイスが、平面において位置を指定することを可能にする、２つの軸、第１の軸（例えば、ｘ）と第２の軸（例えば、ｙ）における２つの自由度を有する。
【０２５１】
外部ストレージデバイス２２１２が、バス２２０４を介してコンピュータプラットフォーム２２０１に接続されて、コンピュータプラットフォーム２２０１に追加の、または取り外し可能なストレージ容量をもたらすことが可能である。コンピュータシステム２２００の或る実施形態では、外部の取り外し可能なストレージデバイス２２１２は、他のコンピュータシステムとのデータの交換を円滑にするのに使用されることが可能である。
【０２５２】
本発明は、本明細書で説明される諸技術を実施するためのコンピュータシステム２２００の使用に関する。或る実施形態では、本発明のシステムは、コンピュータプラットフォーム２２０１のようなマシン上に存在することが可能である。本発明の一実施形態によれば、本明細書で説明される諸技術は、プロセッサ２２０５が、揮発性メモリ２２０６の中に含まれる１つまたは複数の命令の１つまたは複数のシーケンスを実行することに応答して、コンピュータシステム２２００によって実行される。そのような命令は、永続ストレージデバイス２２０８のような別のコンピュータ可読媒体から、揮発性メモリ２２０６に読み込まれることが可能である。揮発性メモリ２２０６の中に含まれる命令のシーケンスの実行は、本明細書で説明されるプロセスステップをプロセッサ２２０５に実行させる。代替の諸実施形態では、配線によって組まれている回路が、ソフトウェア命令の代わりに、またはソフトウェア命令との組合せで使用されて、本発明を実施することが可能である。このため、本発明の諸実施形態は、ハードウェア回路とソフトウェアのいずれの特定の組合せにも限定されない。
【０２５３】
本明細書で使用される「コンピュータ可読媒体」という用語は、実行のためにプロセッサ２２０５に命令を提供することに関与する任意の媒体を指す。コンピュータ可読媒体は、本明細書で説明される諸方法および／または諸技術のいずれを実施するための命令も有することが可能なマシン可読媒体の一例に過ぎない。そのような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むが、以上には限定されない、多くの形態をとることができる。不揮発性媒体には、例えば、ストレージデバイス２２０８のような、光ディスクまたは磁気ディスクが含まれる。揮発性媒体には、揮発性ストレージ２２０６のような、ダイナミックメモリが含まれる。伝送媒体には、データバス２２０４を含む配線を含め、同軸ケーブル、銅線、および光ファイバが含まれる。また、伝送媒体は、無線データ通信中、および赤外線データ通信中に生成されるような、音波または光波の形態をとることもできる。
【０２５４】
一般的な形態のコンピュータ可読媒体には、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、または他の任意の磁気媒体、ＣＤ−ＲＯＭ、他の任意の光メディア、パンチカード、紙テープ、孔のパターンを有する他の任意の物理的媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、フラッシュドライブ、メモリカード、他の任意のメモリチップまたはメモリカートリッジ、後段で説明する搬送波、またはコンピュータが読み取ることができる他の任意の媒体が含まれる。
【０２５５】
様々な形態のコンピュータ可読媒体が、１つまたは複数の命令の１つまたは複数のシーケンスを、実行のためにプロセッサ２２０５に運ぶことに関与することが可能である。例えば、命令は、最初、リモートコンピュータから磁気ディスク上で運ばれることが可能である。代替として、リモートコンピュータが、命令をリモートコンピュータのダイナミックメモリに読み込み、モデムを使用して電話線を介して、それらの命令を送信することもできる。コンピュータシステム２２００にローカルのモデムが、電話線上でデータを受信し、赤外線送信機を使用して、そのデータを赤外線信号に変換することができる。赤外線ディテクタが、赤外線信号の中で伝送されるデータを受信し、適切な回路が、そのデータをデータバス２２０４に乗せることができる。バス２２０４は、そのデータを揮発性ストレージ２２０６に伝送し、ストレージ２２０６から、プロセッサ２２０５が、命令を取り出して、実行する。揮発性メモリ２２０６によって受け取られる命令は、オプションとして、プロセッサ２２０５による実行前に、または実行後に、永続ストレージデバイス２２０８上に格納されてもよい。また、命令は、当技術分野で周知の様々なネットワークデータ通信プロトコルを使用して、インターネットを介してコンピュータプラットフォーム２２０１にダウンロードされることも可能である。
【０２５６】
また、コンピュータプラットフォーム２２０１は、データバス２２０４に結合されたネットワークインタフェースカード２２１３のような、通信インタフェースも含む。通信インタフェース２２１３は、ローカルネットワーク２２１５に接続されたネットワークリンク２２１４に結合する双方向のデータ通信を提供する。例えば、通信インタフェース２２１３は、対応するタイプの電話線へのデータ通信接続をもたらすＩＳＤＮ（デジタル総合サービス網）カードまたはモデムであることが可能である。別の例として、通信インタフェース２２１３は、適合するＬＡＮへのデータ通信接続をもたらすＬＡＮ  ＮＩＣ（ローカルエリアネットワークインタフェースカード）であることが可能である。また、周知の８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ、およびＢｌｕｅｔｏｏｔｈなどの無線リンクも、ネットワーク実装のために使用されることが可能である。そのようないずれの実装でも、通信インタフェース２２１３は、様々なタイプの情報を表すデジタルデータストリームを伝送する電気信号、電磁信号、または光信号を送受信する。
【０２５７】
ネットワークリンク２２１３は、通常、１つまたは複数のネットワークを介して、他のネットワークリソースに対するデータ通信をもたらす。例えば、ネットワークリンク２２１４は、ローカルネットワーク２２１５を介して、ホストコンピュータ２２１６またはネットワークストレージ／サーバ２２２２への接続をもたらすことができる。さらに、または代替として、ネットワークリンク２２１３は、ゲートウェイ／ファイアウォール２２１７を介して、インターネットなどのワイドエリアネットワークまたはグローバルネットワーク２２１８に接続することができる。このため、コンピュータプラットフォーム２２０１は、リモートネットワークストレージ／サーバ２２１９などの、インターネット２２１８上のいずれの場所に位置するネットワークリソースにもアクセスすることができる。他方、コンピュータプラットフォーム２２０１も、ローカルエリアネットワーク２２１５および／またはインターネット２２１８上のいずれの場所に位置するクライアントによってもアクセスされることが可能である。ネットワーククライアント２２２０および２２２１自体、プラットフォーム２２０１と同様のコンピュータプラットフォームに基づいて実施されることが可能である。
【０２５８】
ローカルネットワーク２２１５とインターネット２２１８はともに、デジタルデータストリームを伝送する電気信号、電磁信号、または光信号を使用する。コンピュータプラットフォーム２２０１に、またプラットフォーム２２０１からデジタルデータを伝送する、様々なネットワークを介する信号、ならびにネットワークリンク２２１４上の信号、および通信インタフェース２２１３を介する信号が、情報をトランスポートする搬送波の例示的な形態である。
【０２５９】
コンピュータプラットフォーム２２０１は、インターネット２２１８およびＬＡＮ２２１５、ネットワークリンク２２１４、および通信インタフェース２２１３を含む様々なネットワークを介して、メッセージを送信し、プログラムコードを含むデータを受信することができる。インターネットの例では、システム２２０１が、ネットワークサーバの役割をする場合、システム２２０１は、インターネット２２１８、ゲートウェイ／ファイアウォール２２１７、ローカルエリアネットワーク２２１５、および通信インタフェース２２１３を介して、クライアント２２２０および／またはクライアント２２２１上で実行されるアプリケーションプログラムのための要求されるコードまたはデータを送信することが可能である。同様に、システム２２０１は、他のネットワークリソースからコードを受信することもできる。
【０２６０】
受信されるコードは、コードが受信されるにつれ、プロセッサ２２０５によって実行され、かつ／または後の実行のために、永続ストレージデバイス２２０８または揮発性ストレージデバイス２２０６、あるいは他の不揮発性ストレージの中に格納されることが可能である。このようにして、コンピュータシステム２２０１は、搬送波の形態でアプリケーションコードを獲得することができる。
【０２６１】
最後に、本明細書で説明されるプロセスおよび技術は、いずれの特定の装置にも本来的に関連しておらず、構成要素の任意の適切な組合せによって実施されることが可能であることを理解されたい。さらに、様々なタイプの汎用デバイスが、本明細書で説明される教示に従って使用されることが可能である。また、本明細書で説明される方法ステップを実行する専用の装置を構築することが有利であると判明する可能性もある。本発明を、すべての点で、限定的ではなく、例示的であることが意図される特定の例に関連して説明してきた。ハードウェア、ソフトウェア、およびファームウェアの多くの異なる組合せが、本発明を実施するのに適していることが、当業者には理解されよう。例えば、説明されるソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａなどの、多種多様なプログラミング言語またはスクリプト言語で実施されることが可能である。
【０２６２】
さらに、本発明の他の実装形態が、本明細書で開示される本発明の明細および実施を考慮することで、当業者には明白となろう。説明される諸実施形態の様々な態様および／または構成要素は、データレプリケート機能を有するコンピュータ化されたストレージシステム内で、単独で使用されても、任意の組合せで使用されてもよい。それらの明細および例は、単に例示的であり、本発明の真の範囲および趣旨は、添付の特許請求の範囲によって示されるものとする。
【図面の簡単な説明】
【０２６３】
【図１】図１は本発明の概念の実施形態が実施されることが可能なシステム内のハードウェア構成要素、およびそれらの構成要素間の相互接続を示す概略図である。
【図２】図２は本発明のシステムの実施形態の様々なソフトウェア構成要素の例示的な論理構成、およびそれらのソフトウェア構成要素間の論理上の相互接続を示す図である。
【図３】図３は論理デバイス構成テーブルの例示的な実施形態を示す図である。
【図４】図４はＬＵとＬＤＥＶの間の例示的なマッピングテーブルである。
【図５】図５はエージェントのいくつかの例示的なアプリケーションプログラミングインタフェースのリストである。
【図６】図６ターゲットボリュームと、ＣＤＰのＡｆｔｅｒ  ＪＮＬ機構に関連するボリューム群の間の例示的なマッピングを示す図である。
【図７】図７はＡｆｔｅｒ  ＪＮＬ機構の実施形態を例示する図である。
【図８】図８は図７に示されたシステム内のターゲットＬＤＥＶにアドレス指定されたＳＣＳＩ書き込みコマンドを処理するための例示的な手続きを示す図である。
【図９】図９はＭａｐＩｍａｇｅｆｒｏｍＶＬＵファンクションを使用してイメージを作成し、マッピングするための例示的な手続きを示す図である。
【図１０】図１０は受け取られたコマンドがマーカ挿入オペレーションと関係しているかどうかを判定するための例示的な手続きを示す図である。
【図１１】図１１は本発明の概念の実施形態のオペレーションシーケンスを示す図である。
【図１２】図１２はボリューム依存関係テーブルの例示的な実施形態を示す図である。
【図１３】図１３は復元手続きのオペレーションシーケンスの例示的な実施形態を示す図である。
【図１４】図１４は復元イメージセットの作成のための手続きの例示的な実施形態を示す図である。
【図１５】図１５は発明のシステムの別の実施形態の様々なソフトウェア構成要素の例示的な論理構成、およびそれらのソフトウェア構成要素間の論理上の相互接続を示す図である。
【図１６】図１６は復元手続きのオペレーションシーケンスの例示的な実施形態を示す図である。
【図１７】図１７は復元イメージセットを作成するための手続きの例示的な実施形態を示す図である。
【図１８】図１８は本発明のシステムの別の実施形態の様々なソフトウェア構成要素の例示的な論理構成、およびそれらのソフトウェア構成要素間の論理上の相互接続を示す図である。
【図１９】図１９は本発明の概念の実施形態のオペレーションシーケンスを示す図である。
【図２０】図２０は復元手続きのオペレーションシーケンスの例示的な実施形態を示す図である。
【図２１】図２１は復元イメージの作成のための手続きの例示的な実施形態を示す図である。
【図２２】図２２は本発明のシステムが実施されることが可能なコンピュータプラットフォームの例示的な実施形態を示す図である。
【図１】
2007334877.tif 000003
【図２】
2007334877.tif 000004
【図３】
2007334877.tif 000005
【図４】
2007334877.tif 000006
【図５】
2007334877.tif 000007
【図６】
2007334877.tif 000008
【図７】
2007334877.tif 000009
【図８】
2007334877.tif 000010
【図９】
2007334877.tif 000011
【図１０】
2007334877.tif 000012
【図１１】
2007334877.tif 000013
【図１２】
2007334877.tif 000014
【図１３】
2007334877.tif 000015
【図１４】
2007334877.tif 000016
【図１５】
2007334877.tif 000017
【図１６】
2007334877.tif 000018
【図１７】
2007334877.tif 000019
【図１８】
2007334877.tif 000020
【図１９】
2007334877.tif 000021
【図２０】
2007334877.tif 000022
【図２１】
2007334877.tif 000023
【図２２】
2007334877.tif 000024
【外国語明細書】
2007334877000001.pdf