JP2005004719A - ロールバックによるデータレプリケーション方式 - Google Patents

Abstract

【課題】
データの多重アクセスに於ける現行システムでのデータの再ロード、その他の不便を回避するシステムと方法が必要である。更に又、生成データの特殊処理を必要としているアプリケーションが稼動できる、システムと方法が必要である。
【解決手段】
本発明は、現行システムの欠点を解決したデータの多重アクセスを可能にする。本発明は、一つ以上の処理システム又は処理システムアプリケーションの、一つ以上の中間又はその他の更新結果に対する保存、抽出、転送又はその他のアクセス等を可能にする。かくして、本発明は、データマイニング、データ共用、データ分配、データバックアップ、ソフトウエアテスト、バッチ処理等多様なアプリケーションで活用できる。
【選択図】図２

Description

本発明は一般的にコンピュータシステムに係わり、特にデータのレプリケーションを行う方法とシステムに関連する。

今日のエンタープライズコンピューティングシステムは、多重アクセス要求に対応できるものの、小型コンピューティングシステムが行ってきた方法と同じ動作を踏襲している。

例えば、図１に示すエンタープライズコンピューティングシステムでは、ストレージ１０２に格納されたデータにアクセスするアプリケーションプログラムを実行するアプリケーションサーバ１０１を有する。ストレージ１０２は更にＲＡＩＤ（Redundant Array of Independent Disk）として構成されるディスクアレイを有する。

ディスクアレイ１０２は、サーバ１１1ａ〜ｃがデータボリューム１２２ａ〜ｃ、１２３に発行するリード／ライト要求を実行する為の、アレイコントローラ１２１を有する。このようなデータアクセスの実行のために、アレイコントローラ１２１はデータルーテイング、キャッシング、冗長制御、パリティーチェッキング等の制御動作を行う。

本アレイコントローラ１２１は、データ発生サーバ１１１ａ〜ｃが記録したデータを、一つ以上のデータ利用アプリケーションサーバで稼動しているアプリケーションが独立に利用できる様に、データアクセス機能を提供する。本アレイコントローラ１２１は、データ発生サーバ１１１からのデータ保存要求に応えて“オリジナル”データをオリジナル又は“プライマリ”ボリュームに書き込む。

本アレイコントローラ１２１は、データ利用サーバ１１２からの最初のデータ要求に対して、オリジナルボリュームを“セカンダリ”ボリューム１２３にコピーし、その後のサーバ１１２からのデータ書き込み要求では、このセカンダリボリュームのデータを本サーバ１１２データで置き換える。対応するプライマリボリュームはこのようにして、サーバ１１２からは更新されず、他のデータ利用アプリケーションサーバからも同様に使用できる。

このような多重アクセス構成は、利用は拡大されているものの、格納データの利用法次第では不効率である事が判ってきた。

例えば、データバックアップアプリケーションでは、アプリケーションサーバ１１１からのデータ書き込み要求により、アレイコントローラ１２１はデータベースをプライマリボリューム１２２に書き込む。

バックアップサーバ、例えばサーバ１１２はデータベースのバックアップをデバイス１１３（例えばテープバックアップ）に行うと、アレイコントローラ１２１は本データベースをセカンダリボリューム１２３にコピーする。コピー中にも本データベースを使用するため、セカンダリボリュームを検証することが望ましい。然しながら、検証作業中のセカンダリボリュームのデータ変更は、セカンダリボリュームでのバックアップデータに不整合を発生させる為、本検証は不可能である本発明は一般的にコンピュータシステムに係わり、特にデータのレプリケーションを行う方法とシステムに関連する。

ソフトウエアテスト作業に於いては、アプリケーションサーバ１０１は、対象ソフトウエアを格納する開発システム１１１ａ、テスト環境を整える環境生成器１１１ｂ及びテスト条件を生成する条件生成器１１１ｃとなり、対象ソフトウエア及びテスト環境とテスト条件を（“テストデータ”と共に）プライマリボリューム１２２に保存することになる。

アレイコントローラ１２１は、テスタ１１２からの要求により、テストデータをセカンダリボリューム１２３にコピーし、以降の引き続くテスタ１１２からの書き込み要求により、セカンダリボリュームのデータをテスタ１１２からの引き続く更新データで置き換える事になる。不幸にして、ソフトウエア、環境、又は何かの原因でテストに失敗したり、又は更新要求があると、大量になりかねないテストデータをしばしばリモートソースから再ロードする必要が発生する。

バッチ処理環境では、アプリケーションサーバ１０１は、プライマリボリューム１２２にデータベースデータを格納するデータベース生成サーバ１１１とバッチプロセッサ１１２となる。

バッチプロセッサ１１２の最初のデータベース要求で、アレイコントローラ１２１はデータをセカンダリボリューム１２３にコピーし、バッチプロセッサ１１２のサブプロセスからの引き続くデータ書き込み要求により、サブプロセスからのデータでセカンダリボリュームの更新を継続する事になる。不運にも途中で、本サブプロセスがエラーになると、本サブプロセスの訂正処理に引き続いてソースデータは再度ロードされ、全体のバッチ処理は再実行しなければならない。

従って、データの多重アクセスに於ける現行システムでのデータの再ロード、その他の不便を回避するシステムと方法が必要である。更に又、生成データの特殊処理を必要としているアプリケーションが稼動できる、システムと方法が必要である。

本発明は、現行システムの欠点を解決したデータの多重アクセスを可能にする。本発明は、一つ以上の処理システム又は処理システムアプリケーションの、一つ以上の中間又はその他の更新結果に対する保存、抽出、転送又はその他のアクセス等を可能にする。かくして、本発明は、データマイニング、データ共用、データ分配、データバックアップ、ソフトウエアテスト、バッチ処理等多様なアプリケーションで活用できる。

本発明の一実施例では、アプリケーションサーバのアプリケーションがストレージデバイスに保存(断続的な保存を含めて)する一つ以上のデータセットを選択的にレプリケートし又は取り戻す事が出来る。

更に本発明では、ストレージデバイスは、アプリケーションサーバからの書き込み要求（又は“コマンド”）に対応して、プライマリ又はセカンダリボリュームのリアルデータスペースのデータをバーチュアルデータスペースに一回以上に亘りレプリケートし、又は以前にレプリケートしたバーチュアルデータスペースからのデータをリアルデータスペースにロールバック(取り戻す)することが出来る。

更に本発明では、バーチュアルコピー時刻、日付、名前等の一つ以上の指定により選択的にロールバックをすることが出来る。

更に本発明では、リアル及び対応するバーチュアルデータコピーに対して、同じサイズのストレージ媒体のような変動するメカニズムを使用する、バーチュアルデータコピー保存のため一つ以上のエクステントを使用する、上書きされたバーチュアルデータ及び(又は)バーチュアルボリューム生成を表す一つ以上のログ表示を保持するといった各方式が可能である。

本発明でのデータレプリケーション方式では、データストレージデバイスは、バーチュアルコピー要求を受信すると、バーチュアルストレージを生成し、その後新データを含むデータ保存要求を受信すると、バーチュアルストレージの一部を対応するリアルストレージ中のリアルデータで置き換え、リアルデータの一部を新データで置き換える。

データレプリケーションシステムは、プライマリ、セカンダリ等のリアルデータスペースに対するデータの読み書きを管理するストレージコントローラと、レプリケートされたデータを保存するバーチュアルデータスペースを管理するバーチュアルストレージマネージャを有する。

バーチュアルストレージマネージャは、後のデータレプリケーションに備えてバーチュアルデータスペースを事前に割り当てたり、バーチュアルデータスペースを必要になったときに保存と同時に割り当てたり、エクステントを用いたり、ログボリュームを使用したりすることの一つ以上が可能である。

本発明の効果により、全更新データを保存して不必要にストレージスペースを使用する事無く多数の中間的データの保存、回復を選択的に実施する事が出来る。

本機能はストレージデバイスの基本的なデータ処理機能に変更を加える事なしに実現することが出来る。本発明の更に別の面では、一つ以上の中間的データの選択的な保存と抽出が可能で、一つ以上の処理システムやアプリケーション間でデータの検索や分配が可能になる。他の効果については、以降の説明や図面により更に明確になる。

本発明のデータレプリケーションの為のシステムと方法では、継続してデータ格納されるストレージデバイス内の例えばセカンダリボリュームのデータスペースのデータが、全部又は一部分が更に“バーチュアル”コピーに保存退避される事を可能にする。

更に本発明では、更新されたデータスペースを、以前のデータスペースの選択された部分に“ロールバック”することを可能にする。

本発明は更に、柔軟な管理方法により、同サイズのリアルとバーチュアルボリューム方式、エクステント方式、及びログ方式等の多様なバーチュアルコピーが可能になる。

本発明では、更に、バーチュアルコピーへのデータの限定又は選択された入出力、ストレージデバイスによるエンタープライズ又は他のアプリケーションの遂行又はセキュリティーを可能にする。

ここでは、“又は”は特に注記されない限り、“及び／又は”の意味で使用されることに注意願いたい。

更にアプリケーションサーバは“発生”又は“更新”サーバとして参照され、システム／処理は特定のデバイス又はデバイスタイプに適用する事で本発明の理解を容易にしている。更にデータストレージは一般的に“ボリューム”とも呼ばれる。

然しながら、サーバや他のデバイスは多様な又は多重の処理を実施可能であり、又データを生成し処理可能な事にも注意願いたい。本発明は多様なデバイスタイプに適用可能であり、データスペース参照に実装次第によっては、ボリューム以外の用語を用いる事もある。以上の用語は限定的と看做してならない。

図２での本発明は、アプリケーションの要求に従う多様なシステム構成で使用可能なデータレプリケーションとロールバック方法を可能にする。ここで説明するシステム２００は、ネットワーク２１３と２０２を介して結合する、一つ以上のコンピューティングデバイスとデータレプリケーション可能なストレージデバイスを備える。

レプリケーションシステム２００は、データレプリケーション可能なディスクアレイ２１１、アプリケーションサーバ２１２，２１４ａ〜ｂ、２１５ａーｂ及びネットワークサーバ２１６等の、イントラネット２１３により互いに結合したデバイス群２０１を有する。

システム２００は更に、同様に結合したアプリケーションサーバ２０３と他のコンピューティングシステム２０４を有する。システム２００は更に、具体的実装の要求に従って、一つ以上のファイヤウオール２１７、ルータ、キャッシュ、冗長／負荷均衡システム、バックアップシステム、又は結合している他のネットワーク要素（図示していない）を含む。

データレプリケーションは、ストレージデバイスで、もっと典型的には“ＲＡＩＤ”(Redundant Array of Independent Disk)構成によるディスクアレイ２１１等の共有（“多重アクセス”）ストレージで実行される。

然しながら、レプリケーション可能なデバイスは、本発明での説明に整合するロールバックによるデータレプリケーションを可能にする一つ以上の単機能又は多重機能のストレージにより構成されることに注意が必要である。

ディスクアレイ２１１はディスクアレイコントローラ２１１ａ、バーチュアルボリュームマネージャ２１１ｂ及びストレージ媒体のアレイ２１１ｃを有する。ディスクアレイ２１１は、その他実装上の要求によりキャッシング、冗長回路、パリティーチェック、その他ストレージ又はサポート機能（図示していない）等の為のコンポーネントを含む。

この様なコンポーネントは、慣用的なディスクアレイやその他のストレージシステムに見られるものを含んでもよく、慣用的な構成でもよく、又特定アプリケーションの要求に従った構成でも良い。

アレイコントローラ２１１ａは、以降の例でも見られる本発明の方法又はアプリケーションの要求に従う方法で実行される“リアルデータセット”に関連する、ディスクアレイの管理を出来るようにする。

このような管理により、例えば、システム２００の他のデバイスとの交信、ファイル、フォルダ、デイレクトリ等のようなデータスペース中のアプリケーションデータの保存、抽出、削除、又はストレージに対するプライマリ又はセカンダリボリューム等の多重参照等が可能になる。

データスペースは、特に注記されない限り“ボリューム”を意味し；通常の又は慣用的データストレージのデータスペースは更に、以降で説明する“バーチュアル”ボリュームとは対照的に“リアル”ボリュームと呼ばれることを明確化のために注記する。

アレイコントローラ２１１ａはもっと具体的には、ソースデータを提供するデータ発生サーバ及び本ソースデータを使用するデータ更新サーバからの要求に従い、ディスクアレイ２１１のリアルボリュームを管理する。

アレイコントローラ２１１ａは、データ発生サーバのアプリケーションからの要求に対応して“オリジナルボリューム”に対する生成、読み取り、書き込み、又は削除を行う。アレイコントローラ２１１ａは更に、ユーザ又はデータ発生サーバ又はデータ更新サーバ からの“ペア生成”、“ペアスプリット”等の要求に応える。

一般的に、以降の“ペア生成”要求処理又はディスクアレイの（自動的）初期化処理に於いては、アレイコントローラ２１１ａは、プライマリボリュームに対応するセカンダリボリューム（が存在しない場合は）を生成し、アレイコントローラ２１１ａは更にセカンダリボリュームへのデータの読み書きを抑止して、オリジナルボリューム内のデータをセカンダリボリュームにコピーして、セカンダリボリュームをオリジナルボリュームに同期化する。

アレイコントローラ２１１ａは、ペアスプリット要求に対して、セカンダリボリュームへのデータの読み書きを可能にするが、オリジナルボリュームからセカンダリボリュームへのデータ同期は行わない。

アレイコントローラ２１１ａはデータ更新サーバからのデータ更新要求に対して、対応するセカンダリボリュームの生成、読み書き、及び削除を行う。

ペア生成要求は、更新サーバがデータの読み書き要求を発行する前に発行され、プライマリボリュームに対するセカンダリボリュームを生成し、セカンダリボリュームはプライマリボリュームのコピーを保存し、次いでペアスプリット要求が発生し、セカンダリボリュームは読み書き可能となる。

これ以上のペア生成要求はその後発生しないとして、アレイコントローラ２１１ａは後続する更新サーバからの更新要求に対して、セカンダリボリュームのデータを本サーバからの送信データで置き換えるが、オリジナルボリュームのデータは不変のままである。アレイコントローラ２１１ａは、データ読み取り要求に対して指定ボリュームからのデータを送信し、削除コマンドに対しては指定されたセカンダリボリュームを削除する。

従って、セカンダリボリュームはまた“コピー”ボリューム（ペアコピーを反映している）と呼ばれ、セカンダリボリューム上のデータは又“結果データ”（即ち更新結果を反映している）とも呼ばれ、オリジナルとセカンダリボリュームは併せて、デバイス２１１に関連して、既に述べた“リアルボリューム”を構成する。

（非初期でのペア生成又は“再同期”要求は更に、セカンダリボリュームへのアクセスを抑止して、オリジナルからセカンダリボリュームへのコピーを行い、更新されたセカンダリボリュームを対応するプライマリボリュームのソースデータに同期化する。

然しながら、典型的には以降に更に述べるように、プライマリボリュームの前回でのコピー時点以降の変更部分のみがセカンダリボリュームへコピーされる。

かくのごとく、部分的なデータコピーが可能な環境では、初期のペア生成要求がプライマリボリュームの全データを対応するセカンダリボリュームへコピーするが；これは言い換えると、コピー処理が、コピーされていない部分を全てセカンダリボリュームへコピーする機能を持っており、プライマリボリュームをそのよう（全ての部分がコピーされていない）に指定する事により、単一のペア生成コマンドが初期、非初期含めて同様に動作する事が出来る。）
アレイコントローラ２１１ａは、キャッシング、冗長処理、パリティーチェック、その他のストレージ又はサポート機能等を含む、しかしこれらに限定されない、その他のディスクアレイコンポーネントの管理を実行する。アレイコントローラ２１１ａは、特定の実装に従って様々なエクステントに対して、バーチュアルボリュームマネージャ２１１ｂとの連係動作を持つより以上又はより以下に統合的な実装も可能である。

より以上に統合化された構成では、アレイコントローラ２１１ａはアプリケーションサーバからの要求をバーチュアルボリュームマネージャ２１１ｂに依頼し、更にははバーチュアルボリュームマネージャ２１１ｂからの応答をアプリケーションサーバに転送しても良い。

アレイコントローラ２１１ａは更にバーチュアルボリュームコマンドの通訳を行い又はバーチュアルボリュームマネージャ２１１ｂからの要求に基づいて、ストレージに対する保存、抽出等を行ってもよい。アレイコントローラ２１１ａは更に、ディスクコントローラ又は他のコンポーネントの中に組み込まれてもよい。

（バーチュアルボリューム管理の中により以上に組み込めば、一般的な目的でのストレージデバイスコントロール機能の中で本発明にも適用できる機能について、重複を排除出来るが、組み込みが少ない程、現行のストレージ又はホストデバイス実装との互換性は向上する。従ってこの組み込みにもトレードオフが存在することに注意願いたい。）
バーチュアルボリューム（Ｖ．Ｖｏｌ）マネージャ２１１ｂは、一つ以上のバーチュアルボリュームに対する生成、書き込み、読み取り、削除、又は管理を行い、又は典型的にはストレージ媒体２１１ｃ内のバーチュアルボリュームデータに対する選択的格納と抽出等の管理業務を行う。

バーチュアルボリュームは他のボリュームタイプと同様に、ストレージ媒体２１１ｃ上にアプリケーションデータを格納し、システム２００の各要素が（ネットワーク２１３，２０２経由で）参照可能なストレージエリア又は“データスペース”が割り当てられる。

更新アプリケーションサーバからの“スナップショット”処理では、セカンダリボリュームに継続的に格納されたデータは、異なった時刻に異なったバーチュアルボリュームにレプリケートされ、要求に従って選択的にとり戻される。

ディスクアレイ２１１のバーチュアルボリュームは、オリジナル又は更新データのみならず一時的に生成された多種多様のデータ又はバーチュアルボリュームに書き込む前のセカンダリボリュームのデータの変更部分のみを、選択的に事前格納することが出来る。

そのようなデータは、例えば、一つ以上のセグメントを含む。（セグメントはデータの連続、非連続的部分を含み、そのサイズと数はアプリケーションの要求により決まり、ボリュームを定義する。）従って、バーチュアルボリュームデータは、選択されたデータが、オリジナル、一時的、更新又は更に処理済みデータか否かを問わず、又部分的に又は全体的にレプリケートされたデータか否かを問わず、特に注記されない限り、ここでは“中間的データ”と呼ばれる。

バーチュアルボリュームは、アプリケーション、ユーザの選択又は使用されているセキュリティー機能又はパラメータに従って、又は特定のアプリケーションに従って、自動的に、例えばプログラム的に、又は選択的に管理される。

例えば、バーチュアルボリュームマネージャ２１１ｂはリアルボリュームへのアクセス、アレイコントローラの動作をモニタでき（他の慣用的デバイスモニタ、イベント／データ転送技術を用いる事に相当する）、データバックアップ、データマインニング等の操作によって発生する、当該ボリュームの生成、データの保存、抽出その他に対して自動的に応答する事が出来る。

バーチュアルボリュームマネージャ２１１ｂは更に、一つ以上のアプリケーションに含まれるオペレーション、例えばプログラム命令等を、これまでの慣用的アプリケーションサーバと同様に、スタートアップ、又は一つ以上のユーザ、サーバ、イベント、タイミング等に応答して、格納し実行を開始することが出来る（図３〜４を参照）。

バーチュアルボリュームマネージャ２１１ｂは、例えば、バーチュアルストレージに存在した時点のアプリケーションデータが再構築できるように、異なったサーバからのアプリケーションデータのスナップショットをバーチュアルボリュームに格納することにより、又はデータの部分を格納することにより、モニタされたデータアクセスに応答することが出来る。

バーチュアルボリュームマネージャ２１１ｂは、更にバーチュアルボリュームデータを一つ以上のアプリケーションサーバに分配する事が出来る。自動動作に加えてサーバ起動の場合でもその他の選択肢の組合せについて同様に構成することが出来る。

もっと典型的には、バーチュアルボリュームマネージャ２１１ｂは、アプリケーションサーバからの要求即ち“コマンド”に対応して、バーチュアルボリュームを管理する。

そのようなコマンドはアレイコントローラ２１１ａに従って、個別的にも一般的にも構成することが出来き、これにより、既存のアレイコントローラの動作に広範囲に互換性を持たせることが出来る。

バーチュアルボリュームマネージャ２１１ｂは、バーチュアルボリュームの生成（以下の“チェックポイント”要求を参照）、セカンダリボリュームのデータをバーチュアルボリュームにレプリケート、バーチュアルボリュームのデータをセカンダリボリュームにレプリケート即ちセカンダリボリュームを以前の値にロールバックする、又はバーチュアルボリューム削除に対する応答等、コマンドに対してかなり制限された方法で応答する。

レプリケーション可能デバイスのより大きな処理／ストレージ能力は、コマンドと機能を広範に組み合わせて、本発明での開示（限定した範囲でしか紹介できないが）をより広範に利用できるようにする事が出来る。

バーチュアルボリュームマネージャ２１１ｂは、アプリケーションサーバと直接に交信する、又は例えばアレイコントローラ２１１ａを通して、より間接的に管理を実行する、何れの実装も可能である。

例えば、アレイコントローラ２１１ａが直接アプリケーションと交信し、バーチュアルボリュームマネージャ２１１ｂは、より統合的な実装に於いてコマンドをアレイコントローラ２１１ａ経由で受け取り、アレイコントローラ２１１ａを通して応答する事も出来る。

バーチュアルボリュームマネージャ２１１ｂは、更にアレイコントローラが書き込み、読み取り、削除等の動作を実行するのをモニタして、コマンドを受け取ってもよく、又バーチュアルボリュームの生成、データ格納、データ抽出や他の管理業務を実行するためのコマンドをアレイコントローラ２１１ａに依頼してもよい。

バーチュアルボリュームマネージャ２１１ｂは、データの管理に関してはかなり慣用的な方法、即ち慣用的なアレイコントローラが“リアルボリューム”を管理するのと同様な方法で、キャッシュその他のディスクアレイ２１１のコンポーネントを利用する事が出来る。

アレイコントローラ２１１ａ又はバーチュアルボリュームマネージャ２１１ｂは、図３〜４で説明するように、定常的にもダイナミックにも、実装又はアプリケーションに対応した別の選択肢が存在する事に注意が必要である。

ディスクアレイ２１１の他のコンポーネントについては、ストレージ媒体２１１ｃは、データを保存できる物理記憶媒体であり一つ以上のハードディスク、オプテイカルまたは他の可搬／固定媒体、キャッシュ又はアプリケーションに対応できるその他のストレージ媒体を含む。

他のコンポーネントとしては、例えばエラー検出回路、キャッシュ又はその他のストレージ又はアプリケーション依存のコンポーネントを含む。（このようなコンポーネントとしては、マス又は多重アクセスストレージとしてのリアルボリュームとして共通的に使用される、例えばディスクアレイ、又はネットワーク結合又はスタンドアロンのプロセッシングシステムが含まれる。）
アプリケーションサーバ２１４ａ〜ｂ、２１５ａ〜ｂ，２０３，２０４はユーザ／システムにシステム２００内での処理を提供し、ストレージ２１１へのデータ保存機能を持つデバイスを含み、アプリケーションに対応してバーチュアルボリュームマネージャ２１１ｂと連携する。

そのようなデバイスには、一つ以上のワークステーション、パーソナルコンピュータ“ＰＣ“、ハンドヘルドコンピュータ、セットトップボックス、パーソナルデータアシスタンス“ＰＤＡ”、パーソナル情報端末“ＰＩＭ”、セルフォン、コントローラ、所謂“スマート”デバイス、その他のエレクトロメカニカルデバイスが含まれる。

システム２００に残っているコンポーネントとしては、ネットワーク２１３と２０２は、スタティック又は再構築可能なローカル又は広域ネットワーク（“ＬＡＮ”、“ＷＡＮ”）、バーチュアルネットワーク（例えばＶＰＮ）、その他アプリケーションに対応した結合が含まれる。

ネットワークサーバ２１６は、ネットワークサーバオペレーション（例えば、ネットワークアクセス、ｅ−Ｍａｉｌ，システム管理等）の為に慣用的に構成された一つ以上のアプリケーションサーバで成り立つ。

図３では、システム２００（図２）の要素の一つ以上を構成する処理システムを示す。他の代替構成が可能であるが、簡単の為にシステム２００の要素は、特に注記しない限り、ハードウエア、ソフトウエア、又は一つ以上の処理システムの組合せとする。

処理システム３００は、一つ以上の汎用又は専用のプロセッサ３０２、例えばＰｅｎｔｉｕｍ（Ｒ），ＰｏｗｅｒＰＣ（Ｒ），ＤＳＰ(Digital Signal Processor)等を含めた通信チャネル３０１に結合した要素で成り立つ。

システム３００は更に、アプリケーションの要求に対応して、一つ以上の入力装置３０３（マウス、キーボード、マイクロフォン、ペン等）と出力装置３０４（ディスプレイ、スピーカ、アクチュエータ等）を有する。

システム３００は更に、ストレージ／メモリデバイス、又はハード又はリムーバブルストレージ／メモリデバイス等の、コンピュータ読み取り可能ストレージ媒体３０６とその読み取り装置３０５を有する。

そのようなデバイス又は媒体は、独立のストレージ３０８やメモリ３０９としても使用され、アプリケーションの要求に従ってハードディスク、フロッピ／コンパクトディスク、ディジタル多様ディスク（“ＤＶＤ”）、スマートカード、ＲＯＭ，ランダムアクセスメモリ、キャッシュメモリ等を含む。

モデム、ＤＳＬ，赤外線又は対応可能なトランシーバ等の一つ以上の通信デバイス３０７が更に含まれ、直接のデバイス間通信又は一つ以上のプライベート又はパブリックネットワークを介した交信を可能にする（これらに限定されるものでない）。

使用中に読み込まれ保存されるシステム２００の実装要素として、ワーキングメモリ３１０は、更にオペレーティングシステム（“ＯＳ”）３１１とアプリケーションプログラム、モバイルコード、データ等のプログラム３１２を含む。

ＯＳは、アプリケーションに対応したデバイスと機能に依存する（即ち、Ｗｉｎｄｏｗｓ、Ｍａｃ、Ｌｉｎｕｘ、Ｕｎｉｘ、Ｐａｌｍ ＯＳ、専用ＯＳ等）。多様なプログラム言語又はツールが利用される。

更に又、ワーキングメモリ３１０の内容である、ＯＳ３１１とその他のプログラム３１２は、ユーザのアプリケーションによってかなり影響を受ける事に注意願いたい。

ソフトウエア（即ち、一部又は全体を含めて、アプリケーションプログラム、オブジェクト、エージェント、ダウンロード可能、サーブレット等）で実装されている場合は、システム２００の要素はローカル又はリモートストレージからメモリ（又はキャッシュメモリ等）に実行する為のデータを一時的又は永続的に格納させ、又はその他の適切なメカニズムが使用され、要素はコンパイル状態かインタープリタ方式で実行される。

入力された中間的又は最終的データ又は機能要素は更に一時的又は永続的に、ストレージ媒体、キャッシュ又は他の揮発性、不揮発性メモリ（即ちストレージデバイス３０８、メモリ３０９）にアプリケーションに応じて保存される。

図４は、専用ホストと共にディスクアレイを使用して、如何にデータレプリケーションが実行されるかを説明する。図４は更に、プロセッサベースのアレイコントローラとバーチュアルボリュームマネージャのより以上に統合したアレイマネージャ４０３を示す。

図示されるように、レプリケーションシステム４００は、ホスト４０１とストレージデバイス４０２及びネットワーク４０６を含む。ホスト４０１は図３のシステム３００に対応し簡単の為に簡略化して表示しており、他方、同様に図３のシステム３００に対応するプロセッサベースのストレージデバイス４０２は大いに詳細に示されている。

ホスト４０１は、Ｉ／Ｏインターフェース４１１と４３１、結合４ａを通して、ストレージデバイス４０２と結合し、ストレージデバイス４０２に要求を発行する。

結合４ａは、例えば、“ＳＣＳＩ”(Small Computer System Interface)インターフェース、ファイバチャネル、“ＥＳＣＯＮ”（Enterprise System Connection）、“ＦＩＣＯＮ”（Fiber Connectivity）、イーサネットを含み、インターフェース４１１は一つ以上のプロトコル、ＳＣＳＩ、ｉＳＣＳＩ、ＥＳＣＯＮ、ファイバＦＩＣＯＮ等を使用する。ホスト４０１とストレージデバイス４０２は更に各々のネットワークインターフェース４１２、４３２と結合４ｂ、４ｃを通してネットワーク４０６に結合する。

この様なネットワーク結合は、例えば、ファイバチャネル、イーサネット、インタネットプロトコル（“ＩＰ”）、非同期転送モード（“ＡＴＭ”）等の一つ以上のプロトコルで実装される。

本ネットワーク結合は、ホスト４０１とストレージデバイス４０２がネットワーク４０６に結合しているその他のデバイス即ち図２のアプリケーションサーバ２１２，２１４ａ〜ｂ，２１５ａ〜ｂ、２１６，２０３及び２０４等と交信することを可能にする。（インターフェース４１１，４１２，４３１，４３２，４３３及び４３４は図３の通信インターフェース３０７に対応する。）ストレージデバイス４０２はインターフェース４３１〜４３４に加えてアレイマネージャ４０３とストレージ媒体４０４を有する。

アレイマネージャ４０３内のＣＰＵ４３５はメモリ４０５とキャッシュメモリ４５１内に格納されたコントロール情報４５２に基づき、内部バス４３６とストレージコントロールとデータレプリケーションを実行するための為の他の図示された結合を通して動作する。（既に述べたように、自動的動作又はストレージデバイス主導のリアル／バーチュアルのボリューム管理は、メモリ４０５に受信され格納されている情報に従って実行される。）
キャッシュメモリ４５１はホスト４０１からの受信データ、ホスト４０１への送信データを一時的に保管するために使用される。キャッシュメモリ４５１は更にホストから要求されたシーケンシャルなリード／ライトデータの事前格納の為にも使用される。

ストレージ媒体４０４はアレイマネージャ４０３に、Ｉ／Ｏインターフェース４３３、４３４と結合４ｆを経由して結合し、交信する。

ストレージ媒体４０４はアプリケーションからの要求に従い、一つ以上のＲＡＩＤ、ＪＢＯＤ(Just a Bunch of Disk)、その他の相応しい構成から成るディスクドライブ４４１のアレイを含む。

ストレージ媒体４０４は、内部バス４３６と結合４ｄ〜４ｆを通してＣＰＵ４３５に固有に結合し、本ＣＰＵ４３５は本ディスクの部分をボリューム（即ちプライマリ、セカンダリ、バーチュアルボリューム）として管理し、ホストからのストレージ媒体へのアクセスは本ボリューム（即ち、物理媒体に対してではなく）を通してのみ可能となる。ＣＰＵ４３５は更に既に述べたセキュリティー、アプリケーション又は実装によって必要になる機能を実行する。

図５は本発明に従う、より統合度の低いデータレプリケーションシステムを説明するフローダイアグラムである。システム５００はアプリケーションサーバ５０１とディスクアレイ５０２で構成される。

アプリケーションサーバ５０１は更に、データ生成アプリケーションサーバ５１１ａ〜ｂ、データ更新アプリケーションサーバ５１２ａ〜ｂ及びその他のデバイス５１３を有し、ディスクアレイ５０２は、更に、アレイマネージャ５０２ａ、ストレージ媒体５０２ｂ、及びネットワーク又は入出力インターフェース（“Ｉ／Ｏ”）５０２ｃを有する。

アレイマネージャ５０２ａは、アレイコントローラ５２１ａとバーチュアルボリュームマネージャ５２１ｂを含み、ストレージ媒体５０２ｂは、プライマリボリューム５２２ａ〜５２２ｂ、セカンダリボリューム５２３ａ〜５２３ｂ及びバーチュアルボリューム５２４ａ〜５２４ｂと５２４ｃ〜５２４ｄの各々の一式以上を有する。

明確のために、システム５００内の信号パスは実線の矢印で描き、コンポーネント間の主要なデータの流れは点線の矢印で示す。加えて、アプリケーションサーバ５０１は、他のサーバが利用する為のオリジナルデータを独占的に供給し（オリジナルアプリケーションサーバ１〜Ｍ ５１１ａ〜５１１ｂ）、他のアプリケーションサーバから供給されたデータを利用する（更新アプリケーションサーバ１〜Ｎ ５１２ａ〜５１２ｂ）。各アプリケーションサーバ５１１ａ〜５１１ｂ、５１２ａ〜５１２ｂは、データアクセスを要求する“コマンド”をＩ／Ｏバス５０２ｃを経由してアレイマネージャ５０２ａに送信する。

オリジナルアプリケーションサーバ５１１ａ〜ｂのアプリケーションが、データ書き込み要求（“データライト”）をアレイコントローラ５２１ａに発行し、アレイコントローラ５２１ａはオリジナルデータを（指定された）プライマリボリューム、例えば５２２ａに書き込む。

オリジナルアプリケーションサーバ５１１ａ〜ｂのアプリケーションは更に、データ読み出し要求（“データリード”）を発行し、アレイコントローラ５２１ａは、オリジナルボリュームから要求データを読み出し要求サーバに返送する。オリジナル又は更新サーバのアプリケーションはペア生成、ペアスプリット要求を既に述べたように発行可能である。（ボリュームのリード／ライト部分も類似して実行されることに注意願いたい。）
オリジナルアプリケーションサーバ５１１ａ〜ｂは一般的にはバーチュアルボリュームマネージャ５２１ｂとは交信する必要はない。

更に、サーバ５１１ａ〜ｂはデータの更新は行わず、プライマリボリュームのデータは、コピーを通してセカンダリボリューム５３２ａ〜ｂから利用できる為に、プライマリボリューム５２２ａ〜ｂはバーチュアルボリュームマネージャ５２１ｂに結合する必要はない。かくして、実装上特別な要求が発生しない限り、システム５００は、そのような機能なしでディスクアレイ５０２（又は他の使用するかも知れないストレージデバイス）を構成することによって簡略化出来る。

更新アプリケーションサーバ５１２ａ〜ｂのアプリケーションは、セカンダリボリュームに対して、以降説明するペア生成要求は除いて（上記を参照）データの読み書きを行うために、データリード及びデータライトコマンドを発行する事が出来る。

更新サーバは更にチェックポイント、ロールバック、データ保存、及びバーチュアルボリューム削除等を含むバーチュアルボリュームに影響を及ぼす簡略化したコマンドセットを発行する事が出来き、これによりバーチュアルボリュームの操作の複雑性が最小になる。

チェックポイント要求に対して、バーチュアルボリュームマネージャ５２１ｂは、指定されたセカンダリボリュームに対するバーチュアルボリューム（即ち、バーチュアルボリューム１−１，５２４ａ）を生成する。これ以降は、バーチュアルボリュームマネージャ５２１ｂは、データライト要求に対して、指定されたセカンダリボリュームセグメントのデータを最後に生成されたバーチュアルボリュームに保存する。

典型的には、生成と保存時点のタイムスタンプを含む一つ以上のバーチュアルボリューム識別子がバーチュアルボリュームに関連付けられる。

ロールバック要求を受け取ると、バーチュアルボリュームマネージャ５２１ｂは、少なくとも一つのバーチュアルボリュームの少なくとも一部分をセカンダリボリュームにレプリケートして、セカンダリボリュームを回復する。

最後に、バーチュアルボリュームマネージャ５２１ｂは、バーチュアルボリューム削除要求に対して、指定のバーチュアルボリュームを削除する。（以降説明するように、対象リアルボリュームがバーチュアルボリュームからレプリケート（ロールバック）され上書きされる前に、当該部分のデータを新たなバーチュアルボリュームに保存するために、適用対象セグメントの決定と一つ以上のバーチュアルボリュームからセグメントをコピーする事が、必要である；同様に、セカンダリボリュームの書き込みセグメントを唯一保存しているバーチュアルボリュームを削除する場合には、削除指定されたバーチュアルボリュームのセグメントをコピーして保存しておく必要がある。これにより、残ったバーチュアルボリュームはリアルボリュームのロールバックに使用可能として残る事が出来る。）
各種の代替案が可能である事に注意願いたい。例えば、セカンダリボリュームのスナップショットは、チェックポイントコマンドに対応して、バーチュアルボリュームにレプリケートする事も出来る。

然しながら、バーチュアルボリュームの生成とそれへのポピュレート（実際にデータを住まわせる即ち書き込むこと）を分離する事は、柔軟性を増大するメリットがある。

これにより例えば、バーチュアルボリュームを生成する事は、バーチュアルボリュームをポピュレートさせる事とは分離したメカニズム（例えば、プログラム機能で、更には分離したアプリケーション、又は分離したアプリケーションサーバで）で行う事も可能になる。

単純な単一スナップショットを使用することに比べて、更なる柔軟性は、セカンダリデータに対するチェックポイントコマンドで以降のセカンダリボリュームセグメントに対するデータライト要求が、追加コマンドなしで、レプリケーションを開始する事によりもたらされる。バーチュアルボリュームの一つ以上のセグメントに対する継続するデータ格納は、同じバーチュアルボリュームに対して、継続するデータライト要求がレプリケートされる事により簡便化される。

図６は、既に述べたコマンドを発行するためのコマンドフォーマットの一例を説明する。本例では、下記の項目を有する。コマンド６０１；（一般に最初の受領でアサインされるユーザが指定する参照名である）名前６０３；グループや第一又はソースボリュームに対するアドレス可能なデータ部ＩＤを指定する第一の識別子６０５；第二又はデスティネーションボリュームに対するアドレス可能なＩＤを指定する第二の識別子６０７；コマンドに含まれるデータ又はコマンドによりアクセスされるデータのサイズのような任意の適用可能なパラメータ６０９；及び含まれるデータそのもの６１１。

かくして、本フォーマットに従うペア生成（Pair Create）コマンドは、Pair Createコマンド６０１、ユーザが当該コマンドに指定し今後に参照される名前６０３、オリジナルボリュームＩＤ６０５、コピーボリュームＩＤ（本ペアを指定する識別子）６０７で構成される。図６のコマンドフォーマットに対応するコマンドセットは後続する表１で更に説明する。

図７ａ〜７ｃは、アレイコントローラ５２１ａとバーチュアルボリュームマネージャ５２１ｂの各々が、リアルとバーチュアルディスクアレイの動作管理を如何により独立して、又はあまり統合されないで実行するかを示す。

図示する通り、アレイコントローラ５２１ａは、アレイエンジン７０１を含み、本エンジンが、ボリュームマップ７０２によって与えられるプライマリとセカンダリボリュームとアプリケーションサーバ及び物理媒体とのマッピングを用いてアレイコントロール動作を実行する。

バーチュアルボリュームマネージャ５２１ｂはバーチュアルボリュームエンジン７０３を含み、本エンジンがボリュームマップ７０４、更にはオプションとしてセキュリティーマップ７０５を使用してバーチュアルボリューム管理動作を実行する。バーチュアルボリュームマネージャ５２１ｂは更に７ａの結合を通して、ローカル又はリモートの時刻と日付情報とに接続する。

各アレイコントローラ５２１ａとバーチュアルボリュームマネージャ５２１ｂは、リアル、バーチュアルの対応関係を、要求に伴うデータ、格納済みデータ（図３〜４を参照）により、更には各々のリアル、バーチュアルのマップを維持する事により、決定する事が出来る。

バーチュアルボリュームマネージャ５２１ｂは、コマンド実行に先立って、リアルボリュームマップ７０２を参照し（又は基本的マップは起動時に求めて、変更分はバーチュアルボリュームコントローラが維持してもよい）、アレイコントローラ５２１ａによるセカンダリボリュームの割り当てと共に、バーチュアルボリュームを参照する為にセカンダリボリュームとの対応関係を決める事が出来る。（例えば前に述べた同時係属中の出願を参照。）
バーチュアルボリュームマネージャ５２１ｂは、マップ７０４に更に上記の対応関係を追加し、自らのバーチュアルボリューム割り当てを追加する。バーチュアルボリュームマネージャ５２１ｂは、必要に応じて上記の複合マッピングを検索する事により（言い換えると、両方のマップを参照する事により）、セカンダリボリュームとバーチュアルボリュームとの対応関係を決定することが出来る。実際の実装によってはその他の決定／参照メカニズムを用いる事が出来る。

バーチュアルボリュームマネージャ５２１ｂは更に、アプリケーションサーバ、アプリケーション、ユーザ等々からのアクセス要求を、マップ７０４に蓄えられている各アクセスの許諾を示す事前決定ルール／パラメータと比較する事により、セキュリティープロトコルを実行する事が出来る。

この対象になる要求には、一般的又はより具体的特性に対応して、ロールバック又はバーチュアルボリュームの削除等が含まれる。アレイコントローラ５２１ａは、マップ７０２に関して以上と同様に動作する事が出来る。（マップ７０４と７０２の例は、図７ｂと図７ｃに示す。）
ロールバックでのレプリケーションについて、アレイコントローラとバーチュアルボリュームマネージャがアレイマネージャの中で結合して動作する（図４を参照）、より以上に統合的な例を説明する。ディスクコントローラは、更にアレイマネージャの中に統合されてもよく、又は直接ディスクアレイを制御する低レベルの機能を実行するのに、分離されて実装されてもよい。

ＲＡＩＤ構成が、本発明がよりよく理解されるように、再度描かれいる。（リアルボリュームに関する管理は、基本的にアレイコントローラによってなされ、バーチュアルボリュームに関する管理は、基本的にバーチュアルボリュームマネージャによってなされ、その他の管理は実装に対応して、必要に応じて割り当てられる。自動的オペレーションは、これまでに述べてきた事と実質的には同様であるが、以降の実施例によってより統合的に実行される。）
図８から始めると、サーバ８０１ａは結合８ｂを経由して、ディスクアレイ８０２に結合しており、本ディスクアレイはアレイマネージャ８０２ａとデータストレージ構造８０２ｂを有している。データストレージ構造８０２ｂは更に、リアルデータストレージ８２１とフリーストレージプール８０２ｄ及びバーチュアルデータストレージ８０２ｅを有する。リアルデータストレージ８２１は更に；オリジナルボリューム８２２ａ、オリジナルボリューム（ビット）マップ８２２ｂ、コピーボリューム８２３ａ、コピーボリューム（ビット）マップ８２３ｂ、及び同期／スプリットステータス表示子８２４の各々の少なくとも一つ以上を有する。

バーチュアルデータストレージは更に、フリーストレージプール８０２ｄとバーチュアルボリューム８０２ｅの各々の少なくとも一つを有する。（アレイマネージャは複数セット存在してもよく、各アレイマネージャは、バーチュアルボリュームとペアステータス表示子に関連して一台以上のオリジナルとコピーボリュームペアを管理可能である。）
コンポーネント８０２ａ〜ｅはこれまでに述べてきたのと同様に動作する。一般的に言って、アレイマネージャ８０２ａはオリジナルボリュームビットマップ８２２ｂ、コピーボリュームビットマップ８２３ｂ及びペアステータス８２４をオリジナル、コピーボリュームの管理に使用する。

アレイマネージャ８０２ａは更に、フリーストレージ８０２ｄの一部分を一つ以上のバーチュアルボリュームに割り当て、本バーチュアルボリュームを各コピーボリュームに対応して選択的に生成し、時刻／日時情報８２７を含むバーチュアルボリューム構成情報によって管理する。

オリジナルボリューム８２２ａ、コピーボリューム８２３ａ及びバーチュアルボリューム８２４ａ〜ｄは、各々、オリジナル、コピー又は更新データ、及びバーチュアル又は、一つのデータ部分を対応するコピーボリュームにロールバックするのに十分な一時的データ部分を格納する。

オリジナルボリュームビットマップ８２２ｂは、オリジナルデータが書き込まれたオリジナルボリュームの部分を、例えばビット、ブロック、グループ又はその他の単位で表示した表示子を保持し、一方、コピーボリュームビットマップ８２３ｂは、オリジナル又は更新データがコピーされたコピーボリュームの部分を表示する表示子を保持する。

同期／スプリットステータス８２４は、各ペア８２２ａ，８２３ａに対応するペア生成、ペアスプリット状態を表示するオリジナルーコピーの同期表示子を表示する。

フリーストレージプール８０２ｄは、コピーボリューム８２３ａに対応するバーチュアルボリュームを割り当てるための各ディスクアレイの（“Ｆｒｅｅ”）部分を提供する。フリーストレージプールはボリュームの一部か物理ディスク／ドライブの一部等の形で論理的に表示する。

図９は、受信した要求に対するアレイマネージャの応答を示す。ステップ９０１で要求を受信し、ステップ９０２で要求タイプを（要求を検索するか、自動起動オペレーションの場合はメモリ中の格納情報に基づいて）判定する。

以下に於いては、アレイマネージャは結合しているサーバから要求を受け取ったものとし、自動起動オペレーションの場合も本記述に矛盾しない形で実行されるものとする。

本Ｉ／Ｏ要求種類にはボリュームＩ／Ｏ要求、ペアオペレーション及びバーチュアルボリュームオペレーション（又は“スナップショット”）がある。ボリュームＩ／Ｏ要求には、データリード（ステップ９０７）とデータライト（ステップ９０８）がある。ペアオペレーションには、ペア生成（ステップ９０３）、ペアスプリット（ステップ９０４）、ペア（再）同期(“Ｒｅｓｙｎｃ”) （ステップ９０５）及びペア削除（ステップ９０６）がある。

スナップショットオペレーションには、チェックポイント（ステップ９０９）、ロールバック（ステップ９１０）、及びチェックポイント削除（ステップ９１１）がある。サポートしていない要求に対しては、アレイマネージャはエラー終了する（ステップ９１２）。

（以上の要求やエラー表示は、図６のコマンド構成と合致し、特定の実装の場合は他の構成になることもある。

更には、以上のオペレーションは対応するボリューム部分例えばセグメントに対して実行され、本実行も要求時に一気に実行するか、継続して実行するか又は都合のよい時刻か何かのイベントを契機に実行することにより、限定されたシステム処理能力を多様なアプリケーションの要求に対応できるようにする。）
一般的に、データリード、データライトの要求は、サーバ（図８の８０１ａ）に対して、各々オリジナル又はセカンダリボリュームに対するデータの読み書きを可能にする。ペア生成、ペアスプリット、ペア再同期、及びペア削除の各要求は；最初にオリジナルボリュームに対するＩ／Ｏ要求を抑制して、オリジナルボリュームに対応するコピーボリュームを生成して、オリジナルボリュームをコピーボリュームにコピーして両者を同一内容にし；
プライマリからセカンダリへの同期を抑制し；
リードライト要求を抑制して、更新されたオリジナルボリュームの部分を対応するセカンダリボリュームにコピーし；
更に、存在するオリジナルボリュームとコピーボリュームのペアステータスを“削除”する。（ペア削除要求は、コピーボリュームとバーチュアルボリュームを切断して、同期を抑止するためにも使用されることに注意。反対にユーザはペア状態を維持することも選択できる。）
チェックポイント、ロールバック、及びチェックポイント削除の要求は各々、バーチュアルボリュームを生成して、そこへリアルデータをレプリケートし；
バーチュアルボリュームの一つ以上の部分を対応するリアルデータにコピーし、本バーチュアルボリュームがリアルボリュームの昔の一時点でのスナップショットを提供し；
バーチュアルボリュームを削除する。
データ管理実装の比較
図８、図９を参照しながら図１０に続けると、本発明では多様なレプリケーションシステム構成が可能になる。各々が図９で説明した“インストラクションセット”の受信に対応する、三つの実装方式を詳細に検討する。

各実装に於いて、図８のデータレプリケーションシステムが使用され、アレイマネージャ８０２ａがサーバ８０１ａからの要求に基づいて、ディスクアレイオペレーションを実行するものとする。異なった実装例についても検討するが、互いに組合せ可能なこれらの事例は、本発明の多様な面をよりよく理解するのに有効である。

これら三つの実装方式は、バーチュアルボリュームに書き込みまた管理する方法で大きく異なる。然しながら各方式は組合せ可能で、更に特定の実装に合わせて仕立てをする事が可能である。

最初の“同一ボリュームサイズ”データレプリケーション方式（図１０〜２０ｂ）は、対応するコピーボリュームと実質的に同じサイズのバーチュアルボリュームを使用する。

第二の“エクステント”方式（図１０と２１〜２５ｂ）のデータレプリケーションでは上書き部分のデータ保存に“エクステント”を利用する。

第三の“ログ”データレプリケーション方式（図１０と２６〜３２ｂ）では、レプリケートされた上書き又は“更新”データのログを利用する。
「同一ボリュームサイズ」方式
図１０は図９のステップ９０１，９０２，９０３に対応し、ペア生成要求に対するアレイマネージャの応答を示し、“同一ボリュームサイズ”方式と“エクステント”方式に対して適用可能である。本要求では、オリジナルボリュームと対応するコピーボリュームを指定し、本指定は例えばＳＣＳＩのＬＵＮ（Logical Unit Number）で行ってもよい。

ステップ１００１に示すように、ボリューム管理構造が生成され、セグメント表示子と共に保存され、実質的エラーは無かったことを条件に正常終了が要求元に返送される（ステップ１００２）。

（本正常終了表示と他の関連データは、他のアプリケーション、デバイス等にも転送され他の管理、エラーリカバリ、バックアップ等に供される。デスティネーション表示等他のデータ、パラメータ、指示、結果も転送してもよい。）
図１１は本実施例での、“同一ボリュームサイズ”方式にてアレイマネージャが使用可能なデータ管理構造の一例を示す。

本実施例では、コピーボリュームと実質的に同一サイズのバーチュアルボリュームは、コピーボリュームと実質的に等しいシャドーボリュームデータを格納する“シャドー”ボリュームとして稼動する。

コピーボリュームのサイズは予め判明しているために、シャドーボリュームはライト要求が受信される前に事前割当しておくことが可能である。（然しながら、コピーボリュームとバーチュアルボリュームとの組合せが異なれば、異なったサイズを持つことが出来る。更にセグメントサイズも異なったコピーボリュームとバーチュアルボリュームに対応して、同じボリュームサイズに対しても異なることも可能である。）
システム１１００は、ペア情報（“ペア情報”）１１０１、バーチュアルボリューム情報（“バーチュアルボリューム情報”）１１０２、及びセグメント情報（バーチュアルボリュームセグメント“リスト”）１１０３を有する。各オリジナルとコピーボリュームのペア及びバーチュアルボリュームに対して代替のデータ構造が同様に定義できる事に注意する事。

ペア情報１１０１は、オリジナルボリューム１１１１、オリジナルボリュームに対応するコピーボリューム１１１２及びコピーボリュームに対応して使用可能な（０〜ｎ）バーチュアルボリューム１１１３に対応する合計三つのエントリを持つ。

オリジナルとコピーボリュームのエントリは、要求者が各リアルボリュームペアに対して指定した要求者ＩＤ（“ＬＵＮ０”及び“ＬＵＮ１”）１１１４とアレイマネージャが内部的に各ボリュームをアクセスする時に使用する内部ＩＤ（“Ｖｏｌ０”及び“Ｖｏｌ１”）１１１５を有する。

ペア情報１１０１は、更に、最初のバーチュアルボリューム管理構造（各順番に並んだバーチュアルボリュームに対応して次々にリンクする）をポイントするバーチュアルボリューム識別子１１１６を有する。

（本事例に対して他の多様なデータ構造が可能であり、例えば、一つ以上のｎ次元の配列、直接アドレス、間接アドレス、リンク付きリスト、テーブル等の変形が可能である事に注意願いたい。）
各々のバーチュアルボリューム情報１１０２は、バーチュアルボリューム名１１２１、バーチュアルボリューム（又は“前”の）データ１１２２、セグメントテーブルへのポインタ１１２３、日時情報を保管するタイムスタンプ１１２４、及び次のボリュームのバーチュアルボリューム情報へのリンク１１２５より構成される。

本例では、要求者によるバーチュアルボリューム名は、要求者が本ボリュームを識別できるようにした一つ以上のバーチュアルボリューム名（ここではバーチュアルボリュームＡ〜Ｎ）を指定し、バーチュアルボリュームの生成時刻又は日付、これに最も近い時刻又は日付、又は要求者が指定する時刻又は日付を決定することが出来る。（内部的な“Ｖｏｌ０，Ｖｏｌ１”等の値は要求者指定のバーチュアルボリューム名Ａ―Ｎにマップされる。）
（最後の日時事例に於いては、対応するバーチュアルボリュームを、要求日時表示をバーチュアルボリュームが生成されたタイムスタンプ１１２４と比較して、選択指定に従ってより遅い、早い又は最も近いバーチュアルボリュームを選択する等のメカニズムを用いて選択することが出来る。他の組合せについては、アプリケーションに対応して使用することが出来る。）
バーチュアルボリューム情報の残りの部分については、バーチュアルボリュームデータ１１２２は、レプリケートされた又は“前”のコピーボリュームを示す。

セグメントテーブル識別子１１２３は、本バーチュアルボリュームに対応するセグメントテーブルへのポインタである。次へのボリュームリンク１１２５は、（次に又は直前に生成された）バーチュアルボリューム情報へのポインタである。

セグメントリスト１１０３は対応するバーチュアルボリューム情報で指定されるシャドーボリュームの状態を示す。各セグメントリストのエントリは、セグメント表示子とレプリケーションを示す二つの欄を有する。

既に説明したように、ボリュームはセグメントと呼ばれる一つ以上の部分に分割されており、各セグメントは、ペア生成に従ってコピーボリュームにコピーされるか、各コピーボリュームセグメントリストの更新結果に従ってバーチュアルボリュームにレプリケートされる。

図１１の実施例では、各テーブルは、セグメント番号１１３１（ここでシーケンシャルなセグメント番号はバーチュアルボリュームに対応する）とレプリケート又は“書き込み済み”状態フラグ１１３２の欄を有する。各フラグが、本セグメントが、対応するコピーボリュームセグメントからシャドーボリュームセグメントにレプリケートされた（“１”）か否（“０”）かを表示する。

図１２は、ペアスプリット要求に対するアレイマネージャの応答を示し、本応答は、同一ボリュームサイズ方式、エクステント方式、及びログ方式の何れにも適用可能で、図９のステップ９０１，９０２，９０４に対応する。本要求では、既に述べたペア生成要求と同じく、オリジナルボリュームと対応するコピーボリュームが指定される。

図示するようにアレイマネージャは、ステップ１２０１にてペアステータスをペアスプリット状態に変更し、実質的エラーが無かった条件で、ステップ１２０２にて正常終了表示が要求者に返送される。

図１３、図１４ａ、図１４ｂはペア同期要求に対するアレイマネージャの応答を示し、本応答は、同一ボリュームサイズ方式、エクステント方式、及びログ方式の何れにも適用可能で、図９のステップ９０１，９０２，９０５に対応する。本要求では、既に述べたペア生成要求と同じく、オリジナルボリュームと対応するコピーボリュームのペアが指定される。

図１３では、アレイマネージャ（例えば８０２ａ）は、ペアステータスをペアスプリット状態からペア同期状態に変更（ステップ１３０１）し、一時的ビットマップテーブルを生成する（ステップ１３０２、図１４ａを参照）。一時的ビットマップテーブルは、ペアスプリット状態中での更新セグメントを示す（ステップ１３０２）。

このコピーされたボリュームセグメントはオリジナルボリュームから上書きされ、コピーボリュームはオリジナルボリュームに同期化される（ステップ１３０４〜１３０５）。

次いで、ビットマップテーブルはリセットされて、全ての更新オリジナルボリュームはコピーボリュームにコピーされたことを示し（ステップ１３０６）、実質的エラーが無かったとして、ステップ１３０７にて、正常終了表示が要求者に返送される。

図１４ａは、一時的ビットマップテーブル１４０３が如何にして、オリジナルボリュームビットマップテーブル（“ビットマップ−Ｏ”１４０１）とコピーボリュームビットマップテーブル（“ビットマップ−Ｃ”１４０２）から生成される（図１３のステップ１３０２）かを示す。

図示するように、テーブル１４０１〜１４０３は、各ボリュームに対応するセグメントエントリを持ち、各々のセグメントが、前回のコピー又はレプリケーション以来更新されたか（“Ｙｅｓ”）否（“Ｎｏ”）かを示す。

テーブル１４０４に示すように、一時ビットマップテーブル１４０３は、ビットマップ−Ｏとビットマップ−Ｃの対応する行の“Ｙｅｓ”に対するＯＲ操作で実施される。一度一時的ビットマップテーブル１４０３が生成されると、本テーブルに基づいて、コピーボリュームはオリジナルボリュームに同期化され、テーブル１４０１，１４０２のフラグは“Ｎｏ”にリセットされる。

図１４ａに関連して、図１３と図１４ｂは更に、コピーボリュームの同期方法を説明する。本セグメントコピー動作（図１３のステップ１３０４〜１３０５）では、前回のセグメントコピー以降に更新になったセグメント（図１４ａの一時的ビットマップ１４０３で示される）がオリジナルボリュームからコピーボリュームにコピーされる。

もっと具体的に記すと、コピーは既に述べたように一時的ビットマップの“Ｙｅｓ”フラグを持つセグメントがオリジナルボリュームからコピーボリュームにコピーされる。（例えば、図１３のようにオリジナルボリュームの対象セグメントのデータを読み込み、対応するコピーボリュームのセグメントに書き込むか、又は以下に説明するようにオリジナルボリュームからコピーボリュームにデータを書き込む、といった一つ以上のコピー動作を用いてコピーされる。）
一時的ビットマップテーブル１４０３では、例えば、セグメント０（Ａ）、２（Ｃ）、３（Ｄ）、４（Ｅ）がＹｅｓフラグを持っており、他のセグメント１（Ｂ）、５（Ｆ）はＮｏフラグを持っている。一時的ビットマップ１４０３（図１４ａ）に従い、Ｙｅｓフラグを持っているセグメントがオリジナルボリューム１４１１（図１４ｂ）からコピーボリューム１４１２にコピーされる。

もっと具体的に記すと、セグメント０は（“Ａ”から“Ｇ”に）、セグメント２は（“Ｃ”から“Ｈ”に）、セグメント３は（“Ｄ”から“Ｉ”に）、セグメント４は（“Ｅ”から“Ｊ”に）変更されたとする。

引き続くコピーの結果、コピーボリュームのセグメント０，２，３，４の内容は各々“Ｇ”，“Ｈ”，“Ｉ”，“Ｊ”になり、他のセグメント１，５は元のまま（“Ｂ”，“Ｆ”）である。結果として、コピーボリュームはオリジナルボリュームと同一の内容となる。

図１５は、ペア削除要求に対するアレイマネージャの応答を示し、本応答は、同一サイズボリューム方式、エクステント方式、及びログ方式の何れにも適用可能で、図９のステップ９０１，９０２，９０６に対応する。本要求では対象となるコピーボリュームが指定される。

ステップ１５０１で示すように、アレイマネージャは当該ボリュームペア（及び関連するバーチュアルボリューム）に対応する、ペア情報、バーチュアルボリューム情報、ビットマップテーブル等のデータ構造を削除する。

ステップ１５０２で、更にアレイマネージャは各資源の割り当てを解除し、開放されたデータスペースをフリーストレージプールに返却する。かくして、「同一ボリュームサイズ」方式では、指定されたコピーボリューム及びバーチュアルボリュームの為に使用されていたデータスペースは開放される。（同様に、以下に説明するエクステント及び関連するログが返却される。）最後に、実質的エラーが無かったとして、ステップ１５０３にて正常終了表示が要求者に返送される。

図１６では、データリード要求に対する応答を示し、本応答は同一サイズボリューム方式、エクステント方式、及びログ方式の何れにも適用可能である（図９のステップ９０１，９０２，９０７に対応する）。本要求では対象ボリュームが指定され、コマンドタイプとしてデータリードが指定される。

ステップ１６０１にて、アレイマネージャは要求ボリューム指定情報を解析して、対象ボリュームがオリジナルボリュームかコピーボリュームかを判定する。

ステップ１６０１にて対象ボリュームがオリジナルボリュームと判定されれば、ステップ１６０２にて、アレイマネージャはオリジナルボリュームから読み取る；反対にコピーボリュームだと判定されれば、ステップ１６０３にてコピーボリュームから読み取りを行う。アレイマネージャは、ステップ１６０４にて、リードデータと正常終了報告（実質的エラーがなかったとして）を要求者に返送する。

図１７ａと図１７ｂは、データライト要求に対する応答の例を示し、本応答は、同一サイズボリューム方式、エクステント方式、及びログ方式の何れにも適用可能である（図９のステップ９０１，９０２，９０８に対応する）。本要求では、対象ボリュームの指定と、コマンドタイプとしてデータライトが指定される。

ステップ１７０１（図１７ａ）にて、アレイマネージャは、現在のオリジナルーコピーボリュームペアのペアステータスを判定する。

本ステータスがペア同期中なら、アレイマネージャはステップ１７０２にて指定されたデータを指定されたオリジナルボリュームに書き込み、ステップ１７０３にて、ＷＲＩＴＥ＿ＳＵＢプロセスをコールする。ステップ１７０８にて、正常終了報告（実質的エラーがなかったとして）を要求者に返送する。

現在のペアステータスがペアスプリット状態なら、アレイマネージャはステップ１７０４にて書き込み対象のボリュームタイプを判定する。

オリジナルボリュームなら、アレイマネージャは更に、判定された本ボリュームに要求されたデータを書き込み（ステップ１７０５）、本ボリュームに対してビットマップフラグＯをセットする（ステップ１７０６）。

コピーボリュームに対しては、ＷＲＩＴＥ＿ＳＵＢプロセスをコールする（ステップ１７０７）。何れのケースでも、正常終了報告（実質的エラーがなかったとして）を要求者に返送する（ステップ１７０８）。

図１７ｂは、ＷＲＩＴＥ＿ＳＵＢプロセスを示し、同一サイズボリューム方式で、アレイマネージャが対応するコピーボリュームに対して、最初の書き込みを含めて行う処理ステップを示す。

アレイマネージャはステップ１７２１にて、本セグメントに対する書き込みは前回バーチュアルボリュームが生成さた以降最初の書き込みか否かを判定する。アレイマネージャは、最後に生成されたバーチュアルボリュームに関連するセグメントリスト中の書き込みフラグを更に調べて、“Ｙｅｓ”フラグが存在れば、本書き込みは最初の書き込みではないと判断して、指定されたデータをコピーボリュームに書き込み（ステップ１７２２）、対応するセグメントのビットマップにフラグをセットする（ステップ１７２３）。

反対に本書き込みが生成されたボリュームのセグメントに対する最初の書き込みだと判断した場合は、アレイマネージャは、最初にコピーボリュームの対象セグメント中に存在する書き込みデータを保護するために“シャドー”ボリューム（最後に生成されたバーチュアルボリューム）にレプリケートする（ステップ１７２４）。

次いで要求の書き込みデータをコピーボリュームに書き込み（ステップ１７２５）、対応するビットマップにフラグをセットする（ステップ１７２６）。更に、アレイマネージャは最後に生成されたシャドーボリュームに対応する書き込み済みフラグをセットする（ステップ１７２７）。

図１８ａ〜図１８ｃは、チェックポイント要求に対する応答を示し、本応答は同一サイズボリューム方式に対して適用可能である（図９のステップ９０１，９０２，９０９に対応する）。本要求では、対象コピーボリュームとコマンドタイプとしてチェックポイントを指定する。チェックポイント要求は指定されたコピーボリュームに対してバーチュアルボリュームを生成する。

図１８ａでは、ステップ１８０１でアレイマネージャは、バーチュアルボリューム管理構造即ちバーチュアルボリューム情報を生成し、本情報には本新しいバーチュアルボリュームの為の新しい構造を含み、既存のバーチュアルボリュームの構造（存在すれば）に対するリンクを設定する。

アレイマネージャは更に、バーチュアルボリューム名とタイムスタンプを割り当て（ステップ１８０２）、全てのフラグがリセットされているセグメントリストを生成してこれに対するリンクを設定し（ステップ１８０３）、フリーストレージプールよりシャドーボリューム（データスペース）を割り当てる（ステップ１８０４）。（既に述べた通り、シャドーボリュームのサイズはコピーボリュームに等しいと決まっているために、シャドーボリュームはこの時点で割り当てる事が出来る。）本チェックポイント作業中に実質的エラーがなかったとして、正常終了報告を要求者に返送する。

（既に述べたように本発明のチェックポイントについては更なる代替案がある。本案では、新バーチュアルボリュームを生成し更に対応するコピーボリュームのスナップショットを本新バーチュアルボリュームに書き込むことを単一の要求で実施する。）
図１８ｂと図１８ｃは、チェックポイントとデータライトの組合せに対するアレイコントローラの動作例を示す。

図１８ａでは、本事例のチェックポイント要求は単に新しいバーチュアルボリュームを生成するのみで当該ボリュームへのデータ書き込みは行わない。加えて、本事例では、明確にするためにバーチュアルボリュームの生成とデータ保存のみに着目しており、バーチュアルボリュームの生成と関連する管理は上記に述べた通りに実行される。

図１８ｂではチェックポイントと関連する書き込みの処理流れを図示する。

ステップ（１）、（２）でチェックポイント要求を示し、（１）バーチュアルボリューム生成要求を受信してこれに応答する。（２）フリーストレージプールよりシャドーボリュームを割り当てる。

（３）〜（５）のステップで対応するコピーボリュームへのデータライト要求を説明する；（３）コピーボリュームへの書き込み要求を受け取りこれに応答し；
（４）対応するコピーボリュームのデータをシャドーボリュームに書き込み；
更に（５）要求されたデータをコピーボリュームへ書き込む。

図１８ｃでは、図１８ｂの例に対応し、要求１８４１ａ〜ｈが、データライト要求の対象になるコピーボリューム１８４２を配下に有するディスクアレイのアレイコントローラによって連続的に、実行される。コピーボリューム１８４２のセグメント０〜５は、時刻＝０に於いて“Ａ”―“Ｆ”のデータを保有している。

コピーボリューム１８４３は、１８４１ａ〜ｈが実行された後のコピーボリューム１８４２の状態である。

最初に、データライト要求１８４１ａ，１８４１ｂにより、セグメント０（“Ａ”），１（“Ｂ”）をデータ“Ｇ”，“Ｈ”で各々置き換える。

チェックポイント要求１８４１ｃがシャドーボリューム１８４４を生成し、この後次のチェックポイント要求迄に発生するデータライト要求が本シャドーボリューム１８４４にシャドーされる。

次のデータライト要求１８４１ｄ（“Ｉ”をセグメント０に）がセグメント０（現在“Ｇ”）をシャドーボリューム１８４４のセグメントにレプリケートし、次いでコピーボリュームのセグメント０（“Ｇ”）は“Ｉ”で置き換えられる。

コピーボリューム１８４２のセグメント２に対する、データライト要求１８４１ｅ（“Ｊ”をセグメント２に）も同様に、現データ“Ｃ”をシャドーボリューム１８４４のセグメント２に保存し、コピーボリューム１８４２のセグメント２はデータ“Ｊ”で置き換えられる。

チェックポイント要求１８４１ｆがシャドーボリューム１８４５を生成し、この後次のチェックポイント要求までに発生するデータライト要求がシャドーボリューム１８４５にシャドーされる。

次のデータライト要求１８４１ｇ（“Ｋ”をセグメント０に）でセグメント０（現在“Ｉ”）がシャドーボリューム１８４５のセグメントでレプリケートされ、次いでコピーボリュームのセグメント０（“Ｇ”）は“Ｋ”で置き換えられる。

コピーボリューム１８４２のセグメント３に対する、データライト要求１８４１ｈも同様に、現データ“Ｄ”をシャドーボリューム１８４５のセグメント３に保存し、コピーボリューム１８４２のセグメント３はデータ“Ｌ”で置き換えられる。

結果として、コピーボリューム１８４３のセグメント０〜５は（即ち１８４２の１８４１ａ〜ｈ実行後）は、“Ｋ”，“Ｈ”，“Ｊ”，“Ｌ”，“Ｅ”，“Ｆ”を保有する事になる。最初のチェックポイント要求に対応するタイムスタンプをもつシャドーボリューム１８４４は、セグメント０，２にデータ“Ｇ”，“Ｃ”を各々持つ。

次のチェックポイント要求に対応するタイムスタンプをもつシャドーボリューム１８４５は、セグメント０，３にデータ“Ｉ”，“Ｄ”を各々持つことになる。

図１９ａと図１９ｂはロールバック要求に対する応答を示す。本応答は、同一サイズボリューム方式に対して適用可能である（図９のステップ９０１，９０２，９１０に対応する）。本要求は、対象となるコピーボリューム、バーチュアル又はシャドーボリューム（名前、時刻等）とコマンドタイプとして、ロールバックを指定する。

ロールバック要求は、指定されたコピーボリュームを前に保存していたバーチュアルボリュームの状態に戻す（ロールバックする）。既に述べた様に、バーチュアルボリュームを戻す事は、同じコピーボリュームからのデータを含むことになる。

バーチュアルボリュームは更に、他のサーバ/アプリケーションよりの既存データを含む事が出来、ロールバック又は他のバーチュアルボリュームに影響する要求は、既に述べた他のオペレーションを開始するかも知れないことには注意が必要である。

図１９ａでは、ステップ１９０１で、アレイマネージャはステップ１９０２，１９０３を、前回の同一コピーボリュームに対するチェックポイント要求以降に、指定されたコピーボリュームからシャドーボリュームに移された全てのセグメントに対して、実行する。

ステップ１９０２にて、アレイマネージャは要求に対応する最古（指定時刻又は対応するバーチュアルボリューム以降最初に保存された）のシャドーボリュームセグメントを判定し、当該最古のセグメントより読み取る。次いで、ステップ１９０３でアレイマネージャは既に述べたＷＲＩＴＥ＿ＳＵＢプロセスをコールして、対応するコピーボリュームのセグメントを要求に対応する最古のセグメントで置き換える。実質的エラーがなければ正常終了報告が要求者に返送される。

図１９ｂは、これまでの説明に適用できる一般的なロールバック動作を説明する（ステップ１９３０〜１９３２）。本例では、コピーボリュームセグメントを（指定されたバーチュアルボリュームのデータに）取り戻す前に、本セグメント（又は上書きされるデータについてのみ）はバーチュアルボリュームに（本ボリューム又は他のボリュームに）保護（レプリケート）される。

ここでは、本ロールバック要求は、ロールバック要求が対象とするコピーボリューム１９１１とシャドーボリューム１９１２〜１９１５を配下に有するディスクアレイのアレイコントローラにより、成功裏に実行されるものとする。

コピーボリューム１９１１の時刻＝０のセグメント０〜８は、各々データ“Ａ”〜“Ｉ”を持っている。コピーボリューム１９１１ｂはロールバック実行後のコピーボリューム１９１１ａを反映する。

ステップ１９３０で“バーチュアル（シャドー）ボリュームＢへのロールバック”要求を受信後、アレイマネージャは、本ロールバックはコピーボリューム１９１１のセグメント０〜２を置き換えることを判定し、新しいバーチュアルボリューム“Ｄ”１９１６を生成して、対応セグメント“Ａ”，“Ｂ”，“Ｃ”を本新しいバーチュアルボリュームのセグメント０〜２に保存する（ステップ１９３１）。

他の例と同様に、このような決定には、ロールバック要求内の一つ以上のセグメントを指定する指定子を使用することが含まれる。又はもっと典型的には、変更なしデータに対応して要求の指定データ内に空の値を含んでもよい。

アレイマネージャは次いで、コピーボリュームのセグメント０〜２をバーチュアルボリュームのセグメントと置き換える（ステップ１９３２）。もっと具体的には、アレイマネージャはコピーボリュームのセグメント０〜２を要求に対応するセグメントで最古のバーチュアルボリュームのセグメントで置き換える。

ここでの例では、シャドーボリュームＢのセグメント０（データ“Ｊ”）；，シャドーボリュームＣのセグメント１（データ“Ｎ”（“Ｋ”ではない）），シャドーボリュームＤのセグメント２（データ“Ｑ”）に置き換える。

図１９ｂの例は更なるメリットが存在する。即ちリアルーボリューデータは、実質的に全てのケースで保護され、更に将来バーチュアルボリュームデータをリストアする事により、望み通りに利用する事が出来る。コントール情報を含む他のデータも要求者の間にリストア又は転送する事が出来、追加の要求もアレイマネージャによって実行することが出来る。

かくして、例えば、ソース又はデスティネーションが、バーチュアルボリューム管理情報以外からは知る必要がない形で、バーチュアルボリュームは、上記（連続した要求、ターゲット又は処理情報等）の転送を実行する為に、利用可能である。

更に又これまでのことより、ストレージデバイスの登録や他のメカニズムは、代わって又はある種のアプリケーションに関連して採用できるとしても、本バーチュアルボリュームの実装では、このようなストレージデバイスの登録や他のメカニズムの必要性を低減し、他にも利用価値のあるもっと本質的なカニズムをもっと有効に活用できるようにする。

ロールバックは更に、セキュリティー、アプリケーション、分散デスティネーション等を含む、要求例（単独又は他の指示事項含めて）に対応できる。

例えば、セキュリティーについてはチェックポイント、ロールバック、削除又はレプリケーション等のオペレーションに対して事前設定されたセキュリティー識別子を用いて制限することも出来（図７ｂ〜ｃを参照）、又は要求者との追加の交信を行う事も出来る。

これらに対する応答は、要求者、アプリケーション、又は含まれた一つ以上のデスティネーション（又はバーチュアルボリューム内のアプリケーション／デスティネーション表示子）によって異なる。リアルボリュームにリストアされ又は更に他のボリュームに分配される可能性のあるバーチュアルボリューム、サーバ又はアプリケーションは生きたデータ又は制御情報を含む可能性があり、ロールバックは特にそのような代替案に影響を受け易い。

図２０ａ〜ｂはチェックポイント削除要求に対する応答で、本応答は同一ボリュームサイズ方式に対して適用可能である（図９のステップ９０１，９０２，９１１に対応する）。本要求は対象となるバーチュアル又は“シャドー”ボリュームを指定し、コマンドタイプとしてチェックポイント削除を含み、指定したシャドーボリュームをバーチュアルボリューム管理構造から削除する。

チェックポイント削除は更に、部分的データストレージ実装に於いて、削除ボリュームセグメント（他の少なくとも一つの関連バーチュアルボリュームでは役立たない）を分配するのに利用され、これにより、ロールバックが、削除に続いて、そのような要求に使用されるのを保護される。（今回の事例では、その様なセグメントは当該チェックポイントの削除に先立って前のバーチュアルボリュームに移動する。）
図２０ａでは、ステップ２００１で、アレイマネージャは指定されたバーチュアルボリュームの前のバーチュアルボリュームは存在するかを判定する。

もしその様なバーチュアルボリュームが存在しなければ、ステップ２００７に進む。存在すれば、チェックポイント削除はステップ２００２に進み、２００３〜２００５間のステップを、対象バーチュアルボリュームで本ボリュームのチェックポイント期間（即ち次のチェックポイントに先立つデータライト期間）の間に移動したセグメントの全てについて繰り返す。

ステップ２００３にて、アレイマネージャは前のバーチュアルボリューム管理構造が削除すべきセグメントのエントリを持っているかを判定すつ。もし持っていなければ、対象バーチュアルボリュームの現セグメントのデータが読み出され（ステップ２００４）、前のバーチュアルボリュームの同一セグメントに書き込まれる（ステップ２００５）。

もし持っていれば、本チェックポイント削除処理は、次に該当するセグメントの為に、ステップ２００３に移動する。

ステップ２００６に於いて、対象バーチュアルボリュームの為のバーチュアルボリューム管理構造は削除され、対象バーチュアルボリュームの割り当ては解除される（ステップ２００７）。実質的にエラーがなかったとして、正常終了報告が要求者に返送される(図示していない)。

チェックポイント削除要求の処理を図２０ｂに可視的に示す。本実施例では、同一ボリュームサイズ方式に適用可能であり、指定バーチュアルボリュームを含むチェックポイント削除要求が受信され、本対象バーチュアルボリュームは一つ以上の、前のバーチュアルボリュームにはポピュレート(書き込み)されていない“単独にポピュレートされた”セグメントを一つ以上持っているとする。

本処理では、単独にポピュレートしたセグメントを前のバーチュアルボリュームにコピーすることによって保護し、対象バーチュアルボリュームの割り当てと関連する管理構造を解除する。

（ここでは、割り当て解除は同時に解除された情報をも削除しているとしても、本発明では余分な削除ステップを避ける事も出来、解除済み資源の情報で依然として存在している情報を、アプリケーションの要求によっては利用する事が出来る。

更に又、解除は単に、対象ボリュームを依然としてアクティブとみなされるのを防ぐのみであり、解除済みボリュームを意図せずにアクセスしてしまう事を防止するために、アプリケーションに対応した適切なメカニズムが必要であることに注意願いたい。）
本事例ではチェックポイント削除要求は現又は直前のバーチュアル又は“シャドー”ボリュームＢ２０１３とＡ２０１１を配下に持つアレイコントローラによって、成功裏に実行されるとする。シャドーボリューム２０１１は、チェックポイント削除以前（２０１１ａ）と以後（２０１１ｂ）とで二度描かれている。

ステップ２０２１にて、“バーチュアルボリュームＢ削除”要求を受信後、アレイコントローラは、バーチュアルボリュームＢがポピュレートされたセグメント０と１（データ“Ｂ”と“Ｆ”）を持っている事を単純な比較により判定し、対応するバーチュアルボリュームＡのセグメント０がポピュレート（データＡ）されていて、セグメント１がされていない事を判定する。（バーチュアルボリュームＢのセグメント１は従って、セグメント１に対する現在の削除要求に関して、単独にポピュレートされている。）
従って、図２０ｂのステップ（２）にて、バーチュアルボリュームＢのセグメント１は、バーチュアルボリュームＡのセグメント１にコピーされ、この結果、バーチュアルボリュームＡのセグメント０，１はデータ（“Ａ”，“Ｆ”）を含むようになる。次いで、ステップ（３）にて、バーチュアルボリュームＢは割り当て解除される。
「エクステント」実装方式
第二のエクステント方式でも、バーチュアルボリューム情報やその他のデータを格納する為に、フリーストレージプールより割り当てたデータスペースを利用する。

然しながら、同一ボリュームサイズ方式のシャドーボリュームとは異なって、データスペースは対応するコピーボリュームと同じとして事前割当をする訳にはいかない。

代わってエクステントは、対応するコピーボリュームセグメントのサイズに従って個別に割り当てされる。本実施例（他の実施例でも同様に適用可能）では、データスペースは、少なくとも一つ以上のバーチュアルボリュームセグメントを保存する要求に基づいて割り当てされる。

以下の実施例では、再度、ペアオペレーション（ペア生成、ペアスプリット、ペア再同期、及びペア削除を含む）、ボリュームＩ／Ｏ要求（データリード及びデータライトを含む）及びスナップショットオペレーション（チェックポイント、ロールバック、及びチェックポイント削除を含む）を含み、未サポートの要求に対しては、図９の時と同様にエラー終了する。

下記の要求に対しては、エクステント方式に於いても、同一ボリュームサイズ方式と同様に実行される；即ち、図１０のペア生成；図１２のペアスプリット；図１３のペア再同期；図１５のペア削除；図１６のデータリード;及び図１７のデータライト。

図２１に、エクステント方式のボリューム管理構造を同一ボリュームサイズ方式と比較しながら示す。

本管理構造には、ペア情報（“ペア情報”）２１０１、バーチュアルボリューム情報（“バーチュアルボリューム情報”）２１０２及びバーチュアルボリュームセグメント“リスト”としてのセグメント情報２１０３が同様に含まれる。

このようなデータ構造は各オリジナル及びコピーボリュームペアについて、全ての適用可能なバーチュアルボリューム含めて同様であり、本実装例ではペア情報２１０１も又前に示した同一ボリュームサイズ方式のものと同一である。

本事例では、然しながらバーチュアルボリューム情報（２１０２）は４エントリで、バーチュアルボリューム名２１２１、セグメントテーブルポインタ２１２２、タイムスタンプ２１２３及び次ボリュームへのリンク２１２４により構成される。

要求者のバーチュアルボリューム名には、一つ以上のユニークなバーチュアルボリューム名２１２１（バーチュアルボリュームＡ〜Ｎ）を含むことでバーチュアルボリュームを特定でき、タイムスタンプ２１２３により、同一ボリュームサイズ方式と同様に、バーチュアルボリュームの生成時刻、要求に最も近い時刻を決定することが出来る。

最後に、セグメントテーブルポインタ２１２２は本バーチュアルボリュームに対応するエクステントテーブルへのポインタであり、次のボリュームへのリンク２１２４は、次につながる、即ち本ボリュームの一つ前に生成されたバーチュアルボリュームの（存在すれば）バーチュアルボリューム情報をリンクするポインタである。

エクステントセグメント又はエクステント“リスト”（２１０３）は各コピーボリュームのバーチュアルボリューム対応に生成され、対応するバーチュアルボリュームのバーチュアルボリューム情報２１０２により指定される。

各エクステントリストは各セグメントに対応して、セグメント識別子（セグメントの順序番号）２１３１と使用するエクステント（本エクステントの内部ロケーション）を指定するエクステント識別子２１３２より構成される。エクステントはフリーストレージプールにプールされている。

図２２はエクステント方式での書き込み処理プロセスを示す。ステップ２２０１に示すようにアレイマネージャは本書き込み要求が本バーチュアルボリューム生成以来の当該セグメントへの最初の要求かを判定する。

アレイマネージャは本ボリュームのエクステントの書き込み済みフラグを精査して；“Ｙｅｓ”表示があることは本ボリュームに対する最初の書き込みではないと判断する。もし最初でない場合には、指定されたデータをコピーボリュームに書き込み（ステップ２２０２）対応するフラグを“Ｙｅｓ”にセットする（ステップ２２０３）。

反対に、本書き込みが当該ボリューム生成以来の初めての書き込みの場合は、データスペースを要求サイズに対応して割り当てる。これにより事前割当を行う必要はなくなる。

かくして、アレイコントローラは、フリーストレージプールより必要なエクステントを割り当て（ステップ２２０４）、エクステントが割り当てられたことを表示するためにそれ以前のエクステントリストを（例えばエクステントリストポインターにより）更新する（ステップ２２０５）。

以降は同一ボリュームサイズ方式と同様に進行する。即ち、アレイコントローラはコピーボリュームの対応するセグメントを現エクステントにレプリケートする（ステップ２２０６）事により保護して、指定されたデータをコピーボリュームに書き込み（ステップ２２０７）、対応する書き込み済みフラグを書き込み済みにセットする（ステップ２２０８）。

図２３ａ〜図２３ｃは、本エクステント方式に適用できる、チェックポイント要求に対する応答を示す（図９のステップ９０１〜９０２，９０９に対応する）。

本要求には、対象となるコピーボリューム名とコマンドタイプとしてチェックポイント要求が含まれる。本チェックポイント要求は、指定されたコピーボリュームに対して、エクステントタイプのバーチュアルボリュームを生成する。

図２３ａでは、ステップ２３０１にて、アレイマネージャは新しいバーチュアルボリューム構造を含むバーチュアルボリューム情報を生成し、既に存在する構造に対してリンクを張る。更に、アレイマネージャはバーチュアルボリューム名とタイムスタンプを生成し、格納（ステップ２３０２）して、エクステントリストを生成する（ステップ２３０３）。

本チェックポイント操作中に実質的エラーがなかった条件でアレイマネージャは正常終了報告を要求者に返送する。

図２３ｂと図２３ｃは、チェックポイントとデータライト要求の組み合わせに対するアレイコントローラの動作を説明する。図２３ａに示す如く、チェックポイント要求は、単に新しいバーチュアルボリュームを生成するだけで、データの書き込みは行わない。

更に簡単のために、本事例ではバーチュアルボリュームの生成とデータ保存のみを対象とし、本発明のよりよい理解のために、関連するデータ構造の例示的管理のみが考慮されている。

図２３ｂに示されるように、
（１）バーチュアルボリュームの作成即ちチェックポイント要求が受け取られる。
（２）対応するコピーボリューム２３１２を指示したデータライト要求が受け取られる。
（３）これに対して、新しいエクステントタイプのバーチュアルボリュームが割り当てられる。
（４）コピーボリュームの書き込み対象セグメントが本新しいエクステントに書き込まれる。
（５）含まれるデータがコピーボリュームに書き込まれる。

図２３ｃは図２３ｂの事例を仮定して、更に要求２３４１ａ〜ｈが、データライト要求がアドレスしているコピーボリューム２５３１を配下に持つ、アレイコントローラにより継続的に実行されると仮定する。

コピーボリューム２３５１の時刻＝０でのセグメント０〜５の値は、各々、“Ａ”〜“Ｆ”となっている。コピーボリューム２３５１ａとｂはコピーボリューム２３５１の要求２３４１ａ〜ｈ実行前と実行後の状態である。

最初に、バーチュアルボリュームは未だ存在していないから、データライト要求２３４１ａ、ｂでは、単にセグメント０，１のデータ“Ａ”，“Ｂ”を要求データ“Ｇ”，“Ｈ”で各々置き換えるのみである。

チェックポイント要求２３４１ｃは、管理構造を、エクステントタイプバーチュアルボリューム２３５２に対応して、初期化する。データライト要求２３４１ｄ（データ“Ｉ”をセグメント０に）は、コピーボリューム２３５１、セグメント０に対する最初のチェックポイント後の書き込み要求で、エクステントｅ１（２３５２）を割り当て、コピーボリューム２３５１セグメント０（今やデータ“Ｇ”を保有）を最新のエクステント（ｅ１）セグメント０に移動させる。

データライト要求に指定されているデータ（“Ｉ”）は次にコピーボリューム２３５１セグメント０に書き込まれる。コピーボリューム２３５１のセグメント２に対する、データライト要求２３４１ｅ（データ“Ｊ”をセグメント２に）も同様に、現データ“Ｃ”をエクステント（ｅ１）のセグメント２に保存し、コピーボリューム２３５１のセグメント２はデータ“Ｊ”で置き換えられる。

チェックポイント要求２３４１ｆはエクステント２３５３に対する管理構造を生成する。次のデータライト要求２３４１ｇ（“Ｋ”をセグメント０に）はコピーボリューム２３５１セグメント０に対するチェックポイント要求後の最初の書き込み要求であるため、エクステント−ｅ２ ２３５３ａを割り当て、コピーボリューム２３５１セグメント０（現在データ“Ｉ”を保有）を最新のエクステント（ｅ２）セグメント０にコピーさせる。

含まれているデータ（“Ｋ”）は次いで、コピーボリューム２３５１のセグメント０に書き込まれる。

データライト要求２３４１ｈ（データ“Ｌ”をセグメント３に）はコピーボリューム２３５１セグメント３に対するチェックポイント要求後の最初の書き込み要求であるため、エクステントｅ３を割り当て、コピーボリューム２３５１セグメント３をエクステントｅ３に書き込む。次いで含まれているデータ（“Ｌ”）はコピーボリューム２３５１セグメント３に書き込まれる。

図２４ａと図２４ｂは、ロールバック要求に対する応答を示し、本応答はエクステント方式で使用可能である（図９のステップ９０１，９０２，９１０を参照）。本要求は、対象コピーボリューム、エクステントタイプバーチュアルボリューム指定子（名前、時刻等）及びコマンドタイプとしてロールバックを指定する。

本ロールバック要求では、指定されたコピーボリュームのデータを前に保存されたバーチュアルボリュームにリストア又は“ロールバック”する。既に指摘した通り、バーチュアルボリュームをリストアする事は、典型的に同じコピーボリュームからのデータを含む。

図２４ａでは、ステップ２４０１にて、アレイマネージャはステップ２４０２〜２４０３を、指定されたコピーボリュームに対する前回のチェックポイント要求以来、本コピーボリュームからエクステントタイプのバーチュアルボリュームにコピーされた各セグメントに対して実行する。

ステップ２４０２にて、アレイマネージャは、要求に対応する最古のセグメント（指定時刻又は対応するバーチュアルボリュームＩＤ以降に最初に保存された）に対応するエクステントセグメントを決定し、本最古のセグメントを読み込む。次いで、ステップ２４０３にて、既に記したエクステントタイプ書き込みプロセス(図２２)を使用して、対応するコピーボリュームセグメントを本要求に対応する最古のセグメントで置き換える。

本ロールバック操作中に実質的なエラーが発生しなかったとして、正常終了報告が要求者に返送される（図示していない）。

図２４ｂの事例では、ロールバック要求は、本ロールバックが対象とするコピーボリューム２４１１及びエクステント２４１２―２４１６を配下に持つ、アレイコントローラによって成功裏に実行されるとする。

コピーボリューム２４１１の時刻＝０でのセグメント０〜８のデータは各々“Ａ”〜“Ｉ”とする。コピーボリューム２４１１ａ、ｂはコピーボリューム２４１１のロールバック前、後の状態を反映している。

前回のチェックポイント以降、“バーチュアルボリュームＢへのロールバック”要求をステップ２４２１で受信するまでに移動したバーチュアルボリュームＢのセグメントは、バーチュアルボリュームＢ、ＣのＳ０，バーチュアルボリュームＣのＳ１，及びバーチュアルボリュームＤのＳ２を含む。

バーチュアルボリュームＢのＳ０はバーチュアルボリュームＣのＳ０より古い為、バーチュアルボリュームＢのＳ０が選択される。次いで、Ｓ０、Ｓ１、Ｓ２への書き込みは最初の書き込みの為、アレイマネージャはその最新のバーチュアルボリュームのために三つのエクステントを割り当て、コピーボリュームのセグメントＳ０，Ｓ１、Ｓ２（後に上書きされる予定になっている）は割り当てられたエクステントに移動する。次に検出されたバーチュアルボリュームセグメントはコピーボリュームに書き込まれる。

図２５ａと図２５ｂは、エクステント方式に適用可能な、チェックポイント削除要求に対する応答を示す。（図９のステップ９０１，９０２，９１１を参照）。

本要求では、対象バーチュアルボリュームとコマンドタイプとして、チェックポイント削除を含み、指定されたバーチュアルボリュームをバーチュアルボリューム管理構造から削除する。

チェックポイント削除は更に、部分的データストレージ実装に於いて、削除ボリュームセグメント（他の少なくとも一つの関連バーチュアルボリュームでは役立たない）を分配するのに利用され、これにより、ロールバックが、削除に続いて、そのような要求に使用されるのを保護される。（今回の事例では、その様なセグメントは当該チェックポイントの削除に先立って前のバーチュアルボリュームに移動する。）
図２５ａでは、ステップ２５０１にて、アレイマネージャは指定バーチュアルボリュームより前のバーチュアルボリュームが存在するかを判定する。

もし該当バーチュアルボリュームが存在しなければ、本処理はステップ２５０８に続く；
存在すれば、ステップ２５０２に続き、ステップ２５０３〜２５０７が、対象バーチュアルボリュームのチェックポイント期間（次のチェックポイント前のデータライト期間）の間に移動した全てのセグメントに対して繰り返される。

ステップ２５０３にて、アレイマネージャは、前のバーチュアルボリュームが削除対象のセグメントを持っているかを判定する。もし持っていなければ、アレイマネージャはフリーストレージプールよりエクステントを割り当て（ステップ２５０４）、対応するエクステントリストが割り当て済みエクステントを含むようにエクステントリストを修正する（ステップ２５０５）。

更にアレイマネージャは検出されたセグメントを前のバーチュアルボリュームのエクステントに移動し（ステップ２５０６〜２５０７）、対応するバーチュアルボリューム情報を削除し（ステップ２５０８）、対象エクステントの割り当てを解除する（ステップ２５０９）。反対に、前のバーチュアルボリュームが対応セグメントを持っておれば、アレイマネージャはステップ２５０２に戻り次のセグメントについてチェックする。

本ロールバック操作中に実質的なエラーが発生しなかったとして、正常終了報告が要求者に返送される（図示していない）。

チェックポイント削除動作の図的な説明が図２５ｂに示されている。本事例では、バーチュアルボリュームを指定するチェックポイント削除要求が受信され、指定バーチュアルボリュームは一つ以上の“自ボリュームにのみポピュレート”され、前のバーチュアルボリュームには“ポピュレート”されていないセグメントを有する。

このため、少なくとも“自ボリュームにのみポピュレート”されているセグメントの少なくとも一部分を、新しいバーチュアルボリュームにコピーする事によって、保護して、指定バーチュアルボリュームと関連管理構造の割り当てを解除する。

本事例では、バーチュアルボリュームＢ２５２２が削除される。アレイマネージャは、バーチュアルボリュームＢに割り当てられているエクステントをサーチして、セグメントＳ０（データ“Ｂ”を保有），Ｓ１（データ“Ｆ” を保有）を検出する。バーチュアルボリュームＡ２５２１はデータつきのセグメントＳ０を持っているため、アレイマネージャはＳ１のためにバーチュアルボリュームＡのエクステントを割り当てて、データ（“Ｆ”）を持ったＳ１を割り当てたエクステントに移動する。

アレイマネージャは次いで、バーチュアルボリュームＢに割り当てたエクステントと関連する管理構造の割り当てを解除する。
「ログ」方式
第３のログ方式でもフリーストレージプールから割り当てられたデータスペースをバーチュアルボリューム情報やデータの記憶に使用する。然しながら、シャドーボリュームやエクステント方式と異なり、データストレージや管理はログを通して実行される。

以下の実施例では、再度、ペアオペレーション（ペア生成、ペアスプリット、ペア再同期、およびペア削除を含む）、ボリュームＩ／Ｏ要求（データリード及びデータライトを含む）及びスナップショットオペレーション（チェックポイント、ロールバック、及びチェックポイント削除を含む）を含み、未サポートの要求に対しては、図９の時と同様にエラー終了する。下記の要求に対しては、ログ方式に於いても、同一ボリュームサイズ方式および下記の図に示すのと同様に実行される。

ペアスプリット（図１２）、ペア再同期（図１３）、ペア削除（図１５）、データリード（図１６）、及びデータライト（図１７ａ）。

図２６はログタイプバーチュアルボリューム２６０１を示し、一つ以上のチェックポイント開始表示子２６１１及びログエントリ２６１２で構成される二つのエントリにより成り立っている。（一つ以上のログを使用することが出来、各ログは名前を持つことが出来る。例えば実装方法次第で、バーチュアルボリュームは一つ以上のログを持つことができ、又一つ以上のバーチュアルボリュームが一つのログを共有することができる。）
チェックポイントエントリ２６１１は、対象バーチュアルボリューム名２６１１ａ及びタイムスタンプ２６１１ｂを含むログエントリ情報を保存する。各ログエントリ、例えば２６１２は、データがレプリケートされ（更に上書きされ）たリアルボリュームに対応するコピーボリュームを指定するセグメント表示子２６１２ａとレプリケートされたデータ２６１２ｂを含む。

例えば、ログエントリ２６１２“ブロック２：Ｃ”は、対応するコピーボリューム２６０２セグメント２（ここではブロック）からコピーされた事を示し、そのデータ“Ｃ”が含まれる。

図２７では、ペア情報２７０１（“ペア情報”）とバーチュアルボリューム情報２７０２（“バーチュアルボリューム情報”）によるログ方式でのボリューム管理構造の一例を示す。本バーチュアルボリューム管理構造はログ内にチェックポイントとセグメント情報を含む（図２６での説明を参照）。

各オリジナルとコピーボリュームのペアに対しても、使用するバーチュアルボリューム含めて同様のデータ構造を採用する事が出来る。

より具体的には、本ペア情報２７０１は各オリジナル２７１１と対応するコピーボリューム２７１２の各エントリに対して、同一ボリュームサイズ方式で説明したように、外部参照２７１５と内部参照２７１６を含む。

本ペア情報２７０１は更に、ログボリューム表示（図２６で説明済み）と最初のバーチュアルボリューム情報へのポインタを含む。既に説明したようにバーチュアルボリューム情報は順番にリンクされるテーブルの並びになっている。（既に述べたように、ログボリュームのサイズは事前決定可能で、実際の実装に対応して、チェックポイントやデータライトでのデータストレージ要求を契機に割り当てる事が出来る。）
各バーチュアルボリューム情報２７０２は、バーチュアルボリューム名２７２１、タイムスタンプ２７２２及び次のボリュームへの“リンク”２７２３の３エントリにより構成される。

図２８のフローチャートは、ペア生成要求に対するアレイマネージャの応答の一例を示し、本応答はログ方式に適用可能であり、ペアを生成する（図９のステップ９０１〜９０２、９０３を参照）。本要求には、オリジナルボリューム及び対応するコピーボリュームの指定子（ＳＣＳＩのＬＵＮやその他実装に従った指定子）が含まれる。

ステップ２８０１にてペア情報が生成され、オリジナル及びコピーボリューム情報が移植され、ステップ２８０２にて、フリーストレージプールよりログが割り当てられ、本ログボリュームの指定子が本ペア情報にセットされる。最後に実質的エラーが無かったとして、正常終了報告が返送される（ステップ２８０３）。

図２９に本ログ方式で使用する書き込み処理プロセスの事例を示す。ステップ２９０１にて、アレイマネージャは、指定されたコピーボリュームに対するバーチュアルボリューム生成以降最初の当該セグメントへの書き込みか否かを判定する。

アレイマネージャは対応するログボリュームのログエントリをより詳細に精査する。もし、判定２９０１の結果が“Ｎｏ”であれば、アレイマネージャは指定されたデータをコピーボリュームに書き込み（ステップ２９０２）、本コピーボリュームのビットマップ−Ｃテーブルの書き込み済みフラグをセットする（ステップ２９０３）。

反対に判定２９０１の結果が“Ｙｅｓ”であれば、アレイマネージャは、指定セグメントのデータをログエントリに書き込み（ステップ２９０４）、指定されたデータをコピーボリュームに書き込み（ステップ２９０５）、本コピーボリュームのビットマップ−Ｃテーブルの書き込み済みフラグをセットする（ステップ２９０６）。

図３０ａ〜図３０ｂ及び図２６は、チェックポイント要求に対する応答を示し、本応答は、ログ方式に適用可能である（図９のステップ９０１，９０２，９０９を参照）。本要求は対象コピーボリュームとコマンドタイプとしてチェックポイント要求を含む。本チェックポイント要求は指定されたコピーボリュームに対してログタイプのバーチュアルボリュームを生成する。

図３０ａでは、ステップ３００１にて、アレイマネージャは新しいバーチュアルボリュームを含むバーチュアルボリューム情報を生成して、既に存在するテーブルの最後尾に対してリンクする。さらに、バーチュアルボリューム名を割り当てて保存し、タイムスタンプとして現時刻を書き込み（ステップ３００２）、対応するチェックポイントをログボリュームに書き込む（ステップ３００３）。最後に本処理中に実質的エラーが無かったとして、正常終了報告が返送される。

図３０ｂと図２６は、一つ以上のチェックポイントとデータライト要求の組み合わせに対するアレイコントローラの動作を説明する。簡単の為に、本事例はバーチュアルボリュームの生成とデータ保存に向けられるとして、本発明のよりよい理解の為に、関連管理構造の事例管理のみを対象に説明する。

図３０ｂにて、ペア生成時にログボリュームがフリーストレージプール３０１３より割り当てられる（ステップ３０２１）。本バーチュアルボリュームを生成するチェックポイント要求が受信される（ステップ３０２２）と、アレイマネージャはログボリュームのチェックポイントエントリを書き込む（ステップ３０２３）。

次いでステップ３０２４でデータライト要求が受信されると、アレイマネージャは必要によりコピーボリュームのセグメントのログボリュームにログエントリを書き込み（ステップ３０２５）、上書きされるセグメントを保護する。

最後に、アレイマネージャはコピーボリュームセグメントに要求データを上書きする（ステップ３０２６）。

図２６に戻って、本図では図３０ａに基づく動作を前提とし、更に要求２６２１ａ〜ｈが連続的に、本データライト要求が対象とするコピーボリューム２６０２を配下に持つ、アレイコントローラによって実行されるとする。コピーボリュームの時刻＝０でのセグメント０〜５は、“Ａ”〜“Ｆ”のデータを各々持つものとする。

コピーボリューム２６０２ａはコピーボリューム２６０２の要求２６２１ａ〜ｈ実行前の状態を示し、コピーボリューム２６０２ｂとログボリューム２６０１は要求２６２１ａ〜ｈ実行後の状態を示す。

データライト２６２１ａ〜ｂが（“Ｇ”を０に、“Ｈ”を１に）処理され、この時点ではバーチュアルボリュームが存在しない為、データ“Ｇ”と“Ｈ”がコピーボリューム２６０２のセグメント（ここではブロック）０と１に単純に書き込まれる。

チェックポイント要求２６２１ｃが受信され、時刻“８／１／２００２ １：００ＡＭ”で処理されると、アレイマネージャはログ２６０１を生成し、チェックポイントに対応するログ２６１１に書き込む。

次にデータライト要求２６２１ｄ（“Ｉ”を０にライト）が処理され、アレイマネージャは、本要求はコピーボリューム２６０２のセグメント０への最初の書き込みである事を判定し、コピーボリュームセグメント０（データ“Ｇ”）をログエントリに書き込んで本データを保護し、指定されたデータ（“Ｉ”）をコピーボリューム２６０２セグメント０に書き込む。

同様にアレイマネージャはデータライト要求２６２１ｅ（“Ｊ”を２にライト）を、コピーボリューム２６０２セグメント２のデータ“Ｃ”をログ２６１１に保護し、指定されたデータ“Ｊ”をコピーボリューム２６０２セグメント２に書き込む。

チェックポイント要求２６２１ｆが受信され、時刻“８／１／２００２ ３：００ＡＭ”で処理されると、アレイマネージャはログ２６０１を生成し、ログ２６０１に対応するチェックポイントエントリを書き込む。

次にデータライト要求２６２１ｇ（“Ｋ”を０にライト）が受信されると、アレイマネージャは、本書き込みはコピーボリューム２６０２セグメント０に対する最新のチェックポイント要求からの最初の書き込みであると判断し、ログエントリに書き込み、コピーボリュームセグメント０（データ“Ｉ”）を保護し、指定されたデータ（“Ｋ”）をコピーボリューム２６０２セグメント０に書き込む。

アレイマネージャは、データライト要求２６２１ｈ（“Ｌ”を０にライト）を同様に処理するが、本書き込みは二回目の書き込みで初回では無いため、アレイマネージャは単純に指定されたデータ（“Ｌ”）をコピーボリューム２６０２セグメント０に書き込む。

図３１ａと図３１ｂは、ロールバック要求に対する応答を示し、本応答はログ方式に対して適用できる（図９のステップ９０１，９０２，９１０を参照）。

本要求には、対象コピーボリューム指定子、ログタイプバーチュアルボリューム指定子（名前、時刻等）及びコマンドタイプとしてロールバックを含む。本ロールバック要求は指定コピーボリュームを前回のバーチュアルボリュームの状態にリストア又は“ロールバック”する。既に述べたように、バーチュアルボリュームをリストアすると典型的には同じコピーボリュームからのデータを含む。

図３１ａでは、ステップ３１０１にて、アレイマネージャはステップ３１０２〜３１０３を、当該コピーボリュームに対する前回のチェックポイント以降より、指定されたコピーボリュームから指定されたログタイプボリュームに移動した、各セグメントについて実行する。

ステップ３１０２にて、アレイマネージャは、本要求に対応する最古のセグメント（即ち、指定された時刻又は対応するバーチュアルボリュームＩＤ以降最初にログに保存されたセグメント）を決定し、本最古のセグメントを読み込む。

次にステップ３１０３にて、アレイマネージャは上記で述べたログタイプ書き込みプロセスを使用して、対応するコピーボリュームのセグメントを本最古のセグメントで置き換える。最後に本処理中に実質的エラーが無かったとして、正常終了報告が返送される（図示していない）。

図３１ｂでは、ロールバック操作は、本ロールバック要求が指定するコピーボリューム３１１１とログ３１１２を配下に持つアレイコントローラにより、成功裏に実行されるとする。コピーボリューム３１１１のセグメント０〜８の時刻＝０での各セグメントの内容は“Ａ”〜“Ｉ”とする。

コピーボリューム３１１１ａ、３１１１ｂはコピーボリューム３１１１のロールバック実行前、後の状態を示している。

ステップ３１２１の“バーチュアルボリュームＢへのロールバック”受信に先立って、バーチュアルボリュームは“チェックポイント”Ｂが生成されておりブロックベースセグメント０（データ“Ｊ”を含む）を含み、既に生成されているチェックポイントＣはブロック０−１（データ“Ｋ”と“Ｎ”を含む）を含み、既に生成されているチェックポイントＤはブロック０−２（データ“Ａ”と“Ｂ”と“Ｑ”を含む）を含んでいる。

アレイマネージャは、構造上の位置又は日にちを比較して、バーチュアルボリュームＢ〜Ｄが対象で、ポピュレートしているバーチュアルボリュームのセグメント０−２がコピーボリューム３１１１をリプレースすると決定する。

アレイマネージャは更に、指定されたチェックポイントＢに始まるチェックポイントブロックを比較して、ブロック０はＣＰ（チェックポイント）−Ｂの“Ｊ”が，ブロック１はＣＰ−Ｃの“Ｎ”が，ブロック２に対してはＣＰ−Ｄの“Ｑ”が最古又は“ロ−ルバック”対象セグメントでコピーボリューム３１１１にロ−ルバックされる必要があると判断する。

従って、アレイコントローラは新しいＣＰを生成して、コピーボリュームセグメント０−２を本新しいＣＰに退避し、次いでロ−ルバックセグメントをコピーボリューム３１１１の対応するセグメントにコピーする。

図３２ａと図３２ｂは、チェックポイント削除要求に対する本ログ方式に適用できる応答を示す。（図９のステップ９０１，９０２，９１１を参照）。本要求では対象のバーチュアルボリュームとコマンドタイプとしてチェックポイント削除が含まれ、指定されたバーチュアルボリュームがバーチュアルボリューム管理構造から削除される。

チェックポイント削除は更に、部分的データストレージ実装に於いて、削除ボリュームセグメント（他の少なくとも一つの関連バーチュアルボリュームでは役立たない）を分配するのに利用され、これにより、残った選択的ロールバックを保護する。

図３２ａでは、ステップ３２０１にて、アレイマネージャは指定されたバーチュアルボリューム以前に生成されたバーチュアルボリュームが存在するかを判定する。もし存在すれば、アレイマネージャは指定されたバーチュアルボリュームのログエントリを検索（ステップ３２０２）し、各“検出”されたログエントリに対して、前のバーチュアルボリュームが現在のログエントリと同じセグメント（ここでは使用する“ブロック”）のログエントリを持っているかを判定する（ステップ３２０３）。もし持っておれば、現在のログエントリを削除し（ステップ３２０４）、持っていなければ、本ログエントリを保持する。

引き続くステップ３２０５にて又は前のバーチュアルボリュームがステップ３２０１にて生成されていないと判断した場合は、アレイマネージャは指定されたバーチュアルボリューム情報を削除し、チェックポイントエントリを本ログより削除する（ステップ３２０６）。

チェックポイント削除要求の処理を図３２ｂに図的に示す。この事例では、バーチュアルボリューム−Ｂ３２２１が削除対象である。アレイマネージャはバーチュアルボリューム−Ｂ３２２１と少なくとも一つ前のバーチュアルボリューム（ここではＡ）のログエントリを検索し、バーチュアルボリューム−Ｂのポピュレートされているセグメントは前のバーチュアルボリュームにもポピュレートされているかを判定する。

本事例では下記のセグメントが検出される；バーチュアルボリューム−Ｂがブロック０（データＢを保有）を、バーチュアルボリューム−Ａもブロック−０を保有している。

バーチュアルボリューム−Ａがブロック０を保有しているため、アレイマネージャはバーチュアルボリューム−Ｂブロック０をログから削除する。（バーチュアルボリューム−Ｂが他のセグメントも持っておれば、他のセグメントについても検索して、双方にポピュレートしているセグメントの削除を繰り返す。）アレイマネージャは次いで、指定されたチェックポイントエントリ（ここではバーチュアルボリューム−Ｂの）を削除し、本バーチュアルボリューム−Ｂに対応する管理構造の割り当てを解除する。

図３３ａと図３３ｂは、バーチュアルボリュームマネージャ３３００とアレイコントローラ３３２０の各々より独立した構成例を示している。

図３３ａでは、バーチュアルボリュームマネージャ３３００は、バーチュアルボリュームエンジン３３０１、参照エンジン３３０３、アレイコントローラインターフェース３３０５、アプリケーションインターフェース３３０７、コマンドエンジン３３０９、アプリケーションエンジン３３１１、モニタ３３１３、セキュリティーエンジン３３１５、バーチュアルボリュームマップ３３１７、及びセキュリティーマップ３３１９を有する。

バーチュアルボリュームエンジン３３０１は、バーチュアルボリューム要求に対する契機を受信し、バーチュアルボリュームのコンポーネントを初期化する。参照エンジン３３０３は、各実装に於いて使用される、バーチュアルボリュームＩＤと例えばセカンダリボリューム、アプリケーションサーバ、アプリケーション、ユーザ等との参照関係を管理する。

既に述べたようにこのような参照はダウンロード可能で、参照エンジンによりアサインされ、又はバーチュアルボリューム契機の一部として提供されアレイコントローラにより保存され、バーチュアルボリュームマップ３３１９の中に全体又はその一部が保存される。

参照エンジンは更に、既に説明したように参照の抽出と決定を行う。アレイコントローラインターフェース３３０５は、バーチュアルボリュームマネージャ３３００がアレイコントローラと交信出来る様にし、例えば、バーチュアルボリュームコマンドを受信し、コマンドをアレイコントローラに発行して、データアクセスやサポート機能（キャッシング、エラー訂正等）を実行させる。

コマンドエンジン３３０７はバーチュアルボリュームコマンドを解釈し実行する（即ち、参照エンジン３３０３、アレイコントローラインターフェース３３０５、アプリケーションエンジン３３１１又はセキュリティーエンジン３３１５を起動して）。

アプリケーションエンジン３３１１は、外部コントロール又はバーチュアルボリュームマネージャ３３００からの要求による特殊アプリケーションの実行を推進する。

アプリケーションエンジン３３１１は更に、Ｊａｖａバーチュアルマシーン、アクティブ−Ｘその他の特定アプリケーションからの要求に従う為のインターフェースを提供する。そのようなアプリケーションにはデータバックアップ、ソフトウエア開発又はバッチ処理等が含まれる。

その他のコンポーネントとして、モニタエンジン３３１３はホストデバイス、アプリケーションサーバ、アレイコントローラ等を含むストレージ動作をモニタする。

セキュリティーエンジン３３１５はセキュリティーマップ３３１９と共に許可、認証等のセキュリティーオペレーションを実行する。バーチュアルボリュームマップ３３１７とセキュリティーマップ３３１９は、具体的実装に対応して、バーチュアルボリューム参照とセキュリティー情報を提供する。

アレイコントローラ３３２０（図３３ｂ）は既に説明したアレイコントロール機能を有するアレイエンジン３３２１を有する。アレイコントローラ３３２０は更にバーチュアルボリュームインターフェース３３２３とセキュリティーエンジン３３２５を有する。

バーチュアルボリュームインターフェース３３２３は、バーチュアルボリュームマネージャとのインターフェースを提供し、本バーチュアルボリュームマネージャがデータスペース共有、コマンド解釈、バーチュアルボリュームキャッシングを行い、エラー訂正等その他のサポート機能を実行できるようにする。

最後にセキュリティーエンジン３３２５はセキュリティーマップ３３２７と共に、既に図３３ａのバーチュアルボリュームマネージャ３３００の対応する要素について述べたと同様な動作を、プライマリとセカンダリボリュームのアレイデータスペースに関して実施する。

特定の実施例に基づいて本発明を説明してきたが、ある範囲の改変、及び各種の変更と置き換えは既に述べた開示の範囲に含まれる。本発明の事例のある機能は、対応する他の機能を使用する事無く、又本発明の範囲と精神から離れる事無く採用できる事に注意願いたい。

は、現行データストレージを例示するフローダイアグラムである。 は、本発明の一実施例に基づくデータレプリケーションシステム例を採用するシステムの結合を示すフローダイアグラムである。 は、本発明の一実施例に基づく図２のデータレプリケーションシステムを実現する処理システム又はその要素を説明するフローダイアグラムである。 は、本発明の一実施例に基づくデータレプリケーション処理システム例を説明するフローダイアグラムである。 は、本発明の一実施例に基づくデータレプリケーションシステムのオペレーション例を示すフローダイアグラムである。 は、本発明の一実施例に基づくコマンドの構成例を説明する。 は、本発明の一実施例に基づくアレイコントロールとバーチュアルボリュームの内部動作例を説明するフローダイアグラムである。 は、本発明の一実施例に基づくバーチュアルボリュームマップを示す。 は、本発明の一実施例に基づくリアルボリュームマップを示す。 は、本発明の一実施例に基づくより統合的なレプリケーションシステムを示すフローダイアグラムである。 は、本発明の一実施例に基づくバーチュアルボリューム操作に関連するコマンドへの応答方式を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式又はエクステント方式で使用可能なボリュームペア生成処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式でのデータレプリケーションで使用可能なボリューム管理構造例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式、エクステント方式又はログ方式で使用可能なボリュームペアスプリット処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式、エクステント方式又はログ方式で使用可能なボリューム（再）同期処理例を示すフローチャートである。 は、本発明の一実施例に基づく一時的ビットマップの形成方法を示すフローダイグラムである。 は、本発明の一実施例に基づく一時的ビットマップを使用可能なコピーボリューム（再）同期処理を示すフローダイアグラムである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式、エクステント方式又はログ方式で使用可能なボリュームペア削除処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式、エクステント方式又はログ方式で使用可能なボリューム読み取り処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式、エクステント方式又はログ方式で使用可能なボリューム書き込み処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能な書き込み処理プロセス例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なチェックポイント処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なチェックポイントとデータ書き込み処理を示すフローダイアグラムである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なチェックポイントとデータ書き込み処理の組み合わせ処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なロールバック処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なロールバック処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なチェックポイント削除処理例を示すフローチャートである。 は、本発明の一実施例に基づく同一ボリュームサイズ方式で使用可能なチェックポイント削除処理例の一例を示す。 は、本発明の一実施例に基づくエクステント方式で使用可能なデータ管理構造例を示す。 は、本発明の一実施例に基づくエクステント方式で使用可能な書き込みプロセス例を示すフローチャートである。 は、本発明の一実施例に基づくエクステント方式で使用可能なチェックポイント処理例を示すフローチャートである。 は、本発明の一実施例に基づくエクステント方式で使用可能なチェックポイントとデータ書き込み処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくエクステント方式で使用可能なチェックポイントとデータ書き込み処理の組み合わせ処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくエクステント方式で使用可能なロールバック処理例を示すフローチャートである。 は、本発明の一実施例に基づくエクステント方式で使用可能なロールバック処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくエクステント方式で使用可能なチェックポイント削除処理例を示すフローチャートである。 は、本発明の一実施例に基づくエクステント方式で使用可能なチェックポイント削除処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくログ方式で使用可能なログタイプバーチュアルボリューム及びチェックポイントと書き込み処理の組み合わせ処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくログ方式で使用可能なボリューム管理方式例を示すフローダイアグラムである。 、本発明の一実施例に基づくログ方式で使用可能なペア生成処理例を示すフローチャートである。 は、本発明の一実施例に基づくログ方式で使用可能な書き込みプロセス例を示すフローチャートである。 は、本発明の一実施例に基づくログ方式で使用可能なチェックポイント処理例を示すフローチャートである。 は、本発明の一実施例に基づくログ方式で使用可能なチェックポイントとデータ書き込み処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくログ方式で使用可能なロールバック処理例を示すフローチャートである。 は、本発明の一実施例に基づくログ方式で使用可能なロールバック処理の一例を示す。 は、本発明の一実施例に基づくログ方式で使用可能なチェックポイント削除処理例を示すフローチャートである。 は、本発明の一実施例に基づくログ方式で使用可能なチェックポイント削除処理例を示すフローダイアグラムである。 は、本発明の一実施例に基づくバーチュアルボリュームマネージャの構成を示す。 は、本発明の一実施例に基づくアレイコントローラの構成を示す。

符号の説明

２０２・・・ネットワーク（インターネット）
２０３・・・アプリケーションサーバ（オリジナル／更新）
２０４・・・その他のコンピューティングシステム
２１１・・・ディスクアレイ
２１１ａ・・・アレイコントローラ
２１１ｂ・・・バーチュアルボリューム（Ｖ．Ｖｏｌ）マネージャ
２１１ｃ・・・ストレージ媒体
２１１ｄ・・・その他のコンポーネント
２１２・・・アプリケーションサーバ１（管理）
２１３・・・ネットワーク（企業内イントラネット）
２１４ａ・・・アプリケーションサーバ２（ＯＡＳ）
２１４ｂ・・・ＯＡＳ（オリジナルアプリケーションサーバ）−ｍ
２１５ａ・・・アプリケーションサーバ３（更新）
２１５ｂ・・・ＭＡＳ（更新アプリケーションサーバ）−ｎ

Claims (24)

1. （ａ）データ管理システムを初期化し、少なくともストレージデバイスの第一のリアルデータストレージデータスペースに対応する一つ以上のバーチュアルストレージデータスペースへのアクセス管理の表示子を保存するステップと、
   （ｂ）一つ以上の第一の契機に応答して、一つ以上のデータ部分を、前記第一のリアルストレージデータスペースから対応する前記バーチュアルストレージデータスペースの一つにレプリケートするステップと、
   （ｃ）一つ以上の第二の契機に応答して、前記レプリケートされたデータ部分の少なくとも一つを、前記一つ以上のバーチュアルストレージデータスペースから第二のリアルストレージデータスペースに移動するステップと、
   （ｄ）前記データ管理システムを更新して、前記レプリケーションと移動の少なくとも一つを表示するステップと、
   から成ることを特徴とする、ストレージデバイスにより実行される方法。
2. 前記ストレージデバイスは、プライマリリアルボリューム（“プライマリボリューム”）、セカンダリリアルボリューム（“セカンダリボリューム”）及び、該プライマリボリュームのプライマリボリューム部分を該セカンダリボリュームにコピーする手段を有する多重アクセスストレージデバイスを備えることを特徴とする請求項１の方法。
3. 前記第一、第二のリアルボリュームは、前記多重アクセスストレージデバイスの同じセカンダリボリュームであることを特徴とする請求項２の方法。
4. 前記データ管理システムは、バーチュアルボリュームマネージャとボリュームデータ管理構造を備えることを特徴とする請求項１の方法。
5. 前記初期化のステップと前記一つ以上の第一の契機に応答するステップの少なくとも一つは、更に、バーチュアルストレージデータスペースを割り当て、該割り当てと前記レプリケーションの少なくとも一つに対応したタイムスタンプを保存するステップから成ることを特徴とする請求項１の方法。
6. 前記一つ以上の第二の契機に応答するステップは、更に、前記レプリケートされたデータ部分の少なくとも一つの前記移動に先立って、一つ以上の第二のデータ部分を、前記第一のリアルストレージデータスペースから一つ以上の前記バーチュアルストレージデータスペースに移動させるステップから成ることを特徴とする請求項１の方法。
7. 前記一つ以上の第一の契機に応答するステップは、
   バーチュアルストレージデータスペース生成要求に応答して、対応するバーチュアルストレージデータスペースを生成するステップと、
   引き続く一つ以上のリアルストレージデータスペースへのデータを含むデータ書き込み要求に応答して、該データを前記バーチュアルストレージデータスペースにレプリケートするステップと、
   から成ることを特徴とする請求項１の方法。
8. 前記アクセス管理は、
   前記第一のリアルストレージデータスペースと同じサイズのバーチュアルストレージデータスペース；
   レプリケートしたデータ部分を一つ以上のエクステントとして保存するバーチュアルストレージデータスペース；
   一つ以上のログ内にレプリケートしたデータ部分を保存するバーチュアルボリューム；
   の少なくとも一つを割り当てるステップを含むことを特徴とする請求項１の方法。
9. 前記一つ以上の第一の契機は、データをリアルストレージデータスペースに書き込む要求を含み、前記割り当てが該データ書き込み要求に先立って実施されることを特徴とする請求項８の方法。
10. 前記アクセス管理は、
    バーチュアルストレージデータスペースの生成時に対応するタイムスタンプを含むバーチュアルストレージデータスペース生成表示子と、
    セグメント識別子とレプリケートされたデータセグメントを含む書き込みエントリと、
    をログに格納することを含むことを特徴とする請求項８の方法。
11. 一つ以上の第一の契機に応答して、一つ以上のデータ部分を第一のリアルストレージデータスペースから対応する一つ以上のバーチュアルストレージデータスペースにレプリケートし、一つ以上の第二の契機に応答して、該レプリケートされたデータ部分の少なくとも一つを、該一つ以上のバーチュアルストレージデータスペースから第二のリアルストレージデータスペースに移動させるバーチュアルボリュームエンジンと、
    前記一つ以上のバーチュアルストレージデータスペースへのアクセスを表示するようにストレージ表示子を初期化し、前記レプリケーションと移動の少なくとも一つを表示するように該表示子を更新するデータ管理システムと、
    を含むことを特徴とするストレージデバイス。
12. プライマリボリュームとセカンダリボリューム及び、該プライマリボリュームのプライマリボリューム部分を該セカンダリボリュームにコピーする手段を有する多重アクセスストレージデバイスを備えることを特徴とする請求項１１のストレージデバイス。
13. 前記第一、第二のリアルボリュームは、前記多重アクセスストレージデバイスの同じセカンダリボリュームであることを特徴とする請求項１２のストレージデバイス。
14. 前記初期化と前記一つ以上の第一の契機に対する前記応答の少なくとも一つは、更に、バーチュアルストレージデータスペースの割り当てと、該割り当てと前記レプリケーションの少なくとも一つに対応するタイムスタンプの保存とを含むことを特徴とする請求項１１のストレージデバイス。
15. 前記一つ以上の第二の契機への前記応答は、更に、前記レプリケートされたデータ部分の少なくとも一つの前記移動に先立って、一つ以上の第二のデータ部分を前記第一のリアルストレージデータスペースから一つ以上の前記バーチュアルストレージデータスペースに移動させることを含むことを特徴とする請求項１１のストレージデバイス。
16. 前記一つ以上の第一の契機に対する前記応答は、
    バーチュアルストレージデータスペース生成要求に応答して、対応するバーチュアルストレージデータスペースを生成し、更に
    引き続く一つ以上のリアルストレージデータスペースへのデータを含むデータ書き込み要求に応答して、該データを前記バーチュアルストレージデータスペースにレプリケートする、ことを含むことを特徴とする請求項１１のストレージデバイス。
17. 前記バーチュアルボリュームエンジンは、
    前記第一のリアルストレージデータスペースと同じサイズのバーチュアルストレージデータスペース；
    レプリケートしたデータ部分を一つ以上のエクステントとして保存するバーチュアルストレージデータスペース；
    一つ以上のログ内にレプリケートしたデータ部分を保存するバーチュアルボリューム；
    の少なくとも一つとしてバーチュアルストレージデータスペースを割り当てることを特徴とする請求項１１のストレージデバイス。
18. 前記一つ以上の第一の契機は、データをリアルストレージデータスペースに書き込む要求を含み、前記バーチュアルボリュームエンジンは、該データ書き込み要求に先立って、バーチュアルストレージデータスペースを割り当てることを特徴とする請求項１７のストレージデバイス。
19. 前記データ管理システムは、
    バーチュアルストレージデータスペースの生成時に対応するタイムスタンプを含むバーチュアルストレージデータスペース生成表示子と、
    セグメント識別子とレプリケートされたデータセグメントを含む書き込みエントリと、
    をログに格納することを特徴とする請求項１７のストレージデバイス。
20. （ａ）データ管理システムを初期化し、少なくともストレージデバイスの第一のリアルデータストレージデータスペースに対応する一つ以上のバーチュアルストレージデータスペースへのアクセス管理の表示子を保存するステップと、
    （ｂ）一つ以上の第一の契機に応答して、一つ以上のデータ部分を、前記第一のリアルストレージデータスペースから対応する前記バーチュアルストレージデータスペースの一つにレプリケートするステップと、
    （ｃ）一つ以上の第二の契機に応答して、前記レプリケートされたデータ部分の少なくとも一つを、前記一つ以上のバーチュアルストレージデータスペースから第二のリアルストレージデータスペースに移動するステップと、
    （ｄ）前記データ管理システムを更新して、前記レプリケーションと移動の少なくとも一つを表示するステップと、
    から成るステップをコンピュータに実行させることを特徴とするコンピュータ保存プログラム。
21. 第一のボリュームと該第一のボリュームをレプリケートした第二のボリュームを備えるステップと、
    第一の時点で前記第二のボリュームのコピーを生成するステップと、
    少なくとも書き込み要求に応答して前記第二のボリュームを更新するステップと、
    前記コピーを利用して、前記第二のボリュームを前記第一の時点の内容に戻すステップと、
    から成ることを特徴とする、ストレージシステムにより実行される方法。
22. 第一のボリュームと該第一のボリュームをレプリケートした第二のボリュームを備えるストレージシステムにより実行される方法において、
    第三のボリュームを備えるステップと、
    第一の時点以来データ更新されていない前記第二のボリュームの第一ロケーションに、第一のデータ更新要求がなされたら、該第一ロケーションに書かれているのと同じデータを前記第三のボリュームに書き込むステップと、
    前記第一のデータ更新要求に応答して、前記第一ロケーションに更新データを書き込むステップと、
    前記第一の時点での前記第二のボリュームを前記第三のボリュームに保存されたデ―タを用いて取り戻すステップと、
    から成ることを特徴とする方法。
23. 第四のボリュームを備えるステップと、
    後の時点である第二の時点以来データ更新されていない前記第二のボリュームの第二ロケーションにデータ更新要求がなされたら、前記第二ロケーションに書かれているのと同じデータを前記第四のボリュームに書き込むステップと、
    前記第二のデータ更新要求に応答して、前記第二ロケーションへ更新データを書き込むステップと、
    前記第四のボリュームに保存されたデータを使用して、前記第二の時点での前記第二のボリュームを取り戻すステップと、
    をさらに含むことを特徴とする請求項２２の方法。
24. 前記第一ロケーションは、前記第二ロケーションと同じであることを特徴とする請求項２３の方法。
    

Images