(57)【要約】【課題】ストレージ・システムにおいて、階層管理されている論理ボリュームのスナップショットの作成及び管理をおこなう。【解決手段】本発明の方法は、論理ボリュームのスナップショットの作成指示を受けて、スナップショットを管理するための管理テーブルを準備し、論理ボリュームの保管状態を検出し、論理ボリュームが、第１レベルのストレージからより下位層の２レベルのストレージへマイグレーションされている場合、論理ボリュームを第２レベルのストレージから第１レベルのストレージへリコールすることなく、管理テーブルを更新することを含み、その更新後の管理テーブルは、スナップショットの作成が必要であること、論理ボリュームはマイグレーションされていること、および第２レベルのストレージにおける論理ボリュームの保管先を示すメタデータを含む。【選択図】図４
2015079409.tif 000002
【特許請求の範囲】
【請求項１】
ストレージ・システムにおいて、階層管理されている論理ボリュームのスナップショットの作成及び管理をおこなう方法であって、前記ストレージ・システムは、第１レベルのストレージと、前記第１レベルよりも下位の第２レベルのストレージとを含み、
論理ボリュームのスナップショットの作成指示を受け取るステップと、
前記スナップショットを管理するための管理テーブルを準備するステップであって、前記管理テーブルは、前記スナップショットの作成の状態を示す第１のメタデータと、前記論理ボリュームの保管状態を示す第２のメタデータと、前記論理ボリュームの保管先を示す第３のメタデータとを含む、前記準備するステップと、
前記論理ボリュームの保管状態を検出するステップと、
前記論理ボリュームが、前記第１レベルのストレージから前記第２レベルのストレージへマイグレーションされている場合、前記論理ボリュームを前記第２レベルのストレージから前記第１レベルのストレージへリコールすることなく、前記管理テーブルを更新するステップであって、前記第１のメタデータは前記スナップショットの作成が必要であることを示し、前記第２のメタデータは前記マイグレーションされていることを示し、前記第３のメタデータは前記第２レベルのストレージにおける前記論理ボリュームの保管先を示す、前記更新するステップと、を含む方法。
【請求項２】
前記論理ボリュームまたは前記スナップショットへのアクセスが要求された場合、
前記論理ボリュームの前記リコールを実行するステップと、
前記第１レベルのストレージにリコールされた前記論理ボリュームから前記スナップショットを作成するステップと、
前記管理テーブルを更新するステップであって、前記第１のメタデータは前記スナップショットが作成済みであることを示し、前記第２のメタデータは前記論理ボリュームがプリマイグレーションされていることを示し、前記第３のメタデータは前記第２レベルのストレージにおける前記論理ボリュームの保管先を示す、前記更新するステップと、をさらに含む、請求項１に記載の方法。
【請求項３】
前記論理ボリュームの上書きまたは前記論理ボリュームの削除が要求された場合、
前記管理テーブルを更新するステップであって、前記第１のメタデータは前記スナップショットの作成が不要であることを示し、前記第２のメタデータは前記論理ボリュームがマイグレーションされていることを示し、前記第３のメタデータは前記第２レベルのストレージにおける前記論理ボリュームの保管先を示す、前記更新するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記スナップショットの上書きが要求された場合、
前記管理テーブルを更新するステップであって、前記第１のメタデータは前記スナップショットの作成が不要であることを示し、前記第２のメタデータは前記論理ボリュームが前記第１レベルのストレージに存在することを示し、前記第３のメタデータは削除されたことを示す、前記更新するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記スナップショットの削除が要求された場合、
前記管理テーブルを更新するステップであって、前記第１のメタデータは削除されたことを示し、前記第２のメタデータは削除されたことを示し、前記第３のメタデータは削除されたことを示す、前記更新するステップをさらに含む、請求項１に記載の方法。
【請求項６】
前記論理ボリュームが、前記第１レベルのストレージに保管されている場合、または前記第１レベルのストレージと前記第２レベルのストレージの両方に保管されている場合、
前記第１レベルのストレージの前記論理ボリュームから前記スナップショットを作成するステップと、
前記管理テーブルを更新するステップであって、前記第１のメタデータは前記スナップショットの作成済みであることを示し、前記第２のメタデータは、前記論理ボリュームが、前記第１レベルのストレージに保管されていること、または前記第１レベルのストレージと前記第２レベルのストレージの両方に保管されていることを示し、前記第３のメタデータは、前記第２レベルのストレージに前記論理ボリュームの保管先が無いこと、または前記第２レベルのストレージにおける前記論理ボリュームの保管先を示す、前記更新するステップと、をさらに含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記第１レベルのストレージはＨＤＤを含み、前記第２レベルのストレージはテープドライブを含む、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
請求項１〜６のいずれか一項の方法の各ステップをコンピュータに実行させるためのコンピュータ・プログラム。
【請求項９】
請求項１〜６のいずれか一項の方法の各ステップをコンピュータに実行させる、ストレージ・システム。
【請求項１０】
請求項９に記載のストレージ・システムに通信可能に接続された、ホストまたは複数のホストをさらに含み、
論理ボリュームのスナップショットの作成指示を与える、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ・システムに関し、より具体的には、ストレージ・システムにおいて階層管理されている論理ボリュームのスナップショットの作成及び管理をおこなうための方法に関する。
【背景技術】
【０００２】
ストレージ・システムにおいて、上位層となる比較的高速なＨＤＤ等のストレージと、下位層となる比較的低速なテープドライブ等のストレージとを用いてデータ（ファイル）を階層管理することが行われている。また、ストレージ・システムにおいて、複数の物理ボリュームからなるボリューム・グループを論理的に区分化した論理ボリュームを用いた論理ボリューム管理（ＬＶＭ）も行われている。
【０００３】
こうしたストレージ管理が存在する場合も含めて、各種ストレージサブシステム、ファイルシステム、アプリケーション等が提供するコピーサービスの中で、ある瞬間（以降、その瞬間をTime 0と呼ぶ）におけるデータのイメージを保存する手法として、スナップショット（Snapshot）やフラッシュコピー（Flash Copy）と呼ばれる技術がある。この技術の詳細な仕組みは、各ハードウェアあるいはソフトウェアによって異なるものの、その原理は文字通りTime 0におけるファイル（データ）が保存されている場所のポインタ情報を保存し、そのポインタ情報を使用して、元のファイルとTime 0に作成したイメージの管理を行うものである。なお、本明細書中では、以降フラッシュコピーの機能を含めて（同義として）、スナップショットという名前を用いて説明する。
【０００４】
既存のスナップショットは単純にTime 0において、ディスク上に存在するファイルにおいてのみ有効であり、対象となるファイルがディスク上に存在しない場合にはスナップショットが作成できない。すなわち、単一階層であるディスク上のみでのスナップショットでは、ディスク上に有効なデータが存在する場合にはポインタ情報を作成し、そのポインタ情報を用いてスナップショットの作成および管理が可能であるが、ディスク上にデータがない場合には、そもそもスナップショットの作成はできない。
【０００５】
しかし、上述したファイルがディスクと物理テープ等を用いて階層管理されている場合、ディスク上に有効なデータが存在しない場合でも物理テープ上には有効なデータが存在する場合がある。また、データを階層移動してディスク上から削除される場合もある。こうした場合を含めて、ファイルが階層管理されている場合に、従来のスナップショット機能を実現するための単純なポインタ情報のみではスナップショットの作成及び管理を行うことは困難である。
【０００６】
特許文献１は、ファイルがディスクと物理テープ等を用いて階層管理されている場合において、各ソース・ファイル毎のｉノードと、各ソース・ファイルのスナップショット・ファイル毎のｉノードとを用いて、スナップショット・ファイルを含むファイル管理の方法を開示する。しかし、特許文献１に記載の方法は、ディスク上に有効なデータが存在しないが物理テープ上には有効なデータが存在するような場合におけるスナップショットの作成及び管理の方法を開示するものではない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第２００９／０１９１２８号（特表２０１０−５３６０７９号公報）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
したがって、本発明の目的は、ディスク上に有効なデータが存在しないが物理テープ上には有効なデータが存在する場合を含めて、階層管理されている論理ボリュームのスナップショットの作成及び管理を行う方法を提供することである。
【課題を解決するための手段】
【０００９】
本発明は、ストレージ・システムにおいて、階層管理されている論理ボリュームのスナップショットの作成及び管理をおこなう方法を提供する。そのストレージ・システムは、第１レベルのストレージと、第１レベルよりも下位の第２レベルのストレージとを含む。その方法は、
（ａ）論理ボリュームのスナップショットの作成指示を受け取るステップと、
（ｂ）スナップショットを管理するための管理テーブルを準備するステップであって、管理テーブルは、スナップショットの作成の状態を示す第１のメタデータと、論理ボリュームの保管状態を示す第２のメタデータと、論理ボリュームの保管先を示す第３のメタデータとを含む、ステップと、
（ｃ）論理ボリュームの保管状態を検出するステップと、
（ｄ）論理ボリュームが、第１レベルのストレージから第２レベルのストレージへマイグレーションされている場合、論理ボリュームを第２レベルのストレージから第１レベルのストレージへリコールすることなく、管理テーブルを更新するステップであって、第１のメタデータはスナップショットの作成が必要であることを示し、第２のメタデータはマイグレーションされていることを示し、第３のメタデータは第２レベルのストレージにおける論理ボリュームの保管先を示すステップと、を含む。
【００１０】
本発明によれば、スナップショットを管理するための管理テーブルを更新し利用することにより、論理ボリュームが第１レベルのストレージから第２レベルのストレージへマイグレーションされている場合に、その論理ボリュームを第２レベルのストレージから第１レベルのストレージへ直ちにリコールすることなく、階層管理されている論理ボリュームのスナップショットの作成及び管理を行うことができる。
【００１１】
本発明の一態様では、論理ボリュームまたはスナップショットへのアクセスが要求された場合に、
（ｅ）論理ボリュームのリコールを実行するステップと、
（ｆ）第１レベルのストレージにリコールされた論理ボリュームからスナップショットを作成するステップと、
（ｇ）管理テーブルを更新するステップであって、第１のメタデータはスナップショットが作成済みであることを示し、第２のメタデータは論理ボリュームがプリマイグレーションされていることを示し、第３のメタデータは第２レベルのストレージにおける論理ボリュームの保管先を示す、ステップと、をさらに含む。
【００１２】
本発明の一態様によれば、論理ボリュームまたはスナップショットへのアクセスが要求された場合に、実際にそのスナップショットを作成し、管理テーブルを更新し利用することにより、そのアクセス要求に対応すると共にその後のスナップショットの管理を適切におこなうことができる。
【００１３】
本発明の一態様では、論理ボリュームの上書きまたは論理ボリュームの削除が要求された場合、
（ｈ）管理テーブルを更新するステップであって、第１のメタデータはスナップショットの作成が不要であることを示し、第２のメタデータは論理ボリュームがマイグレーションされていることを示し、第３のメタデータは第２レベルのストレージにおける論理ボリュームの保管先を示す、ステップをさらに含む。
【００１４】
本発明の一態様によれば、先にスナップショットの作成の指示があった論理ボリュームの上書きまたはその論理ボリュームの削除が要求された場合に、そのスナップショットの作成を不要にすると共に、第２レベルのストレージにおける論理ボリュームの保管先を維持することにより、その保管先の論理ボリューム及びそのスナップショットの作成／管理をおこなうことができる。
【００１５】
本発明の一態様では、スナップショットの上書きが要求された場合、
（ｉ）管理テーブルを更新するステップであって、第１のメタデータはスナップショットの作成が不要であることを示し、第２のメタデータは論理ボリュームが第１レベルのストレージに存在することを示し、第３のメタデータは削除されたことを示す、ステップをさらに含む。
【００１６】
本発明の一態様では、スナップショットの削除が要求された場合、
（ｊ）管理テーブルを更新するステップであって、第１のメタデータは削除されたことを示し、第２のメタデータは削除されたことを示し、第３のメタデータは削除されたことを示す、ステップをさらに含む。
【図面の簡単な説明】
【００１７】
【図１】本発明の方法が実行されるストレージ・システムの構成例を示す図である。
【図２】データの保管状態例を示す図である。
【図３】図２の状態においてスナップショットを作成したイメージ図である。
【図４】本発明の方法のフローを示す図である。
【図５】図４のステップＳ２において準備される管理テーブルの例を示す図である。
【図６】更新後の管理テーブルを示す図である。
【図７】更新後の管理テーブルを示す図である。
【図８】更新後の管理テーブルを示す図である。
【図９】更新後の管理テーブルを示す図である。
【図１０】更新後の管理テーブルを示す図である。
【図１１】更新後の管理テーブルを示す図である。
【図１２】更新後の管理テーブルを示す図である。
【発明を実施するための形態】
【００１８】
図面を参照しながら本発明の実施の形態を説明する。図１は、本発明の方法が実行されるストレージ・システムの構成例を示す図である。ストレージ・システム１０は、ホスト２０に通信可能に接続する第１のストレージ１０１と第２のストレージ１０２を含む。図１の構成は、階層管理に必要となる最小の構成を示したものであって、ストレージ・システム１０は、複数のホスト（サーバ）に接続可能であり、かつ複数の第１のストレージ１０１及び第２のストレージ１０２を含むことができる。なお、ストレージ・システム１０とホスト２０を含む構成を１つの全体的なシステム１（例えば、データシステム、データ管理システム等）として、あるいはその一部として捉えることができる。
【００１９】
一実施形態としては、ストレージ・システム１０の第１のストレージ１０１が上位層となるディスク（以下、ディスクキャッシュ、あるいはHDDとも呼ぶ場合がある）含むストレージであり、第２のストレージ１０２が下位層となる物理テープ（テーブドライブ）を含むストレージである場合を例示することができる。なお、第１及び第２のストレージの構成（組み合わせ）としては、階層化ができるのであれば任意の組み合わせが可能であって、ディスクと物理テープの組み合わせに限定されるものではない。以下の説明では、出願人であるＩＢＭ（登録商標）社が提供するバーチャル・テープ・サーバーＴＳ７７００（以下、単にＴＳ７７００と呼ぶ）を例にとり説明をおこなう。ＴＳ７７００では、図１のストレージ・システム１０において例示されるディスクキャッシュと物理テープを含む形態を最小構成として含むことができる。
【００２０】
図２は、ＴＳ７７００におけるデータの保管状態を示す。ホスト２０から書き込まれたデータは、論理ボリューム３０という単位でディスクキャッシュ１０１に書かれる。論理ボリューム３０は、上述したように、複数の物理ボリュームからなるボリューム・グループを論理的に区分化したものである。ホスト２０は、論理ボリューム３０に対してマウントコマンドを発行し、論理ボリューム３０の読み書きを行う。その後、ホスト２０はリワインド・アンロードとデマウントを行ってアクセスを完了する。アクセス完了後、ユーザーが各論理ボリューム３０ごとに設定したポリシーを元に、ディスクキャッシュ１０１から物理テープ１０２にデータが移行されて階層管理される。
【００２１】
図２に例示されるように、ＴＳ７７００の内部に存在するデータ４０は、以下の３つの保管状態を取り得る。
Ａ：ディスクキャッシュ１０１にのみ存在
Ｂ：ディスクキャッシュ１０１と物理テープ１０２の両方に存在
Ｃ：物理テープ１０２にのみ存在
また、保管状態がＡからＢへ移行することを“プリマイグレーション”と呼び、ＢからＣへ移行することを“マイグレーション”と呼び、ＣからＢへ移行することを“リコール”と呼ぶ。
【００２２】
ＴＳ７７００ではディスクキャッシュ上のデータはＧＰＦＳ（General Parallel File System、登録商標）を介して読み書きしている。ＧＰＦＳではファイルシステムレベル、ファイル単体レベルのスナップショット機能を提供している。以降、本明細書中ではスナップショットの元になる論理ボリュームを元データ、Time 0に作成された論理ボリュームのイメージをスナップショットと呼び説明を行う。
【００２３】
図３に、図２で示した保管状態Ａ、Ｂ、Ｃのデータそれぞれに対して、ＧＰＦＳが提供する機能を使用したTime 0のスナップショットを作成した場合のイメージを示す。図３において、破線のブロック５０がデータ４０に対するスナップショットを示している。Ａ、Ｂの保管状態に関しては、ディスクキャッシュ１０１上にデータ４０が存在するので、正しくTime 0のスナップショット５０を作成することが可能である。
【００２４】
一方、Ｃの場合に関してはディスクキャッシュ１０１上にデータが存在しないために、たとえ物理テープ１０２上に正しい（最新の）データ４０が存在していても、ＧＰＦＳによるスナップショットは作成できない。そのため、保管状態Ｃのデータに対してTime 0のスナップショット５０を作成するには、事前に物理テープ上にあるデータをリコールし、ディスクキャッシュ１０１上に書き出す作業を行わなければいけない。
【００２５】
しかし、ＴＳ７７００では最大２００万の論理ボリュームを定義することが可能であり、マイグレーションされている論理ボリュームが大量にある場合には、全てをリコールするのに長時間かかるため、Time 0自体を定義することが不可能である。また、限られたディスクキャッシュ容量においては、一度に全てのボリュームのリコールができない場合も起こり得る。したがって、事前に物理テープ上にあるデータをリコールする方法は、不適切であり現実的に不可能である。これが、本発明が以下に詳細に説明する方法によって解決する具体的な問題の所在である。
【００２６】
図４を参照しながら本発明の階層管理されている論理ボリュームのスナップショットの作成及び管理を行うための方法のフローについて説明する。図４のフローは、例えば図１の構成において、ストレージ・システム１０内のコンピュータ（コントローラ）が実行するソフトウェアにより実施される。
【００２７】
ステップＳ１において、ホスト等から論理ボリュームのスナップショットの作成指示を受け取る。具体的には、例えば、ユーザーがホストを通して、もしくは管理インターフェースを通してストレージ・システムに指示を与えることができる。ステップＳ２において、スナップショットを管理するための管理テーブルを準備する。具体的には、例えば、スナップショット用のＤＢ２（登録商標）テーブルを準備（複製）する。ここで、ＤＢ２テーブルとは、リレーショナルデータベースとして、ＴＳ７７００において定義されるＤＢ２用のテーブルを意味する。ＤＢ２テーブルは、以下に説明するスナップショットを管理するための各種メタデータを含む。
【００２８】
図５は、ステップＳ２において準備される管理テーブル（ＤＢ２テーブル）の一例である。管理テーブルにおいて、１行〜３行のLVOL_TOK、LVOL、LVOL_TO_PVOLは、それぞれ元データ（論理ボリューム）についての下記のメタデータ情報を含む。また、４行〜６行のLVOL_TOK_SNAP、LVOL_SNAP、LVOL_TO_PVOL_SNAPは、スナップショットについての下記のメタデータ情報を含む。
【００２９】
（ａ）LVOL_TOK： 
各論理ボリュームの状態（最新のデータが存在するかどうか等）を保持する。ディスク、もしくは物理テープのどちらにデータが存在するかに関わらず、ユーザーが論理ボリュームを定義した時点でエントリーが作成される。
（ｂ）LVOL： 
各論理ボリュームのデータがディスク、もしくは物理テープ上にあるかどうか（マイグレーション／プリマイグレーションされているかどうか）等を保持する。LVOL_TOKと同様に、ディスク、もしくは物理テープのどちらにデータが存在するかに関わらず、ユーザーが論理ボリュームを定義した時点でエントリーが作成される。
（ｃ）LVOL_TO_PVOL： 
各論理ボリュームがプリマイグレーション、もしくはマイグレーションされている場合に、その論理ボリュームがどの物理テープ上にあるあるかどうか等を保持する。論理ボリュームが物理テープにプリマイグレーションされた時点でエントリーが作成される。
【００３０】
図５の例は、既にマイグレーションされた（migrated）状態にある、すなわち物理テープにのみ存在する論理ボリューム（元データ）についての管理テーブルを示している。そのため、２行目のLVOLが“migrated”を示し、３行目のLVOL_TO_PVOLがマイグレーションされた論理ボリューム（元データ）の保管先の物理ボリュームPVOLXを示している。１行目のLVOL_TOKは、初期状態として“スナップショット（Snap）が作成不要であることを示している。４行〜６行のLVOL_TOK_SNAP、LVOL_SNAP、LVOL_TO_PVOL_SNAPは、初期状態として“存在しない（ＮＡ）”を示している。
【００３１】
図４に戻って、ステップＳ３において、論理ボリューム（元データ）の保管状態を検出する。具体的には、図２で示したＡ、Ｂ、Ｃのいずれの状態にあるのかを検出する。ステップＳ４において、論理ボリューム（元データ）がマイグレーションされているか否かを判定する。この判定がＹｅｓの場合、ディスクキャッシュ上にデータが存在しないために、スナップショットの作成をＧＰＦＳに指示しても、実際のスナップショットは作成されずに、Time 0のイメージを作成できない。そのため、スナップショットを直ちに作成するための処理を行うことなく、ステップＳ５において、管理テーブルの更新を行う。
【００３２】
図６に更新後の管理テーブルを示す。LVOL_TOKと、LVOL_TOK_SNAPの現在のスナップショットの状態を示すフィールドに、元データがリコールされた段階で、各論理ボリューム単位で再度スナップショットの作成が必要なことを示す“Snap作成必要”を記録する。そして、LVOL_SNAPにもLVOLと同じようにマイグレーションされていることを示す“migrated”を記録し、さらに、LVOL_TO_PVOL_SNAPには、マイグレーションされている元データの物理ボリュームPVOLXが記録される。
【００３３】
ステップＳ４の判定がＮｏの場合、すなわちディスクキャッシュ上に元データが存在する場合、ステップＳ５において、図３のＡ、Ｂのケースで例示したように、その元データからTime 0でのスナップショットを作成する。そして、ステップＳ５に進み、管理テーブルの更新を行う。図７にスナップショット作成後に更新された管理テーブルを示す。図７の管理テーブルにおいて、“cached”はディスクキャッシュ１０１上に元データが存在する図２のＡの保管状態を意味し、“pre-migrated”はディスクキャッシュ１０１と物理テープ１０２の両方に存在する図２のＢの保管状態を意味する。
【００３４】
ここまでで、ＴＳ７７００が管理している全ての論理ボリュームに対するTime 0のスナップショット作成作業は完了する。しかし、実際にはTime 0のスナップショットイメージは、上述したマイグレーションされている論理ボリュームに対しては作成されていない。そこで、本発明では、スナップショット作成作業完了後、以下のいずれかの事象が発生した場合に、マイグレーションされている論理ボリュームへのスナップショット作成及び管理を個別に行う。例えば、一実施形態として、ＧＰＦＳでは“mmcrsnapshot”コマンドにより、管理しているファイルシステム下の全てのデータに対して一括してスナップショット作成を行うことができる。一方、個別のファイルに対するスナップショットは、“mmclone”コマンドにより作成が可能である。
【００３５】
（Ａ）元データ、もしくはスナップショットに対してアクセス（論理ボリュームの読み出し、追記）が発生した場合
（Ａ１）ＴＳ７７００では、ホストはディスクキャッシュ上に存在するファイルに対してのみアクセスが可能なために、マイグレーションされている元データに対してアクセスが来た場合には、データのリコールが行われる。同様に、スナップショットに対してアクセスが来た場合においても、LVOL_TO_PVOL_SNAPに書かれている物理テープからリコールを行う
（Ａ２）元データのリコールが完了した時点でホストからのアクセスが可能となるが、この時点で元データ毎にスナップショットを作成する。
（Ａ３）その後、管理テーブルの更新を行う。図８に更新後の管理テーブルを示す。LVOL_TOKとLVOL_TOK_SNAPは、“Snap作成必要”から“Snap作成済み”に変更され、LVOLとLVOL_SNAPは、プリマイグレーション状態になったこと（“pre-migrated”）に変更される。
【００３６】
（Ｂ）元ファイルの上書き：Write From BOT（Beginning of Tape）が発生した場合
この場合、管理テーブルの以下の更新を行う。すなわち、LVOL_TOKは“Snap作成不要”と変更、LVOLはディスク上にデータが存在すること（“cached”）をアップデートし、さらにLVOL_TO_PVOLを削除（ＮＡ）にする必要がある。しかし、スナップショットのLVOL_TO_PVOL_SNAPにはまだエントリーが残っているために、物理テープ上に存在している元ファイルの論理ボリュームの無効化は行わない。この場合、スナップショットの作成を行う必要はなくなり、元ファイルとスナップショットは独立した二つのファイルとして、今後のアクセスを提供する。図９に更新後の管理テーブルを示す。
【００３７】
（Ｃ）元ファイルの削除が発生した場合
この場合、管理テーブルにおいて、LVOL_TOK、LVOL及びLVOL_TO_PVOLの削除を伴う更新をおこなう。LVOL_TOK_SNAP、LVOL_SNAP及びLVOL_TO_PVOL_SNAPの状態は、上記の（Ｂ）のケースと同様である。図１０に更新後の管理テーブルを示す。
【００３８】
実際に例えばＧＰＦＳ上等でのスナップショットの作成が行われる前に、以下のいずれかの事象が発生した場合には、スナップショットの作成は不要になる。
（Ｄ）スナップショットの上書き（Write
From BOT）が発生した場合
この場合、元ファイルからスナップショットを作成する必要はなくなるために、リコールなどは行わず、管理テーブルの以下の更新を行う。すなわち、LVOL_TOKとLVOL_TOK_SNAPは、“snap作成必要”から“snap作成不要”に変更し、LVOL_SNAPは、ディスク上にデータが存在すること（“cached”）をアップデートし、さらにLVOL_TO_PVOL_SNAPは削除（ＮＡ）にする。図１１に更新後の管理テーブルを示す。
【００３９】
（Ｅ）スナップショットの削除が発生した場合
この場合、管理テーブルの以下の更新を行う。すなわち、LVOL_TOK_SNAP、 LVOL_SNAP及びLVOL_TO_PVOL_SNAPは削除（ＮＡ）にされ、LVOL_TOKは、Snap作成必要”から“Snap作成不要”に変更する。図１２に更新後の管理テーブルを示す。
【００４０】
以上のように、LVOL_TOKとLVOL_TOK_SNAPに新たに追加される“現在のスナップショットの状態”を示すフィールドが取りうる値としては、“Snap作成不要”、“Snap作成必要”及び“Snap作成済み”の３つとなる。そして、“Snap作成不要”の論理ボリューム、スナップショットは、それぞれを独立の論理ボリュームとして扱われることになる。
【００４１】
本発明の実施形態について、図を参照しながら説明をした。しかし、本発明はこれらの実施形態に限られるものではない。上述した実施形態では、ディスクと物理テープの間で階層管理を実現している場合を例にとり説明したが、本発明はこれに限られず、一般的に異なる層での階層管理をしているシステム全般に適応可能である。上位のディスク装置上で既存のスナップショット機能を適用し、下位のディスク装置に移行されたデータの状態をメタデータとして記録しておくことで、同様の仕組みを利用することができる。また、３つ以上の階層を使用している場合でも同様の手法でスナップショットの管理が可能である。
【符号の説明】
【００４２】
１  全体的なシステム
１０  ストレージ・システム
２０  ホスト、複数のホスト（サーバー）
３０  論理ボリューム
４０  データ
５０  スナップショット
１０１  第１のストレージ（HDD等）
１０２  第２のストレージ（テープドライブ等）
【図１】
2015079409.tif 000003
【図２】
2015079409.tif 000004
【図３】
2015079409.tif 000005
【図４】
2015079409.tif 000006
【図５】
2015079409.tif 000007
【図６】
2015079409.tif 000008
【図７】
2015079409.tif 000009
【図８】
2015079409.tif 000010
【図９】
2015079409.tif 000011
【図１０】
2015079409.tif 000012
【図１１】
2015079409.tif 000013
【図１２】
2015079409.tif 000014