(57)【要約】【課題】  然しながら、データベースシステムを除くと、データを任意時点に回復する手段は用意されていない。データベースシステムにしても、ジャーナルを適用するには下記の手順の為に時間が必要である。・ストレージ（例えばディスク）からジャーナルデータを読み込む。・ジャーナル内で目的のデータを特定するのに解析が必要である。・データになされた活動を再生するには、ジャーナルデータを適切なデータイメージに適用しなければならない。このことは、イメ−ジへのアクセスが通常必要でジャーナルが適用される度にデータの書き出しが必要である。【解決手段】  ストレージシステムは、複数のジャーナルエントリと一つ以上のデータボリュームの少なくとも一つのスナップショットのジャーナルを維持する。ジャーナルとスナップショットの各々に発生順に固有な順序番号を割り当てることにより、スナップショットに適用すべきジャーナルを見つける事が容易になる。ジャーナルスペースが枯渇するオーバーフロー条件を検出し、ジャーナルスペースを回復する技術が述べられる。【選択図】図１
2005018738.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションデータの保存において、ホストからの書き込み要求の受信によって保存されるアプリケーションデータに対する少なくとも最初のスナップショットを生成するステップと、前記ホスト要求による各書き込み動作に対応してジャーナルエントリを生成するステップと、各ジャーナルエントリをジャーナルデータ領域に保存し、該ジャーナルエントリのリストを集積するステップと、前記ジャーナルデータ領域内の未使用容量をモニタするステップと、前記未使用容量が第一の限界値より減少したら、該未使用容量が第二の限界値より増大するまで、前記ジャーナルデータ領域から１ないしはそれ以上のジャーナルエントリを除去することで、未使用容量を増大させるステップと、から成ることを特徴とするデータ処理方法。
【請求項２】
１ないしはそれ以上のジャーナルエントリを除去する為に、前記最初のスナップショットにその時の最古のジャーナルエントリより始めて順にジャーナルエントリを適用することにより該最初のスナップショットを更新し、前記最初のスナップショットに適用されたジャーナルエントリが、前記ジャーナルエントリリストから除去されることで前記ジャーナルデータ領域の未使用容量を増大させることを特徴とする請求項１の方法。
【請求項３】
１ないしはそれ以上のジャーナルエントリを除去する為に、その時の最古のジャーナルエントリより古くてかつ最も近いスナップショットを特定して、該スナップショットを該最古のジャーナルエントリより始めて順に１ないしはそれ以上のジャーナルエントリを適用して更新することを特徴とする請求項１の方法。
【請求項４】
１ないしはそれ以上のジャーナルエントリを除去する為に、最新のスナップショットを見つけて、該最新のスナップショットより古いジャーナルエントリを前記ジャーナルデータ領域より除去することを特徴とする請求項１の方法。
【請求項５】
前記第一の限界値と第二の限界値は異なった値であることを特徴とする請求項１の方法。
【請求項６】
各ジャーナルエントリは固定長のヘッダ部分と可変長のデータ部分から構成され、前記ジャーナルデータ領域は複数のヘッダ部分が定義される第一のストレージ領域と複数のデータ部分を保存する第二のストレージ領域で構成され、ジャーナルエントリを生成する為にジャーナルヘッダのひとつを割り当て書き込み動作に対応するデータを収容するためにデータ部に十分なスペースを割り当てることを特徴とする請求項１の方法。
【請求項７】
各ジャーナルエントリを保存する為に、ジャーナルヘッダが開始位置から始まって常に順番に割り付けられ、最終位置にジャーナルヘッダが割り当てられたら、該開始位置に戻って再度順番に割り当てられることを特徴とする請求項６の方法。
【請求項８】
ホストからの書き込み要求の受信によって保存されるアプリケーションデータの少なくとも一部分に対する少なくとも最初のスナップショットを生成するステップと、ホストからの書き込み要求動作に対応してジャーナルデータ領域に保存され、該ジャーナルデータ領域の未使用容量を消費する複数のジャーナルエントリを記録するステップと、少なくとも前記最初のスナップショットを少なくとも一つのジャーナルエントリで更新して、該少なくとも一つのジャーナルエントリが消費している記憶スペースを未使用化して前記ジャーナルデータ領域の未使用容量を増大させるステップと、から成ることを特徴とするデータの処理方法。
【請求項９】
前記更新ステップは、前記ジャーナルデータ領域の未使用容量を定期的にモニタして、該未使用容量が第一の限界値以下になったら、少なくとも前記最初のスナップショットを更新するステップを含むことを特徴とする請求項８の方法。
【請求項１０】
少なくとも前記最初のスナップショットを更新するステップを前記未使用容量が第二の限界値を超えるまでジャーナルエントリに対して繰り返すことを特徴とする請求項９の方法。
【請求項１１】
更に、前記最初のスナップショットとジャーナルエントリに各々順序番号を割り当てるステップと、目標時刻を受信するステップと、前記ジャーナルエントリと前記最初のスナップショットの各々に割り当てられた順序番号に基づいて、開始ジャーナルエントリを決定するステップと、前記最初のスナップショットに前記開始ジャーナルエントリを適用することにより前記最初のスナップショットを更新するステップと、前記最初のスナップショットに、前記開始ジャーナルエントリに引き続く前記目標時刻以前のジャーナルエントリを適用することにより、前記最初のスナップショットの追加更新を実行するステップと、を含むことを特徴とする請求項８の方法。
【請求項１２】
更に、追加のスナップショットを生成して、複数のスナップショットを集積するステップと、前記スナップショットとジャーナルエントリに各々順序番号を割り当てるステップと、目標時刻を受信するステップと、前記目標時刻に基づいて一つのスナップショットを選択するステップと、前記ジャーナルエントリと前記選択されたスナップショットの各々の順序番号に基づいて、一つの開始ジャーナルエントリを決定するステップと、前記選択されたスナップショットに前記開始ジャーナルエントリを適用することにより前記選択されたスナップショットを更新するステップと、前記開始ジャーナルエントリに引き続き、前記目標時刻以前のジャーナルエントリを前記選択されたスナップショットに適用することにより、前記選択されたスナップショットの追加更新を実行するステップと、から成ることを特徴とする請求項８の方法。
【請求項１３】
前記選択されたスナップショットは、最初のスナップショットであることを特徴とする請求項１２の方法。
【請求項１４】
前記選択されたスナップショットは前記目標時刻以前でかつ最も近いスナップショットであることを特徴とする請求項１２の方法。
【請求項１５】
ホストからの書き込み要求の受信によって保存されるアプリケーションデータの１ないしはそれ以上の部分で構成される複数のスナップショットを生成するステップと、ホストから要求される各書き込み動作に対応して生成され、ジャーナルデータ領域に保存されリスト状に集積され、該ジャーナルデータ領域の未使用容量を消費するジャーナルエントリを記録するステップと、前記ジャーナルデータ領域内の残未使用容量をモニタするステップと、前記残未使用容量が第一の限界値より少なくなったら、一つのスナップショットを選択し該選択されたスナップショットより古いジャーナルエントリを除去することにより１ないしはそれ以上のジャーナルエントリを除去するステップと、から成ることを特徴とするデータ処理方法。
【請求項１６】
前記選択されたスナップショットは、その時の最古のジャーナルエントリより少なくとも決められた時間だけ新しいスナップショットであることを特徴とする請求項１５の方法。
【請求項１７】
更に、前記スナップショットとジャーナルエントリに各々順序番号を割り当てるステップを含み、前記選択されたスナップショットは、その時の最古のジャーナルエントリの順序番号より決められた量だけ大きい順序番号を持つスナップショットであることを特徴とする請求項１５方法。
【請求項１８】
ホストからの書き込み要求の受信によって保存されるアプリケーションデータの複数のスナップショットを生成するステップと、ホストから要求される各書き込み動作に対応してジャーナルエントリを生成するステップと、各ジャーナルエントリをジャーナルデータ領域に保存し、ジャーナルエントリのリストを集積するステップと、前記ジャーナルデータ領域内の未使用容量をモニタするステップと、前記未使用容量が第一の限界値より少ないときには、その時の最古のジャーナルエントリより古くてかつ最も近いスナップショットを選択するステップと、前記最古のジャーナルエントリより始まる１ないしはそれ以上のジャーナルエントリにより前記選択したスナップショットを更新し、前記ジャーナルエントリのリストを減少させるステップと、前記未使用容量が第二の限界値を超えるまで追加のジャーナルエントリによる更新を繰り返すステップとから成ることを特徴とするデータ処理方法。
【請求項１９】
更に、前記スナップショットとジャーナルエントリに各々順序番号を割り当てるステップを含み、前記選択されたスナップショットは、該スナップショットの順序番号とその時の最古のジャーナルエントリの順序番号とに基づいて決定されることを特徴とする請求項１８の方法。
【請求項２０】
各ジャーナルエントリは、ジャーナルエントリのシーケンシャルリストで表現されるように、順番に連続してジャーナルデータ領域に保存され、ジャーナルエントリのリストが終端に達したら、最初のリスト部分に折り重ねて保存し該領域を再使用することを特徴とする請求項１８の方法。
【請求項２１】
ホストからの書き込み要求の受信によって保存されるアプリケーションデータの複数のスナップショットを生成するステップと、ホストから要求される各書き込み動作に対応して生成され、ジャーナルデータ領域に保存され、該ジャーナルデータ領域内でリスト上に集積されるジャーナルエントリを記録するステップと、複数の順序番号を生成するステップと、前記スナップショットとジャーナルエントリの各々に、前記順序番号を順に割り当てるステップと、前記ジャーナルデータ領域内の未使用容量をモニタするステップと、前記未使用容量が第一の限界値より少なくなったら、各スナップショットの順序番号をその時点の最古のジャーナルエントリの順序番号と比較して、一つのスナップショットを選択するステップと、前記選択したスナップショットを前記最古のジャーナルエントリに始まる１ないしはそれ以上のジャーナルエントリで順に更新するステップと、前記未使用容量が第二の限界値を超えるまで、追加のジャーナルエントリによる更新を繰り返すステップと、から成ることを特徴とするデータ処理方法。
【請求項２２】
ジャーナルエントリを記録するステップはスナップショット生成に先立って起動され、最初のスナップショットが生成されている期間に発生した各書き込み動作はジャーナルエントリに記録されることを特徴とする請求項２１の方法。
【請求項２３】
前記選択されたスナップショットは、前記最古のジャーナルエントリより以前のスナップショットであることを特徴とする請求項２１の方法。
【請求項２４】
前記選択されたスナップショットは、前記最古のジャーナルエントリより以前でかつ他のスナップショットに比べて前記最古のジャーナルエントリに最も近いスナップショットであることを特徴とする請求項２１の方法。
【請求項２５】
前記第一の限界値は前記第２の限界値と異なっていることを特徴とする請求項２１の方法。
【請求項２６】
データストレージシステムに送られた各書き込み動作に対応してジャーナルエントリを生成し、複数個のジャーナルエントリをバックアップストレージシステムに保存する、ジャーナル処理を起動するステップと、前記ジャーナル処理起動に引き続いて、前記データストレージシステムに保存されたデータの一部分に対して一ないしはそれ以上のスナップショットを取得するステップと、各ジャーナルエントリとスナップショットが生成される度に、同じシーケンス系列で構成される順序番号を各々順に割り当てるステップと、前記バックアップストレージシステム内の使用可能ストレージ容量に基づいて、該バックアップストレージシステム内で前記ジャーナルエントリによって消費されているスペース量を減少させる為に、一つのスナップショットに幾つかのジャーナルエントリを適用すべきかどうか決定するステップと、から成ることを特徴とするデータストレージシステムにおけるデータ処理方法。
【請求項２７】
一つのスナップショットに幾つかのジャーナルエントリを適用すると決定されたら、該ジャーナルエントリとスナップショットの各々に割り当てられた順序番号に基づいて、一つのスナップショットを選択するステップと、前記選択されたスナップショットより新しくかつ最古のジャーナルエントリを特定するステップと、前記最古のジャーナルエントリから始まる一つ以上のジャーナルエントリで前記選択されたスナップショットを更新するステップと、
から成ることを特徴とする請求項２６の方法。
【請求項２８】
ホストからの書き込み動作を受信するように構成された生産用データ領域と、前記生産用データ領域の少なくとも一部分のスナップショットを一つ以上保存するように構成されたスナップショットデータ領域と、ホストからの各書き込み動作に対応してジャーナルエントリを生成し、一つ以上のジャーナルエントリを保存するように構成されたジャーナルデータ領域と、前記生産用データ領域とスナップショットデータ領域にアクセスするステップと、前記ジャーナルデータ領域にアクセスするステップと、全体の中の幾つかのジャーナルエントリにより一つのスナップショットを更新し、幾つかのジャーナルエントリをデータ回復の為に温存するステップとを実行するコントローラと、から構成されることを特徴とするデータ処理の為のストレージシステム。
【請求項２９】
前記コントローラは更に、前記スナップショットとジャーナルエントリに各々順序番号を割り当てるステップと、目標時刻を受信するステップと、前記目標時刻に基づき一つのスナップショットを選択するステップと、前記ジャーナルエントリと選択されたスナップショットの各順序番号に基づき一つの開始ジャーナルエントリを決定するステップと、前記開始ジャーナルエントリを前記選択されたスナップショットに適用することにより前記選択されたスナップショットを更新するステップと、前記開始ジャーナルエントリより新しく、前記目標時刻より以前のジャーナルエントリを前記選択されたスナップショットに適用することにより、前記選択されたスナップショットに追加の更新を実行するステップと、を実行するように構成されていることを特徴とする請求項２８のストレージシステム。
【請求項３０】
一つ以上の書き込み動作を含む交信をホストから受信する手段と、生産用データを保存する為の第一の保存手段と、スナップショットを保存する為の第二の保存手段と、ジャーナルエントリを保存する為の第三の保存手段と、前記第二の保存手段に、生産用データの少なくとも一部の一つ以上のスナップショットを保存し、各書き込み動作に対応してジャーナルエントリを前記第三の保存手段に記録し、複数のジャーナルエントリを生成し、該第三の保存手段の未使用容量を減少させ、一つ以上のジャーナルエントリに従ってスナップショットの一つを更新して、前記第三の保存手段の未使用容量を増大させる、コントロール手段と、から構成されることを特徴とするデータ処理の為のストレージシステム。
【請求項３１】
前記更新が、周期的又は未使用容量に基づいた間隔で実施されることを特徴とする請求項３０のストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンピュータストレージに関わり、特に具体的にはデータのバックアップ及びリカバリに関連する。
【背景技術】
【０００２】
データ損失を防止する為に幾つかの方法が慣用的に実施されている。典型的には、データはシステム管理者によって定期的に（例えば毎日一回）バックアップされる。ベリタス社のNetBackup、レガート社のNetworker等の多数のシステムがデータのバックアップとリカバリの為に出回っている。もう一つの技術はボリュームシャドウィングである。本技術では、データがプライマリストレージシステムに書き込まれているときにセカンダリストレージシステムにも書き込まれ、データのミラーイメージが生成される。
【０００３】
ジャーナリングは、データベースシステムで一般に使用されているバックアップとリストアの技術である。バックアップされるデータのイメージが取得される。次いで、データが更新される度に更新ジャーナルが維持される。データのリカバリは、ジャーナルを回復対象データのイメージに適用する事によって行うことができ、任意時点のデータに回復される。オラクル等の典型的なデータベースシステムはジャーナリングを使用することができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
然しながら、データベースシステムを除くと、データを任意時点に回復する手段は用意されていない。データベースシステムにしても、ジャーナルを適用するには下記の手順の為に時間が必要である。
・ストレージ（例えばディスク）からジャーナルデータを読み込む。
・ジャーナル内で目的のデータを特定するのに解析が必要である。
・データになされた活動を再生するには、ジャーナルデータを適切なデータイメージに適用しなければならない。このことは、イメ−ジへのアクセスが通常必要でジャーナルが適用される度にデータの書き出しが必要である。
【０００５】
任意時点でのデータ回復は、次のような管理上の要求に応えなければならない。例えば、典型的な要求は、“誤って昨日１０：００ＡＭ頃にファイルを消去してしまった。そのファイルを消去直前に回復しなければならない”といったことである。
【０００６】
データがデータベースシステムに存在しなければ、この種類の要求は都合よく解決されているとは言えない。従って、損失データの回復を容易にするデータ処理方法のニーズが存在する。更にまた、データベースアプリケーション以外のユーザ環境でも、損失データの回復を容易にするデータ処理を可能とするニーズが存在する。
【課題を解決するための手段】
【０００７】
本ストレージシステムが、スナップショット動作とジャーナリングを実行して、損失データを回復させる追加のデータ処理を実行する。スナップショットとジャーナルエントリは、ユーザの生産用データボリュームとは別に保存される。新しいジャーナルエントリを作る為に、より古いジャーナルエントリは除去される。本除去は、一つ以上の古いジャーナルエントリを対応するスナップショットに適用して、本スナップショットを更新することにより達成される。その後の損失データの回復は、所定のスナップショットにアクセスして、本スナップショットにジャーナルエントリを適用して希望するデータ状態を再生することにより行われる。
【発明の効果】
【０００８】
ストレージシステムが、ユーザがアプリケーションを実行する為のデータストレージサービスを可能にする。
【発明を実施するための最良の形態】
【０００９】
図１は本発明に従うバックアップとリカバリシステムの一実施例を説明する上位階層の一般的ブロックダイアグラムである。システムが立ち上がると、スナップショットが生産用データボリューム（ＤＶＯＬ）１０１に対して取得される。ここで、“スナップショット”とは、本明細書では慣例に従い、ある指定時点に於けるデータボリュームのデータイメージのことを言う。システムに対する要求や実装等に対応して、スナップショットは、データボリュームの全体、又はその或る部分、又は複数の部分に対してなされる。本発明では、システムの正常運用の間にジャーナルエントリがホストから本データボリュームに発せられた全ての書き込み動作に対して作成される。以下に説明するように、所定のスナップショットに対して一連のジャーナルエントリを適用する事により、データは如何なる時点に対しても回復され得る。
【００１０】
図１のバックアップとリカバリシステムには、少なくとも一式のストレージシステム１００が存在する。図示されてはいないものの、本ストレージシステムには適切なプロセッサ、メモリ、及びホスト１１０とそのストレージ媒体（例えばディスク）との間の入出力動作を実行するコントロール回路が存在する事は当業者には明らかである。バックアップとリカバリのシステムには、更に少なくとも一式のホスト１１０が必要である。適切な通信パス１３０がホストとストレージシステムの間に存在する。ホスト１１０には、通常一つ以上のユーザアプリケーション（ＡＰＰ）１１２が稼動している。これらのアプリケーションは本ストレージシステム１００のデータボリューム１０１に存在するストレージ媒体に対してデータの読み書きを実行する。
【００１１】
かくして、アプリケーション１１２とデータボリューム１０１が保護されるべき対象リソースとなる。ユーザのアプリケーションで使用されるデータは、一つあるいはそれ以上のデータボリュームに保存され得るのは明らかである。本発明では、ジャーナルグループ（ＪＮＬＧ）１０２を定義する。データボリューム１０１は本ジャーナルグループの中に編成される。本発明では、ジャーナルグループは、ホスト１１０からデータボリュームへの書き込み動作のジャーナリングが保証されるデータボリュームの最小ユニットである。本関連するジャーナルは、ホストからデータボリュームへの書き込み動作を適切な順序で記録する。ジャーナリング処理によって生成されたジャーナルデータは、一つ以上のジャーナルボリューム（ＪＶＯＬ）１０６に保存される。ホスト１１０には更にリカバリマネージャ（ＲＭ）１１１が存在する。本コンポーネントは、バックアップとリカバリ動作の上位階層での協調を可能にする。本リカバリマネージャに関しては更に後に記す。
【００１２】
ストレージシステム１００はジャーナルグループを構成するデータボリュームのスナップショット（ＳＳ）１０５を生成する。例えば、スナップショット１０５は、本スナップショットが取得された時点のジャーナルグループ１０２内のデータボリューム１０１を反映している。スナップショットイメージを取得する為の慣用的方法は公知である。スナップショットデータを含むストレージシステムの中には、一つ以上のスナップショットボリューム（ＳＶＯＬ）１０７が存在する。一つのスナップショットを一つ以上のスナップショットボリュームに保存することも出来る。本発明の実施例では、ジャーナルデータとスナップショットデータを別々のストレージコンポーネントに保存しているが、これらデータを単一のストレージコンポーネントに保存しても良い事は勿論である。
【００１３】
管理テーブル（ＭＴ）１０８はジャーナルグループ１０２、スナップショット１０５、及びジャーナルボリューム１０６に関する情報を保存する。管理テーブルの更なる詳細は図３とこれに関する以下の記述で説明する。コントローラコンポーネント１４０は、書き込み動作のジャーナリングとデータボリュームのスナップショット、及びこれに対応する各異なったストレージコンポーネント１０１、１０６、１０７間のデータ移動を調整する。ここで、コントローラコンポーネントは、ストレージシステム１００内に分散する一つ以上のサブコンポーネントを物理的に含んだものの論理的表現である事に注意願いたい。
【００１４】
図２はジャーナル実装で使用されるデータを示す。書き込み要求がホスト１１０からストレージシステム１００に到達すると、これに対応してジャーナルが生成される。ジャーナルはジャーナルヘッダ２１９とジャーナルデータ２２５で構成される。ジャーナルヘッダ２１９は、対応するジャーナルデータ２２５に関する情報を保持する。ジャーナルデータ２２５は書き込み動作で用いられるデータ（書き込みデータ）を含む。この種類のジャーナルは“事後ジャーナル”とも呼ばれる。ジャーナルヘッダ２１９にはオフセット番号（ＪＨ＿ＯＦＳ）２１１が存在する。本オフセット番号はジャーナルグループ１０２内の本ジャーナルに対応するデータボリューム１０１を指定する。今回の実装では、本データボリュームは、データボリューム０、データボリューム１、データボリューム２・・・と番号付けられる。これに対応して本オフセット番号は０、１、２・・・等となる。
【００１５】
ジャーナルヘッダ２１９内のアドレス（ＪＨ＿ＡＤＲ）２１２フィールドは、（オフセット番号２１１で指定され、）データが書き込まれるデータボリューム内の開始アドレスを保存する。例えば、本アドレスはブロック番号ＬＢＡ（Logical Block Address）で表現される。ジャーナルヘッダ２１９内のデータ長（ＪＨ＿ＬＥＮ）２１３フィールドは、書き込みデータのデータ長を保存する。典型的にはこれはブロック数で表す。ジャーナルヘッダ２１９内の書き込み時刻（ＪＨ＿ＴＩＭＥ）２１４フィールドは、書き込み要求がストレージシステム１００に到着した時刻を保存する。本時刻はカレンダ日、時、分、秒、更にはミリ秒を含む。本時刻はデイスクコントローラ１４０又はホスト１１０により提供される。例えば、メインフレーム環境では複数のメインフレームホストが、タイマを共有し書き込みコマンドを発行する時刻を提供する。
【００１６】
各書き込み要求には順序番号が割り当てられ、ジャーナルヘッダ２１９のフィールド（ＪＨ＿ＳＥＱ）２１５に保存される。ジャーナルグループ１０２内では各順序番号は固有である。本順序番号は、ジャーナルエントリが生成された時に本ジャーナルエントリに対して割り当てられる。ジャーナルヘッダ２１９内のジャーナルボリューム識別子（ＪＨ＿ＪＶＯＬ）２１６は、ジャーナルデータ２２５を保存するジャーナルボリューム１０６を指定する。即ち、本識別子はジャーナルデータを保持しているジャーナルボリュームを示す。ジャーナルデータは、ジャーナルヘッダを保存するジャーナルボリュームとは異なったジャーナルボリュームに保存され得る事に注意願いたい。ジャーナルヘッダ２１９内のジャーナルデータアドレス（ＪＨ＿ＪＡＤＲ）２１７フィールドは、ジャーナルデータを保持している本ジャーナルボリューム１０６内でのジャーナルデータ２２５の開始アドレスを保存する。
【００１７】
図２は、ジャーナルボリューム１０６は、ジャーナルヘッダ領域２１０とジャーナルデータ領域２２０の二つのデータ領域で構成される事を示す。ジャーナルヘッダ領域２１０はジャーナルヘッダ２１９のみを、ジャーナルデータ領域２２０はジャーナルデータ２２５のみを保存する。各ジャーナルヘッダは固定長のデータ構造である。ジャーナルヘッダはジャーナルヘッダ領域の開始点より順番に割り当てられる。本順番はジャーナルエントリの発生順に対応して割り当てられる。後に説明するが、各時点の“最古の”ジャーナルエントリであるリスト中の最初のジャーナルエントリをポイントするデータが用意される。指定された順序番号（順序番号フィールド２１５内に存在）又は指定された書き込み時刻（時刻フィールド２１４内に存在）に対するジャーナルヘッダ２１９を検出する事が、一般的に必要になる。
【００１８】
ジャーナルヘッダ２１９とジャーナルデータ２２５はジャーナルボリューム１０６の対応領域に発生順に収容されている。かくして、ジャーナルヘッダとジャーナルデータがジャーナルボリュームに保存される順番は、割り当てられた順序番号と同じ順番である。後に説明する様に、本発明の一態様として、本ジャーナル情報２１９、２２５は各対応領域２１０，２２０内で折り返される。
【００１９】
図３は管理テーブル１０８（図１）の詳細を示す。ジャーナルヘッダ領域２１０とジャーナルデータ領域２２０を管理するには、各領域に対するポインタが必要である。既に述べたように、本管理テーブルは、ジャーナルグループ１０２についての攻勢情報及び、ジャーナルグループと本ジャーナルグループに所属するジャーナルボリューム１０６及びスナップショットイメージ１０５間の関係についての構成情報を維持する。図３に示す管理テーブル３００は管理テーブルの一例とその内容を示す。本管理テーブルは、ストレージシステム１００内の特定の一つのジャーナルグループ１０２を指定するジャーナルグループＩＤ（ＧＲＩＤ）３１０を保持する。ジャーナルグループ名（ＧＲＮＡＭＥ）３１１はジャーナルグループを指定する、人が認識できる識別子である。
【００２０】
ジャーナルグループ属性（ＧＲＡＴＴＲ）３１２がジャーナルグループ１０２に対して定義される。本実装例ではマスタ及びリストアの二つの属性が定義される。本マスタ属性はジャーナルグループがジャーナルされていること示す。本リストア属性はジャーナルグループがジャーナルによりリストアされていることを示す。ジャーナル状態（ＧＲＳＴＳ）３１５がジャーナルグループ１０２に対して定義される。これには活性及び非活性の二つの状態がある。管理テーブルには順序カウンタ（ＳＥＱ）３１３を保持するフィールドが存在する。本カウンタはジャーナルヘッダ２１９内で使用される順序番号の源となる。新しいジャーナルが生成される時に、本順序番号３１３が読み込まれ本新ジャーナルに割り当てられる。次いで本順序番号は加算され本管理テーブルに戻される。管理テーブル内の数（ＮＵＭ＿ＤＶＯＬ）３１４は、ジャーナルグループ１０２内に存在するデータボリューム１０１の数を示す。データボリュームリスト（ＤＶＯＬ＿ＬＩＳＴ）３２０はジャーナルグループ内のデータボリュームをリストする。
【００２１】
一実装例では図３に見られる通り、ＤＶＯＬ＿ＬＩＳＴはデータボリューム情報を保持するデータ構造への最初のエントリのポインタである。各データボリューム情報にはオフセット番号（ＤＶＯＬ＿ＯＦＦＳ）３２１が存在する。例えば、ジャーナルグループ１０２が三式のデータボリュームを持つなら、本オフセット値は０、１、２となる。データボリューム識別子（ＤＶＯＬ＿ＩＤ）３２２は全ストレージシステム１００内でデータボリュームを固有に識別する。ポインタ（ＤＶＯＬ＿ＮＥＸＴ）３２４は、ジャーナルグループ内で次のデータボリューム情報を保持しているデータ構造をポイントする。該当する情報が無ければナル値が与えられる。本管理テーブルは、ジャーナルグループ１０２に属するデータ（ジャーナルヘッダとジャーナルデータ）を保持する為に用いられているジャーナルボリューム数を保存する（ＮＵＭ＿ＪＶＯＬ）３３０フィールドを含んでいる。
【００２２】
図２で述べたように、ジャーナルヘッダ領域２１０は、各ジャーナルに対するジャーナルヘッダ２１９を保持する。ジャーナルデータ領域２２０についても同様である。既に述べたように、本発明の一態様として本データ領域２１０、２２０は折り返される。これにより、各データ領域のスペースは有限でもジャーナリングを続ける事が出来る。本管理テーブルは、データ領域２１０、２２０の異なった部分に対するポインタを保存する為のフィールドを持ち、折り返しを可能にする。各フィールドは次のジャーナルエントリの格納場所を指示する。フィールド（ＪＩ＿ＨＥＡＤ＿ＶＯＬ）３３１は、次の新ジャーナルヘッダ２１９を保存するジャーナルヘッダ領域２１０を有するジャーナルボリューム１０６を指定する。フィールド（ＪＩ＿ＨＥＡＤ＿ＡＤＲ）３３２は、次のジャーナルヘッダを保存するジャーナルヘッダ領域の位置についてジャーナルボリューム１０６上のアドレスを指定する。
【００２３】
フィールド（ＪＩ＿ＤＡＴＡ＿ＶＯＬ）３３５は、次のジャーナルデータを保存するジャーナルデータ領域２２０を有するジャーナルボリュームを指定する。フィールド（ＪＩ＿ＤＡＴＡ＿ＡＤＲ）３３６は、次のジャーナルデータを保存するジャーナルボリューム上のアドレスを指定する。かくして、次に書き込まれるジャーナルエントリは、“ＪＩ＿”フィールド３３１、３３２、３３５、３３６の情報で“ポイント”される。管理テーブルは更に、その時の“最古の”ジャーナルエントリを識別するフィールドを有する。
【００２４】
本情報の使用法を以下に記す。フィールド（ＪＯ＿ＨＥＡＤ＿ＶＯＬ）３３３は、最古のジャーナルヘッダ２１９を保持するジャーナルヘッダ領域２１０を保存するジャーナルボリュームを指定する。フィールド（ＪＯ＿ＨＥＡＤ＿ＡＤＲ）３３４は、ジャーナルヘッダ領域内の最古のジャーナルのジャーナルヘッダの位置のアドレスを指定する。フィールド（ＪＯ＿ＤＡＴＡ＿ＶＯＬ）３３７は、最古のジャーナルデータを保持するジャーナルデータ領域２２０を保存するジャーナルボリュームを指定する。本データを保存するジャーナルボリューム内のジャーナルデータ領域のデータアドレスは、フィールド（ＪＯ＿ＤＡＴＡ＿ＡＤＲ）３３８に保存される。管理テーブルには、特定のジャーナルグループ１０２に属するジャーナルボリュームのリスト（ＪＶＯＬ＿ＬＩＳＴ）３４０が存在する。本実装例では、ＪＶＯＬ＿ＬＩＳＴはジャーナルボリューム情報のデータ構造へのポインタである。
【００２５】
図３に示すように、各データ構造は、所定のジャーナルグループ１０２に属する特定のジャーナルボリューム１０６を指定するオフセット番号（ＪＶＯＬ＿ＯＦＦＳ）３４１を持つ。例えば、ジャーナルグループが二式のジャーナルボリューム１０６を持っていたら、各ジャーナルボリュームは０又は１で指定される。ジャーナルボリューム識別子（ＪＶＯＬ＿ＩＤ）３４２は、ストレージシステム１００内でのジャーナルボリュームを固有に指定する。最後にポインタ（ＪＶＯＬ＿ＮＥＸＴ）３４４は、本ジャーナルグループ内の次のジャーナルボリュームに関係する次のデータ構造のエントリをポイントする。存在しなければナル（ＮＵＬＬ）値が指定される。管理テーブルには、ジャーナルグループ１０２に属するスナップショットイメージ１０５のリスト（ＳＳ＿ＬＩＳＴ）３５０が存在する。
【００２６】
本実装例では図３に示すように、ＳＳ＿ＬＩＳＴはスナップショット情報のデータ構造へのポインタである。各スナップショット情報のデータ構造には、スナップショットが取得された時の順序番号（ＳＳ＿ＳＥＱ）３５１が与えられる。既に述べたように本番号は順序カウンタ３１３よりもたらされる。時刻値（ＳＳ＿ＴＩＭＥ）３５２は本スナップショットが取得された時の時刻を示す。状態（ＳＳ＿ＳＴＳ）３５８は各スナップショットの状態（有効及び無効）の値を示す。ポインタ（ＳＳ＿ＮＥＸＴ）３５３は次のスナップショット情報のデータ構造をポイントする。存在しなければナル（ＮＵＬＬ）値が示される。各スナップショット情報のデータ構造は、更にスナップショットイメージ１０５を保存するスナップショットボリューム１０７（図１）のリストを有する。
【００２７】
図３で分かるように、スナップショットボリューム情報のデータ構造へのポインタ（ＳＶＯＬ＿ＬＩＳＴ）３５４が、各スナップショット情報のデータ構造に存在する。各スナップショットボリューム情報のデータ構造には、スナップショットイメージの少なくとも一部を含む各スナップショットボリュームを指定するオフセット番号（ＳＶＯＬ＿ＯＦＦＳ）３５５が存在する。一式のスナップショットイメージはセグメント化又は分割されて、一つ以上のスナップショットボリュームに保存することが出来る。本実装例では、オフセット値はスナップショットイメージの一部分（セグメント又は分割）を含むｉ番目のスナップショットボリュームを指定する。ｉ番目のスナップショットイメージのセグメントは、ｉ番目のスナップショットボリュームに保存しても良い。各スナップショットボリューム情報のデータ構造には更に、ストレージシステム１００内でのスナップショットボリュームを固有に指定するスナップショットボリューム識別子（ＳＶＯＬ＿ＩＤ）３５６が存在する。ポインタ（ＳＶＯＬ＿ＮＥＸＴ）３５７は、指定されたスナップショットイメージに対する次のスナップショットボリューム情報のデータ構造をポイントする。
【００２８】
図４は本発明の実装例に従う、リカバリマネージャ１１１とストレージシステム１００がバックアッププロセスを開始するプロセスを説明するフローチャートである。スナップショットが取得されていても、ジャーナルエントリが記録されていない書き込み動作は、データ回復処理中にデータは損失するか破損する。従って、本発明では最初のスナップショット取得前にジャーナリングプロセスを起動する。これを行うことにより、スナップショット取得後に発生する全ての書き込み動作がジャーナルされることが保障される。スナップショット完成前に記録されたジャーナルエントリは全て無視してもよい事を注記する。更に本発明に従えば、単一系列の順序番号（ＳＥＱ）３１３が各スナップショットとジャーナルエントリに、生成される毎に割り当てられる。各スナップショットとジャーナルエントリに同一系列の順序番号を割り当てる目的は以下に述べる。
【００２９】
図４に戻って、リカバリマネージャ１１１は、ジャーナルグループ（ＪＮＬＧ）１０２が定義済でなければ、これをステップ４１０で定義する。
【００３０】
図１で示した通り、本定義では、ジャーナルの対象となる一台以上のデータボリューム（ＤＶＯＬ）１０１を指定し、ジャーナル関連情報を保存する一台以上のジャーナルボリューム（ＪＶＯＬ）１０６を指定する。リカバリマネージャは、目的を達成する為に、ストレージシステム１００との間で適切な一連のやり取りを実行する。
【００３１】
ステップ４１５にて、ストレージシステムは図３のテーブル３００の詳細図に示される多様な情報を収容する管理テーブル１０８（図１）を生成する。とりわけ、本プロセスでは、ジャーナルグループ１０２を構成するジャーナルボリュームをリストするＪＶＯＬ＿ＬＩＳＴ３４０の初期化を行う。同様に、データボリュームのリストＤＶＯＬ＿ＬＩＳＴ３２０を生成する。次のジャーナルエントリ（又はテーブルが最初に生成される場合には最初のジャーナルエントリ）を指定するフィールドを初期化する。かくして、ＪＩ＿ＨＥＡＤ＿ＶＯＬ３３１はジャーナルボリュームリスト内の最初を指定し、ＪＩ＿ＨＥＡＤ＿ＡＤＲ３３２は、最初のジャーナルボリュームに存在するジャーナルヘッダ領域２１０の最初のエントリをポイントする。
【００３２】
同様に、ＪＩ＿ＤＡＴＡ＿ＶＯＬ３３５は、ジャーナルボリュームリスト内の最初を指定し、ＪＩ＿ＤＡＴＡ＿ＡＤＲ３３６は、最初のジャーナルボリュームに存在するジャーナルデータ領域２２０の開始点をポイントする。ヘッダ領域２１０とデータ領域２２０は異なるジャーナルボリュームに収容でき、ＪＩ＿ＤＡＴＡ＿ＶＯＬは最初のジャーナルヘッダボリュームとは異なったジャーナルボリュームを指定することがあり得ることに注意していただきたい。ステップ４２０にて、リカバリマネージャ１１１はジャーナリングプロセスを起動する。ジャーナリングを実行する為に、ストレージシステム１００に対して適切な交信がなされる。ステップ４２５にて、ストレージシステムはホスト１１０からの今後の各書き込み動作に対して、ジャーナルエントリ（これは、“事後ジャーナル”とも呼ばれる）を作成する。
【００３３】
図３を参照するに、ジャーナルエントリを作成するには、とりわけ、次のジャーナルエントリを保存するロケーションを指定することが必要になる。フィールドＪＩ＿ＨＥＡＤ＿ＶＯＬ３３１とＪＩ＿ＨＥＡＤ＿ＡＤＲ３３２は各々、次のジャーナルヘッダ２１９のジャーナルボリューム１０６とジャーナルヘッダ領域２１０内での位置を指定する。管理テーブルからの順序カウンタ（ＳＥＱ）３１３は、次のヘッダのＪＨ＿ＳＥＱ２１５フィールドにコピーされ割り当てられる。本順序カウンタは次いで加算され、管理テーブルに戻される。勿論、本順序カウンタは最初に加算し、ついでＪＨ＿ＳＥＱにコピーし、最後に管理テーブルに戻してもよい。
【００３４】
管理テーブルのＪＩ＿ＤＡＴＡ＿ＶＯＬ３３５とＪＩ＿ＤＡＴＡ＿ＡＤＲ３３６フィールドは、各々書き込み動作に付随するデータを保存する、ジャーナルボリュームとジャーナルデータ領域２２０の開始点を指定する。ＪＩ＿ＤＡＴＡ＿ＶＯＬとＪＩ＿ＤＡＴＡ＿ＡＤＲは各々、ジャーナルヘッダのＪＨ＿ＪＶＯＬ２１６とＪＨ＿ＡＤＲ２１２にコピーされ、この結果ジャーナルヘッダがジャーナルデータに対応するポインタを得る事になる。書き込み動作のデータは保存される。
【００３５】
ＪＩ＿ＨＥＡＤ＿ＶＯＬ３３１とＪＩ＿ＨＥＡＤ＿ＡＤＲ３３２フィールドは、次のジャーナルエントリに対する次のジャーナルヘッダ２１９をポイントするべく更新される。このことはジャーナルヘッダ領域２１０内の次に続くジャーナルヘッダエントリを用いる結果となる。同様に、ＪＩ＿ＤＡＴＡ＿ＶＯＬフィールドとＪＩ＿ＤＡＴＡ＿ＡＤＲフィールドは、各々次のジャーナルエントリに対するジャーナルデータボリュームとジャーナルデータ領域での開始点を反映すべく更新される。このことは、ジャーナルデータ領域における次の保存可能位置に進めることを意味する。従ってこれらのフィールドは、ジャーナルエントリのリストをポイントすると見なすことが出来る。リストのジャーナルエントリは、ジャーナルヘッダ領域２１０内のジャーナルヘッダ２１９のシーケンシャル構成によって、互いにリンクすることが出来る。
【００３６】
ジャーナルヘッダ領域２１０の最終点に達したら、次のジャーナルエントリに対するジャーナルヘッダ２１９は、ジャーナルヘッダ領域の開始点に戻される。ジャーナルデータ２２５に対しても同様である。以前のジャーナルエントリに上書きする事を防止する為に、本発明はジャーナルボリューム１０６のエントリを開放する処置を実施する。本件については、以下に述べる。ジャーナル起動後の最初のジャーナルエントリに対しては、ＪＯ＿ＨＥＡＤ＿ＶＯＬ３３３、ＪＯ＿ＨＥＡＤ＿ＡＤＲ３３４、ＪＯ＿ＤＡＴＡ＿ＶＯＬ３３７、及びＪＯ＿ＤＡＴＡ＿ＡＤＲ３３８の各フィールドは、各対応する“ＪＩ＿”フィールドの初期値がセットされる。後に説明するように、“ＪＯ＿”フィールドはその時の最古のジャーナルエントリをポイントする。かくして、新しいジャーナルエントリが作成されると、“ＪＩ＿”フィールドは前進するが“ＪＯ＿”フィールドは前進しない。“ＪＯ＿”フィールドの更新については以下で説明する。
【００３７】
図４のフローチャートに戻って、ジャーナリングプロセスが起動している場合には、ホストからのすべての書き込み動作はジャーナルされる。そこでステップ４３０に於いて、リカバリマネージャ１１１はデータボリューム１０１のスナップショットの取得を起動する。ストレージシステム１００は、リカバリマネージャからスナップショットを取得する指示を受け取る。ステップ４３５にて、ストレージシステムはデータボリュームのスナップショットを取得するプロセスを開始する。この結果特に、管理テーブル（図３）上のＳＳ＿ＬＩＳＴ３５０にアクセスすることになる。次のスナップショットを扱う為に必要な量のメモリがフィールド３５１−３５４に割り当てられる。順序カウンタ（ＳＥＱ）３１３は、上記のＪＨ＿ＳＥＱ２１５で説明したように、ＳＳ＿ＳＥＱ３５１フィールドにコピーされ、加算される。
【００３８】
かくて、順序番号はＳＥＱ３１３より生成され、順序カウンタ中の各番号はジャーナルエントリ又はスナップショットエントリのいずれかに処理中を通して割り当てられる。スナップショットは一台（以上）のスナップショットボリューム（ＳＶＯＬ）１０７に保存される。フィールド３５５−３５７に必要な量のメモリが割り当てられる。スナップショットを保存する為のＳＶＯＬに関連する情報がフィールド３５５−３５７に保存される。スナップショット保存に追加のボリュームが必要なら、フィールド３５５−３５７に追加のメモリが割り当てられる。
【００３９】
図５は、ジャーナルエントリとスナップショットの関係を示す。スナップショット５２０は、ジャーナルグループ１０２に属するデータボリューム１０１の最初のスナップショットイメージを表す。順序番号ＳＥＱ０とＳＥＱ１のジャーナルエントリ（５１０）が作られ、これらは二つの書き込み動作に対するジャーナルエントリを表していることに注意していただきたい。これらのエントリは、ジャーナリングはスナップショットが取得（ステップ４２０）されるに先立って起動されている事を示す。かくして、順序番号ＳＥＱ２に対応する時点で、リカバリマネージャ１１１はスナップショット取得を開始し、更にジャーナル採取は既に起動されているため、スナップショット取得開始後の全ての書き込み動作は、ジャーナルされている。かくして、順序番号ＳＥＱ３以上の書き込み動作は、全てジャーナルされている。見て分かる通り、順序番号ＳＥＱ０とＳＥＱ１のジャーナルエントリは破棄するか無視しなければならない。
【００４０】
データのリカバリでは、指定時点のデータボリューム１０１の少なくとも一部分のデータ状態に回復する事が通常要求される。このことは必要量のジャーナルエントリを本ジャーナルエントリより以前に取得されたスナップショットに適用する事で一般的に実行される。本実施例で開示する方法では、順序番号ＳＥＱ３１３は、ジャーナルエントリ又はスナップショットに割り当てられる度に、加算される。従って、所定のスナップショットに対して適用可能なジャーナルエントリを特定することは単純である。即ち、（ＪＨ＿ＳＥＱ）２１５の順序番号が本スナップショットの順序番号（ＳＳ＿ＳＥＱ）３５１より大きなジャーナルエントリを適用すればよい。
【００４１】
管理者は或る時点、例えば、データボリュームのデータが失われたか又は破損した時（“目標時刻”）以前の時刻を、データ回復の時点に指定することが出来る。目標時刻以前の時刻が見つかるまで、各スナップショットのＳＳ＿ＴＩＭＥ３５２の時刻フィールドが検索される。次に、その時の“最古の”ジャーナルヘッダから始めて、ジャーナルヘッダ領域２１０内のジャーナルヘッダ２１９が検索される。本最古のジャーナルヘッダは、管理テーブルの“ＪＯ＿”フィールド３３３、３３４、３３７及び３３８によって指定されている。ジャーナルヘッダは、順序番号ＪＨ＿ＳＥＱ２１５が対象スナップショットの順序番号ＳＳ＿ＳＥＱ３５１より大きい最初のヘッダを目指して領域２１０内を順番に検索される。選択されたスナップショットには、一時には一ずつ、各ジャーナルエントリを順次適用する事により、順次加算更新され一連の書き込み動作が再現される。本処理は、ジャーナルエントリのＪＨ＿ＴＩＭＥ２１４フィールドの値が目標時刻より以前である限り継続される。本更新作業は時刻フィールド２１４の値が目標時刻を過ぎると停止する。
【００４２】
本発明の一実施例では、単一のスナップショットが取得される。本スナップショットに引き続く全てのジャーナルエントリは、所定時刻におけるデータ状態を再構築する為の適用対象となる。本発明の他の実施例として、複数スナップショットが取得される。本件は図５Ａに示され、複数スナップショット５２０’が取得される。本発明では、各スナップショットとジャーナルエントリは各々が記録される順に順序番号が割り当てられる。各スナップショット５２０’の間には通常、多数のジャーナルエントリ５１０が存在する事に注意願いたい。複数スナップショットを使用する事により、データ回復の時間を短縮する事が出来る。目標回復時刻に対して最寄りのスナップショットが選択される。本スナップショットに続くジャーナルエントリが所望のデータ回復の為に適用可能である。
【００４３】
図６は本発明のもう一つの態様を説明する。本発明によれば、ジャーナルエントリはホストからの書き込み動作の度に作成され、これはかなり大量のジャーナルエントリ数になる。ジャーナル採取が繰り返されると時間の経過と共に、ジャーナルグループ１０２に対してリカバリマネージャ１１１が定義した各ジャーナルボリューム１０６は、何時かは満杯になってしまう。このままでは、この時点でこれ以上のジャーナルエントリは作成できなくなり、結果として、後続する書き込み動作はジャーナルされず、ジャーナルボリュームが満杯になった以降のデータ状態の回復は不可能になってしまう。
【００４４】
図６は、ストレージシステム１００が、“オーバーフロー”条件の検出を契機に、相応しいスナップショットへジャーナルエントリを適用する状況を示している。ここで、“オーバーフロー”は、ジャーナルボリュームでの未使用容量が設定された限界値を下回った場合に発生したと見做される。オーバーフロー限界値の設定には多様な基準があることに注意願いたい。一つの分かりやすい限界値は、ジャーナルグループに割り当てられたジャーナルボリュームの合計ストレージ容量を基準にするものである。未使用容量が全ストレージ容量のある割合、例えば１０％、に達したら、オーバーフローとする。他の限界値としては各ジャーナルボリューム対応に決めても良い。本発明の一態様では、ジャーナルボリューム内の未使用容量は定期的にモニタされる。反対に未使用容量は非定期的にモニタしても良い。例えば、モニタ間隔はランダムであっても良い。更に他の方法として、例えば、モニタ間隔は未使用容量の関数として変動させても良い。或いは又、ジャーナル採取を契機にモニタしても良い。
【００４５】
図７は、ストレージシステム１００内でオーバーフロー条件の検出の為に行うプロセスを説明する。かくして、ステップ７１０にて、ストレージシステムはジャーナルボリューム１０６の全未使用容量を定期的に、例えば１０秒毎にチェックする。未使用容量は、管理テーブル３００内のポインタ（ＪＩ＿ＨＥＡＤ＿ＶＯＬ３３１、ＪＩ＿ＨＥＡＤ＿ＡＤＲ３３２等）がジャーナルボリュームで消費しているストレージの現在の状態を維持しているので、容易に計算可能である。未使用容量が限界値以上であれば、次の周期を待って未使用容量のチェックを繰り返すのみである。未使用容量が前もって決定した限界値以下になったら、ステップ７２０にて、幾つかの、特に最古のジャーナルエントリがスナップショットに適用され、スナップショットを更新する。
【００４６】
図３を参照するに、本最古のジャーナルエントリのジャーナルヘッダ２１９は、ＪＯ＿ＨＥＡＤ＿ＶＯＬフィールド３３３とＪＯ＿ＨＥＡＤ＿ＡＤＲフィールド３３４で指定される。これらのフィールドは、本最古のジャーナルエントリを保存するジャーナルボリュームとジャーナルヘッダ領域２１０に対する本ジャーナルボリューム内の位置を指定する。同様に、本最古のジャーナルエントリのジャーナルデータは、ＪＯ＿ＤＡＴＡ＿ＶＯＬフィールド３３７とＪＯ＿ＤＡＴＡ＿ＡＤＲフィールド３３８で指定される。これらのフィールドで指定されるジャーナルエントリはスナップショットに適用される。ここで選択されるスナップショットは、ジャーナルエントリより以前でかつ本ジャーナルエントリに順序番号が最も近いスナップショットである。
【００４７】
かくして、本実装例では、順序番号が加算される度に、ジャーナルエントリに対して最も近くてより小さい（時刻的にはより早い）順序番号を持つスナップショットが選択される。ジャーナルエントリがスナップショットに適用されてスナップショットが更新されると、適用済のジャーナルエントリは開放される。このことは単に、ＪＯ＿ＨＥＡＤ＿ＶＯＬフィールド３３３、ＪＯ＿ＨＥＡＤ＿ＡＤＲフィールド３３４、ＪＯ＿ＤＡＴＡ＿ＶＯＬフィールド３３７、及びＪＯ＿ＤＡＴＡ＿ＡＤＲフィールド３３８を次のジャーナルエントリをポイントすべく更新するのみである。順序番号は最終的には折り返され０から再度スタートすることは当業者には明らかである。順序番号を比較する時に、本再スタートを把握するための相応しいメカニズムも当業者の技術範囲である。
【００４８】
図７に戻って、スナップショットにジャーナルエントリを適用してスナップショットを更新した後には、この結果として適用済ジャーナルエントリが開放され（ステップ７３０）て、ジャーナルボリューム内の未使用容量が増大した事をチェックする。本未使用容量は、更にステップ７３０にて限界値と比較される。この場合第二の異なった限界値が使用できる。例えば、本プロセスを終了するには開始する時よりより高いレベルの未使用容量を必要としても良い。
【００４９】
これにより本プロセスが過剰に使用される事を防止する事が可能になるが、一旦開始されたら、第二の高いレベルの限界値により合理的な範囲で出来るだけ多くの未使用容量を確保して回復を促進する。これらの限界値を決めるには管理者の時間をかけた経験が要求される事に注意願いたい。かくして、ステップ７３０により未使用容量が第二の限界値を超え停止条件に達したら、本プロセスは終了する。そうでなければ、ステップ７２０に戻り次に古いジャーナルエントリに対して繰り返される。ステップ７３０と７２０が、未使用容量がステップ７３０にて本限界値に達するまで繰り返される。
【００５０】
図７Ａは、図７のステップ７２０に対する代替の実施例のサブステップを示す。ステップ７２０では、ジャーナルエントリを、本ジャーナルエントリより以前の最新のスナップショットに適用する事によって、開放する。然しながら、複数のスナップショットが使用可能なら、スナップショットを更新する為にジャーナルエントリを適用するプロセスで消費する時間を省略する事が出来る。
【００５１】
図７Ａは、図７のステップ７２０に対する代替ステップ７２０’の詳細を示す。ステップ７２１にて、本最古のジャーナルエントリより新しいスナップショットが存在するかどうかを判定する。本判定は、順序番号が本最古のジャーナルエントリより大きい最初のスナップショットを検索する事により、可能である。代わって本判定は、その時の最古のジャーナルエントリより所定時間（例えば少なくとも１時間）だけ新しいスナップショットを見つけてこれを基準にしても良い。更に又他の方法として、スナップショットとジャーナルエントリの時間差に代わって、順序番号を用いても良い。例えば、最古のジャーナルエントリの順序番号より、Ｎ分だけ進んだ順序番号を持つスナップショットを選択しても良い。
【００５２】
該当するスナップショットがステップ７２１で見つかったら、これより古いジャーナルエントリはスナップショットに適用しないまま除去しても良い。かくして、ステップ７２２にて、“ＪＯ＿”フィールド（ＪＯ＿ＨＥＡＤ＿ＶＯＬ３３３，ＪＯ＿ＨＥＡＤ＿ＡＤＲ３３４，ＪＯ＿ＤＡＴＡ＿ＶＯＬ３３７，及びＪＯ＿ＤＡＴＡ＿ＡＤＲ３３８）は、選択されたスナップショットより新しい最初のジャーナルエントリをポイントする値に単純に書き換えられる。該当するスナップショットが見つからなかったら、ステップ７２０で議論したように、ステップ７２３にて、残った最古のジャーナルエントリがこれより古いスナップショットに適用される。
【００５３】
ステップ７２１に対する更なる代替案として、単純に最も新しいスナップショットを選択する案がある。本スナップショットより小さな順序番号を持つジャーナルエントリは開放可能である。このことはさらに単純に、最新のスナップショットより大きな順序番号を持つ最初のジャーナルエントリをポイントするように、“ＪＯ＿”フィールドを更新するのみである。ここで、本発明の一態様はデータを希望する時点の状態に回復する事が出来る事を思い出してほしい。このことは、生成されたジャーナルエントリを必要範囲は保存して、本ジャーナルエントリを所定のスナップショットに適用して、書き込み動作を再現する事により達成される。この最後の実施例は大量のジャーナルエントリを除去する事が出来るが、これによってデータ状態が回復できる時間帯を制限する結果になってしまう。然しながら、構成によっては、大量のジャーナルエントリを除去する事は与えられた動作環境にとっては望ましい事もあり得る。
【００５４】
これまで述べたステップは全体として、コントローラ１４０（例えばデイスクコントローラ）で実現される事に注意願いたい。このことは、特定の実装次第で純粋のソフトウエア、カスタムロジック、ソフトウエアとハードウエアの相応しい組合せで可能である。もっと一般的に言えば、前記の実現は典型的に、ソフトウエアとハードウエアの組合せでなされると言ってよい。当業者には、最終的に採用する技術はシステムコスト、システム性能、慣用的ソフトウエアとハードウエア、動作環境その他を含めた要素等によって決まる事、しかしこれらに限定、制約されるものでない事を容易に理解してもらえるであろう。これまで述べられ意図された実施例は、当業者により過大な実験を行う事無く具体的実装に直ちに適用可能である。
【図面の簡単な説明】
【００５５】
本発明の態様、効果と新規な機能が、本発明の以下の付随図面と共になされる説明によって明らかになる。
【図１】は、本発明の一実施例を説明する上位階層の一般的ブロックダイアグラムである。
【図２】は、本発明に従うジャーナルエントリを保存するデータ構造の一実施例を一般的に説明する。
【図３】は、本発明に従うスナップショットボリュームとジャーナルエントリボリュームを管理するためのデータ構造の一実施例を一般的に説明する。
【図４】は、リカバリマネージャとストレージシステム内のコントローラとの間での処理を説明する上位階層のフローチャートである。
【図５】は、一つのスナップショットと複数のジャーナルエントリ間の関係を説明する。
【図５Ａ】は、複数のスナップショットと複数のジャーナルエントリ間の関係を説明する。
【図６】は、オーバーフロー状態が発生した場合のデータフローを説明する上位階層の図である。
【図７】は、オーバーフロー状態を処理する為のストレージシステム内のコントローラ動作を説明する上位階層のフローチャートである。
【図７Ａ】は、図７で示す処理ステップの別案を示す。
【符号の説明】
【００５６】
１００・・・ストレージシステム
１０１・・・データボリューム（ＤＶＯＬ）
１０５・・・スナップショット（ＳＳ）
１０６・・・ジャーナルボリューム（ＪＶＯＬ）
１０７・・・スナップショットボリューム（ＳＶＯＬ）
１０８・・・管理テーブル（ＭＴ）
１０２・・・ジャーナルグループ（ＪＮＬＧ）
１１０・・・ホスト
１１１・・・リカバリマネージャ（ＲＭ）
１１２・・・アプリケーション（ＡＰＰ）
１４０・・・コントローラ
【図１】
2005018738.tif 000003
【図２】
2005018738.tif 000004
【図３】
2005018738.tif 000005
【図４】
2005018738.tif 000006
【図５】
2005018738.tif 000007
【図５Ａ】
2005018738.tif 000008
【図６】
2005018738.tif 000009
【図７】
2005018738.tif 000010
【図７Ａ】
2005018738.tif 000011
【外国語明細書】
2005018738.tif 000012
2005018738.tif 000013
2005018738.tif 000014
2005018738.tif 000015
2005018738.tif 000016
2005018738.tif 000017
2005018738.tif 000018
2005018738.tif 000019
2005018738.tif 000020
2005018738.tif 000021
2005018738.tif 000022
2005018738.tif 000023
2005018738.tif 000024
2005018738.tif 000025
2005018738.tif 000026
2005018738.tif 000027
2005018738.tif 000028
2005018738.tif 000029
2005018738.tif 000030
2005018738.tif 000031
2005018738.tif 000032
2005018738.tif 000033
2005018738.tif 000034
【図１】
2005018738.tif 000035
【図２】
2005018738.tif 000036
【図３】
2005018738.tif 000037
【図４】
2005018738.tif 000038
【図５】
2005018738.tif 000039
【図５Ａ】
2005018738.tif 000040
【図６】
2005018738.tif 000041
【図７】
2005018738.tif 000042
【図７Ａ】
2005018738.tif 000043