JP2009543199A - 永久的コンシステンシ・ポイント・イメージを使用するストレージシステムのデータ重複解消を管理するシステム、及び方法 - Google Patents

Abstract

永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）を使用しているストレージシステムのデータ重複解消を管理するシステム、及び方法。データ転送の目標ＰＣＰＩが生成されると、ストレージシステムのバックアップ管理モジュールは、データ重複解消モジュールに警告を発し、目標ＰＣＰＩに含まれるデータの重複解消を開始させる。重複解消手順が完了すると、ストレージシステムのアクティブファイルシステムの重複解消は完了するが、目標ＰＣＰＩは重複解消されないままに置かれる。これに応答し、バックアップ管理モジュールは、変更された目標ＰＣＰＩを生成し、エキスポートする。その後、以前の目標ＰＣＰＩは削除され、それによって、エキスポートされたＰＣＰＩイメージのファイルシステムの状態は、重複解消状態へと移行される。
【選択図】図８

Description

[発明の分野]
本発明は、重複データの除去に関し、具体的には、永久的コンシステンシ・ポイント・イメージを使用しているストレージシステムにおける重複データの除去の管理に関する。

[発明の背景]
ストレージシステムは一般に１以上の記憶装置を備え、要望に応じてその中に情報を入れたり、そこから情報を取り出したりすることができる。ストレージシステムは、ストレージオペレーティングシステムを含み、ストレージオペレーティングシステムは、とりわけ、システムによって実施されるストレージサービスを支える種々のストレージオペレーションを実施することにより、システムを機能的に編成する。ストレージシステムは、種々のストレージアーキテクチャに従って実施することができ、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、あるいは、クライアントコンピュータ、又はホストコンピュータに直接取り付けられたディスクアセンブリとして実施される場合がある。記憶装置は通常、ディスクアレイとして編成された幾つかのディスクドライブである。ここで、「ディスク」という用語は一般に、内蔵型の回転式磁気媒体記憶装置を意味する。この文脈におけるディスクという用語は、ハード・ディスク・ドライブ（ＨＤＤ）やダイレクト・アクセス・ストレージ・デバイス（ＤＡＳＤ）と同じような意味である。

ディスクアレイへの情報の記憶は、好ましくは、ディスク空間の全体的論理構成を定義する、物理ディスクの１以上のストレージ「ボリューム」として実施される。ボリューム内のディスクは通常、１以上のグループに編成され、各グループが、ＲＡＩＤ（Redundant Array of Independent or Inexpensive Disks）として運用される。大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所与の数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、ストライピングされたデータに関する冗長情報（パリティ）を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。各ＲＡＩＤグループの物理ディスクには、ストライピングされたデータを記憶するように構成されたディスク（すなわち、データディスク）と、データのパリティを記憶するように構成されたディスク（すなわち、パリティディスク）とがある。その後、ディスクが故障したときに、失われたデータの復旧を可能にするために、パリティは読みされる場合がある。「ＲＡＩＤ」という用語、及びその種々の実施形態は周知であり、１９９８年６月、データ管理に関する国際会議（ＳＩＧＭＯＤ）の議事録において、D.A. Patterson、G.A. Gibson、及びR.H. Katzにより、「A Case for Redundant Arrays of Inexpensive Disks (RAID)」と題して開示されている。

ストレージシステムのストレージオペレーティングシステムは、ファイルシステムのような上位モジュールを実施し、ディスクに記憶された情報をディレクトリ、ファイル、又はブロックのようなデータコンテナの階層構造として論理編成する場合がある。例えば、「ディスク上」の各ファイルは、ファイルの実際のデータのような情報を記憶するように構成された一組のデータ構造、すなわちディスクブロックとして実施される場合がある。これらのデータブロックは、ファイルシステムによって管理されるボリュームブロック番号（ｖｂｎ）空間の中に編成される。ファイルシステムは更に、ファイル内の各データブロックに、対応する「ファイルオフセット」、又はファイルブロック番号（ｆｂｎ）を割り当てる場合がある。ファイルシステムは通常、ファイルごとに連続したｆｎｂを割り当てるのに対し、ｖｂｎは、より大きなボリュームアドレス空間に割り当てられる。ファイルシステムは、ｖｂｎ空間内において幾つかのデータブロックを「論理ボリューム」として編成する。そして、もちろん必須ではないが、各論理ボリュームは、その論理ボリューム独自のファイルシステムに関連付けられる場合がある。ファイルシステムのサイズが、ｎ＋１ブロックである場合、ファイルシステムは通常、ゼロからｎまでの連続した範囲のｖｂｎから構成される。

一つの既知のタイプのファイルシステムは、ディスク上でデータを上書きしないｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムである。ディスクからストレージシステムのメモリ内へデータブロックを取り出し（読み出し）、新たなデータで「汚す」（すなわち、更新、又は変更）するとき、書き込み性能を最適化するために、以後、そのデータブロックは、ディスク上の新たな場所に記憶（書き込み）される。ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上で実質的に連続的に配置されるような最適レイアウトを最初に仮定する場合がある。この最適なディスクレイアウトにより、ディスクに対する効率的なアクセスオペレーションが可能となり、特に、シーケンシャル読み出しオペレーションの場合に効率的なアクセスオペレーションが可能となる。ストレージシステム上で動作するように構成されたｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワーク アプライアンス，インコーポレイテッドから販売されているＷｒｉｔｅ Ａｎｙｗｈｅｒｅ Ｆｉｌｅ Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムである。

ストレージシステムは、クライアント／サーバモデルの情報配送に従って動作するように構成され、それによって、多数のクライアントが、システムに記憶されたディレクトリ、ファイル、及びブロックにアクセスできる場合がある。このモデルでは、クライアントは、データベースアプリケーションのようなアプケーションを有し、ポイント・ツー・ポイントリンク、共有ローカルエリアネットワーク、ワイドエリアネットワーク、あるいはインターネットのような公共ネットワークを介して実施される仮想私設ネットワークのようなコンピュータネットワークを介してストレージシステムに「接続」されたコンピュータ上で、そうしたアプリケーションを実行する場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージ（パケットの形をしている）をストレージシステムに対して発行することにより、ファイルシステムにサービスを要求する場合がある。従来のコモン・インターネット・ファイルシステム（ＣＩＦＳ）プロトコルとネットワーク・ファイル・システム（ＮＦＳ）プロトコルのような複数のファイルシステムプロトコルをサポートすることによって、ストレージシステムの利便性を向上させることができる。

既知のファイルシステムの中には、ファイルシステムのスナップショット、又はその一部を生成する機能を有するものがある。スナップショット、及びスナップショット生成手順の詳細については、１９９８年１０月６日に発行された「Method For Maintaining Consistent States of a File System and for Creating User-Accessible Read-Only Copies of a File System」と題するDavid Hitz他による米国特許第５，８１９，２９２号に記載されており、この文献は、ここで参照することにより本明細書の中で完全に説明されたものとして、本明細書に援用される。「スナップショット」は、ネットワーク アプライアンス，インコーポレイテッドの商標である。この商標は、本明細書では、永久的コンシステンシ・ポイント（ＣＰ）イメージ（ＰＣＰＩ）を指して使用される。ＰＣＰＩは、ある時点でのストレージシステムの読み出し専用表現であり、具体的には、アクティブファイルシステムを表したものであり、記憶装置（例えば、ディスク）、又は他の永久的メモリに記憶され、自分自身を他の時点において作成された他のＰＣＰＩから区別するための名前、又は一意の識別子を有する。さらに、ＰＣＰＩは、当該イメージが作成された時点におけるアクティブファイルシステムに関する他の情報（メタデータ）を含む場合もある。ネットワークアプライアンスの商標権を失墜させることなく、本明細書では、「ＰＣＰＩ」という用語と「スナップショット」という用語は、交換可能に使用される。

ＰＣＰＩは、アクティブファイルシステムのバックアップの形で使用されることがある。データの読み出しや復元を改善するために、ＰＣＰＩは、そのＰＣＰＩが生成された元のボリューム、又はファイルシステム以外の別のファイルシステムにコピーしなければならない。一つの既知の例として、バックアップストレージシステムを使用して幾つかのＰＣＰＩを記憶し、ユーザ定義の一組のオプションに従って、一群のＰＣＰＩを管理する場合がある。バックアップストレージシステムの詳細については、「System and Method for Managing a Plurality of Snapshots」と題するHugo Patterson他による米国特許出願第１０／１０１，９０１号に記載されており、この文献は、参照により本明細書に援用される。

ＰＣＰＩをバックアップの形で使用する環境では、しばしば、バックアップストレージシステム上の複数の場所に、同じデータが記憶されることがある。これが発生するのは、例えば、単一のデータコンテナが複数のセクションに同じデータを有する場合や、あるいは、ボリューム内の複数のデータコンテナ、又は他のデータの集合（すなわち、データ集合）が、同じデータを有する場合である。ストレージシステムでは、重複データの量を減らすための種々の既知の技術を使用し、例えばアクティブファイルにおける重複データブロックの数を低減する場合がある。しかしながら、ＰＣＰＩを使用しているバックアップストレージシステム環境では、ＰＣＰＩの長期保有により、従来のデータ重複解消技術の有効性は、制限されることがある。その主な理由は、データ重複解消手順の利点、すなわち、記憶される重複データブロックの数を低減するためには、通常、データ集合中の種々のデータポインタに対する変更が必要となるからである。ＰＣＰＩは読み出し専用であるため、ＰＣＰＩ内の種々のブロックは、そのＰＣＰＩが削除されるまで、「ロック」された状態に維持される（従って、重複解消されることはない）。非バックアップストレージシステムでは、ＰＣＰＩは通常、２〜３日後に削除されるため、ＰＣＰＩの長期保有による制限は最小限に抑えられる。

本発明は、１以上の永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）を使用しているストレージシステムにおけるデータ重複解消を管理するシステム、及び方法を提供することにより、従来技術の欠点を克服する。具体的には、ＰＣＰＩをバックアップの形で使用しているバックアップストレージオペレーティングシステムでは、バックアップ管理モジュールは、データ重複解消モジュールとの間で情報をやりとりし、バックアップストレージシステム内の１以上のデータ集合、例えば、ボリューム、又はファイルシステムに対してデータ重複解消を実施する。動作として、バックアップ管理モジュールは、ソースストレージシステム（「ソース」）から転送要求を受信し、それに応じて、ソースからバックアップストレージシステム上の宛先ボリュームへのデータ集合の転送を開始する。最後のデータ転送が完了すると、バックアップ管理モジュールは、ファイルシステムと協働し、宛先ボリュームの第１のＰＣＰＩを生成する。次に、バックアップ管理モジュールは、データ転送中に生成された一時ファイルのクリーンアップオペレーションを実施し、その後、宛先ボリュームの第２のＰＣＰＩを生成する。そしてバックアップ管理モジュールは、第３の、すなわち目標ＰＣＰＩを生成し、その後、その目標ＰＣＰＩを１以上のクライアントにエキスポートする。

目標ＰＣＰＩが生成されると、転送要求は完了したものとみなされ、転送されたデータは、バックアップストレージシステムのクライアントによりアクセス可能な状態になる。さらに、目標ＰＣＰＩが生成されると、バックアップ管理モジュールは、データ重複解消モジュールに警告を発し、目標ＰＣＰＩに含まれるデータの重複解消を開始させる。データ重複解消モジュールは、同一データを有する複数のデータブロックの中から一つだけが得られるまで、同一データを有するブロックを識別し、削除することにより、重複解消手順を実施する。重複解消手順が完了すれば、バックアップファイルシステムのアクティブファイルシステムは重複解消される。しかしながら、エキスポートされた目標ＰＣＰＩは依然として重複解消されていない。これに応答し、バックアップ管理モジュールは、変更された目標ＰＣＰＩを生成し、エキスポートする。その後、一つ前の目標ＰＣＰＩは削除される場合があり、それによって、ファイルシステムの状態のエキスポートされたＰＣＰＩのイメージは、重複解消された状態へと移行される。

本発明の一実施形態によるストレージシステム環境を示す略ブロック図である。 本発明の一実施形態によるストレージシステム上で実行される例示的ストレージオペレーティングシステムを示す略ブロック図である。 本発明の一実施形態による例示的ｉｎｏｄｅを示す略ブロック図である。 本発明の一実施形態による例示的ｉｎｏｄｅバッファツリーを示す略ブロック図である。 本発明の一実施形態による永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）ｉｎｏｄｅの生成を示す、例示的ｉｎｏｄｅバッファを示す略ブロック図である。 本発明の一実施形態による、データの書き込みに応答して新たに生成されたバッファツリーを示す、例示的ｉｎｏｄｅバッファツリーを示す略ブロック図である。 本発明の一実施形態による、複数のバックアップクライアントのファイルシステムの単一宛先ボリュームへの統合を示す、例示的宛先ボリュームを示す略ブロック図である。 本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムのデータ重複解消のための手順のステップを詳細に示すフロー図である。 本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムのデータ重複解消を示す図である。 本発明の一実施形態による、第１の重複解消手順の完了前に第２の転送が開始されるときの、ＰＣＰＩを使用しているストレージシステムにおけるデータ重複解消を示す図である。 本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムのデータ重複解消を実施する手順のステップを詳細に示すフロー図である。 本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムにおけるデータ重複解消を示す図である。 本発明の一実施形態による、ＰＣＰＩを使用しているシステムにおけるデータ重複解消を示す図である。 本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムにおけるデータ重複解消を示す図である。

[例示的実施形態の詳細な説明]
Ａ．ストレージシステム環境
図１は、本発明とともに有利に使用されるストレージシステム１２０を含む環境１００を示す略ブロック図である。ストレージシステムは、ディスクアレイ１６０のディスク１３０のような記憶装置上での情報の編成に関連するストレージサービスを提供するコンピュータである。ストレージシステム１２０は、システムバス１２５によって相互接続されたプロセッサ１２２、メモリ１２４、ネットワークアダプタ１２６、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）１２９、及びストレージアダプタ１２８を含む。ストレージシステム１２０はさらに、ストレージオペレーティングシステム２００を含み、ストレージオペレーティングシステム２００は、好ましくは、ファイルシステムのような上位モジュールを実施し、情報をディレクトリ、ファイル、及び仮想ディスク（以下、「ブロック」）と呼ばれる特殊なタイプのファイルの階層構造として論理編成する。

例示的実施形態として、メモリ１２４は、ソフトウェアプログラムコードを記憶するために、プロセッサ、及びアダプタによってアドレス指定可能な多数の記憶場所を有する。メモリの一部は、本発明に関連するデータ構造を記憶するために、「バッファキャッシュ」１７０としてさらに編成される場合がある。コンシステンシ・ポイント間におけるファイルシステムへの変更を記憶するために、ＮＶＲＡＭ１２９をさらに使用する場合がある。また、プロセッサ、及びアダプタは、ソフトウェアコードを実行し、データ構造を操作するように構成された処理要素、及び／又は論理回路を含む場合がある。ストレージオペレーティングシステム２００は、その一部が通常、メモリに常駐し、処理要素によって実行され、とりわけ、ストレージシステムによって実行されるストレージオペレーションを実行することにより、システム１２０を機能的に編成する。当業者には明らかなように、本明細書に記載する本発明の技術に関連するプログラム命令の記憶、及び実行には、他の処理手段や、種々のコンピュータ読取可能媒体を含む他の記憶手段を使用してもよい。

ネットワークアダプタ１２６は、コンピュータネットワーク１４０を介してストレージシステム１２０をクライアント１１０に接続するために必要な機械的、電気的、及び信号的回路から成り、コンピュータネットワーク１４０は、ポイント・ツーポイント接続、又はローカルエリアネットワークのような共有媒体からなる場合がある。例えば、コンピュータネットワーク１４０は、イーサネット（Ｒ）ネットワーク、又はファイバチャネル（ＦＣ）ネットワークとして実施される場合がある。クライアント１１０は、トランスミッション・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）のような所定のプロトコルに従って個々のデータフレーム、又はデータパケット１５０をやりとりすることにより、ネットワーク１４０を介して、ストレージシステムとの間で通信することができる。

クライアント１１０は、本明細書に記載するように、アプリケーションを実行するように構成された汎用コンピュータであってもよいし、ストレージシステム１２０を使用してバックアップオペレーションを行うストレージシステム（すなわち、バックアップストレージシステムのようなもの）であってもよい。すなわち、本発明の代替実施形態では、バックアップストレージシステム１２０は、長期保管のためにバックアップ／ミラーを記憶するバックアップサーバのような働きをする場合がある。そのような用途の詳細については、「System and Method for Managing a Plurality of Snapshots」と題する、上で参照した米国特許出願に詳しく記載されている。

クライアント１１０（すなわち、ソースストレージシステム）は、クライアント／サーバモデルの情報配送に従って、バックアップストレージシステム１２０との間で情報をやりとりする場合がある。すなわち、ネットワーク１４０を介してパケット１５０をやりとりすることにより、クライアントはストレージシステムにサービスを要求する場合があり、システムはクライアントから要求されたサービスの結果を返す場合がある。クライアントは、ファイルやディレクトリの形をした情報をアクセスするときは、ＴＣＰ／ＩＰを介してコモン・インターネット・ファイル・システム（ＣＩＦＳ）プロトコル、又はネットワーク・ファイル・システム（ＮＦＳ）プロトコルのようなファイルベースのアクセスプロトコルを含むパケットを発行する場合がある。一方、クライアントは、ブロックの形をした情報をアクセスするときは、ＳＣＳＩ ｏｖｅｒ ＴＣＰ（ｉＳＣＳＩ）プロトコルや、ＳＣＳＩ ｏｖｅｒ ＦＣ（ＦＣＰ）プロトコルのようなブロックベースのアクセスプロトコルを含むパケットを発行する場合がある。

ストレージアダプタ１２８は、システム１２０上で実行されているストレージオペレーティングシステム２００と協働し、ユーザ（すなわち、クライアント）から要求された情報をアクセスする。情報は、書き込み可能なストレージデバイス媒体の任意のタイプのアタッチド・アレイに記憶され、媒体には、例えば、ビデオテープ、光学的、ＤＶＤ、磁気テープ、バブルメモリ、電気的ランダムアクセスメモリ、又はＭＥＭＳデバイスなどがあり、あるいはデータやパリティ情報を記憶するように構成された任意の他の適当な媒体も含まれる。ただし、本明細書で例示するように、情報は、アレイ１６０のＨＤＤ、及び／又はＤＡＳＤのようなディスク１３０に記憶されることが好ましい。ストレージアダプタは、従来の高性能ＦＣシリアルリンクトポロジのようなＩ／Ｏ相互接続構成によってディスクに接続される入出力（Ｉ／Ｏ）インタフェース回路を含む。

アレイ１６０への情報の記憶は、好ましくは、１以上のストレージ「ボリューム」として実施され、ボリュームは、一群の物理記憶ディスク１３０を含み、それらが
協働して、ボリューム（複数の場合もあり）上のボリュームブロック番号（ｖｂｎ）空間の全体的論理構成を規定する。当然ながら必須ではないが、各論理ボリュームは一般に、各自、自分のファイルシステムに関連している。論理ボリューム／ファイルシステム内のディスクは通常、１以上のグループに編成され、各グループは、ＲＡＩＤ（Redundant Array of Independent or Inexpensive Disks）として運用される場合がある。ＲＡＩＤ４レベル実施形態のような大半のＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所与の数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、更に、そのストライピングされたデータに関連するパリティ情報を適切に記憶することにより、データ記憶の信頼性／完全性を向上させる。ＲＡＩＤ実施形態の一例は、ＲＡＩＤ４レベル実施形態であるが、当然ながら、本明細書に記載する本発明の原理によれば、他のタイプ、又はレベルのＲＡＩＤ実施形態を使用することも可能であるものと考えられる。

Ｂ．ストレージオペレーティングシステム
ディスク１３０へのアクセスを容易にするために、ストレージシステム２００は、ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。このファイルシステムは、仮想化モジュールと協働し、ディスク１３０により提供される記憶空間を仮想化する。ファイルシステムは、情報を名前付きディレクトリ、及びファイルの階層構造としてディスク上に論理編成する。「ディスク」上の各ファイルは、データのような情報を記憶するように構成された一組のディスクブロックとして実施される場合がある一方、ディレクトリは、特殊な形のファイルとして実施され、その中に他のファイルやディレクトリの名前、あるいはそれらへのリンクが記憶される場合がある。仮想化モジュールによれば、ファイルシステムは、情報をディスク上のブロックの階層構造としてさらに論理編成し、それらを名前付きの論理ユニット番号（ＬＵＮ）としてエキスポートすることが可能になる。

例示的実施形態として、ストレージオペレーティングシステムは、カリフォルニア州サニーベイルにあるネットワーク アプライアンス，インコーポレイテッドから市販されているＮｅｔＡｐｐ Ｄａｔａ ＯＮＴＡＰオペレーティングシステムであることが好ましい。ただし、当然ながら、任意の適当なストレージオペレーティングシステムを本明細書に記載する本発明の原理に従って拡張して使用することが可能であるものと考えられる。したがって、「Ｄａｔａ ＯＮＴＡＰ」という用語を使用した場合でも、この用語は、本発明の教示に適合する任意のストレージオペレーティングシステムを指すものとして広い意味で捉えるべきである。

図２は、本発明とともに有利に使用されるストレージオペレーティングシステム２００を示す略ブロック図である。ストレージオペレーティングシステムは、統合ネットワークプロトコルスタックを形成するように編成された一連のソフトウェア層を含む。すなわち、より一般的に言えば、ストレージオペレーティングシステムは、ストレージシステムに記憶された情報をブロックアクセスプロトコル、及びファイルアクセスプロトコルを使用してアクセスするときのデータパスをクライアントに提供するマルチプロトコルエンジンを含む。プロトコルスタックは、ＩＰ層５１２、並びにその支援搬送手段であるＴＣＰ層２１４、及びユーザ・データグラム・プロトコル（ＵＤＰ）層２１６のような種々のネットワークプロトコル層との間のインタフェースとして機能するネットワークドライバ（例えば、ギガビット・イーサネット（Ｒ）・ドライバ）のメディアアクセス層２１０を含む。ファイルシステムプロトコル層は、マルチプロトコルファイルアクセスを可能にし、その目的のために、ダイレクトアクセスファイルシステム（ＤＡＦＳ）プロトコル２１８、ＮＦＳプロトコル２２０、ＣＩＦＳプロトコル２２２、及びハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）プロトコル２２４をサポートする。ＶＩ層２２６は、ＶＩアーキテクチャを実施し、ＤＡＦＳプロトコル２１８によって必要とされるようなＲＤＭＡのようなダイレクト・アクセス・トランスポート（ＤＡＴ）機能を提供する。

ｉＳＣＳＩドライバ層２２８は、ＴＣＰ／ＩＰネットワークプロトコル層を介したブロックプロトコルアクセスを提供する一方、ＦＣドライバ層２３０は、ストレージシステムとの間で、ブロックアクセス要求、及び応答の送受信を行う。ＦＣドライバ、及びｉＳＣＳＩドライバは、ブロックに対するＦＣ固有の、又はｉＳＣＳＩ固有のアクセス制御を提供し、したがって、ストレージシステム上のブロックをアクセスするときに、ｉＳＣＳＩとＦＣＰのいずれか一方、あるいは両方へのＬＵＮのエキスポートを管理する。さらに、ストレージオペレーティングシステムは、ＲＡＩＤシステム２４０として実施され、Ｉ／Ｏオペレーションに従ってボリューム／ディスクに対する情報の記憶、又は読み出しを管理するストレージモジュールと、ＳＣＳＩプロトコルのようなディスクアクセスプロトコルを実施するディスクドライバシステム２５０とを含む。

ディスクソフトウェア層を統合ネットワークプロトコルスタック層に橋渡しするのは、仮想化システムである。仮想化システムはファイルシステム２８０によって実施され、ファイルシステム２８０は、例えばｖディスクモジュール２９０、及びＳＣＳＩターゲットモジュール２７０として実施される仮想化モジュールとの間で情報をやりとりする。ｖディスクモジュール２９０は、ファイルシステム２８０の上に層として形成され、ストレージシステムに対するユーザ（システム管理者）発行コマンドに応答して、ユーザインタフェース（ＵＩ）２７５のような管理インタフェースによるアクセスを有効化にする。ＳＣＳＩターゲットモジュール２７０は、ＦＣ、ｉＳＣＳＩドライバ２２８，２３０と、ファイルシステム２８０との間に配置され、ブロック（ＬＵＮ）空間とファイルシステム空間の間の変換層を仮想化システムに提供する。ただし、ＬＵＮはブロックとして表現される。ＵＩ２７５は、種々の層、及びシステムへの管理者、又はユーザによるアクセスが可能となるような形で、ストレージオペレーティングシステム上に配置される。さらに、後で詳しく説明するように、ファイルシステム２８０内の一組のＰＣＰＩプロセス２８２によって、ＰＣＰＩの生成が可能になる。

ファイルシステムは、例えば、ディスクのような記憶装置に記憶された情報のアクセスに使用される論理ボリューム管理機能を備えたメッセージベースのシステムである。すなわち、ファイルシステム２８０は、ファイルシステムセマンティックを提供するだけでなく、通常ならばボリュームマネージャに関連する機能も提供する。そのような機能には、例えば、（１）ディスクのアグレゲーション、（２）ディスクの記憶帯域幅のアグレゲーション、及び（３）ミラーリング、及び／又はパリティ（ＲＡＩＤ）のような信頼性保証がある。ファイルシステム２８０は、例えば４キロバイト（ＫＢ）ブロックを使用し、インデックス・ノード（「ｉｎｏｄｅ」）を使用してファイルやファイル属性（例えば、作成時刻、アクセス許可属性、サイズ、及びブロック位置）を識別するブロックベースのオンディスク・フォーマット表現を有するＷＡＦＬファイルシステム（以後一般に「ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム」）を実施する。ファイルシステムは、ファイルを使用して、自分が有しているファイルシステムのレイアウトを表すメタデータを記憶する。そのようなメタデータファイルとしては、とりわけ、ｉｎｏｄｅファイルがある。ディスクからｉｎｏｄｅを読み出すためには、ファイルハンドル、すなわちｉｎｏｄｅ番号を含む識別子が使用される。

簡単に言えば、ｗｒｉｔｅ−ａｎｙｗｈｒｅファイルシステムのｉｎｏｄｅは全て、ｉｎｏｄｅファイルとして編成される。ファイルシステム（ＦＳ）ｉｎｆｏブロックは、ファイルシステム内の情報のレイアウトを指定し、ファイルシステムの他の全てのｉｎｏｄｅを含むファイルのｉｎｏｄｅを含む。各論理ボリューム（ファイルシステム）は、ＦＳ ｉｎｆｏブロックを有し、このブロックは、例えばＲＡＩＤグループ内の固定位置に記憶されることが好ましい。ｉｎｏｄｅファイルのｉｎｏｄｅはｉｎｏｄｅファイルのブロックを直接参照（指し示す）場合もあれば、ｉｎｏｄｅファイルの間接ブロックを参照し、さらに、その間接ブロックが、ｉｎｏｄｅファイルのブロックを指し示す場合もある。ｉｎｏｄｅファイルの直接ブロックの中にはそれぞれ、種々のｉｎｏｄｅが埋め込まれ、それらのｉｎｏｄｅがそれぞれ、間接ブロックを参照し、さらに、その間接ブロックが、ファイルのデータブロックを参照する。

動作として、クライアント１１０からの要求は、パケット１５０としてコンピュータネットワーク１４０を介してストレージシステム１２０へ転送され、そこで、ネットワークアダプタ１２６により受信される。（層２１０、又は層２３０）のネットワークドライバは、そのパケットを処理し、必要に応じて、それをネットワークプロトコル層、及びファイルアクセス層へ渡して更なる処理を施してから、ｗｒｉｔｅ−ａｎｙｈｗｅｒｅファイルシステム２８０へと転送する。ここで、ファイルシステムは、要求されたファイルが、「コア」内、すなわちバッファキャッシュ１７０内に無ければ、それをディスク１３０からロードするオペレーションを生成する。情報がキャッシュ内に無ければ、ファイルシステム２８０は、ｉｎｏｄｅ番号を使用してｉｎｏｄｅファイルを検索し、適当なエントリにアクセスし、論理ｖｂｎを読み出す。次にファイルシステムは、その論理ｖｂｎを含むメッセージ構造をＲＡＩＤシステム２４０へ渡す。そして、論理ｖｂｎは、ディスク識別子、及びディスクブロック番号（ｄｉｓｋ，ｄｂｎ）にマッピングされ、ディスクドライバシステム２５０の適当なドライバへと送られる。ディスクドライバは、指定されたディスク１３０からｄｂｎをアクセスし、要求されたデータブロック（複数の場合も有り）をストレージシステムによる処理に備えてバッファキャッシュ１７０に読み出す。要求が完了すると、ストレージシステム（及び、オペレーティングシステム）は、ネットワーク１４０を介してクライアント１１０に返答を返す。

バックアップ管理モジュール２８４は、例えば、バックアップ作成を管理し、クライアントとの間で、バックアプオペレーションを実施するための情報をやりとりする。また、バックアップ管理モジュール２８４は、ファイルシステムのデータ重複解消（ｄｅｄｕｐ）モジュール２８６と協働し、本発明の一実施形態に従って、ＰＣＰＩを使用しているストレージシステム１２０においてデータ重複解消を実施する。重複解消モジュール２８６は、ストレージシステムによって記憶される重複データブロックの量を減らすために、１以上のデータ重複解消手順を実施する。例示的実施形態として、データ重複解消モジュールは例えば、２００５年４月１３日に出願された「Method and Apparatus for Identifying and Eliminating Duplicate Data Blocks and Sharing Data Blocks in a Storage System」と題するLing Zheng他による米国特許出願第１１／１０５，８９５号に記載されているデータ重複解消技術を実施する場合があり、この文献の内容は、参照により本明細書に援用される。ただし、代替実施形態では、さらに他の重複解消技術を更に使用したり、別の重複解消技術を使用する場合もある。

なお、ストレージシステムにおいて受信されたクライアント要求に対し、データストレージアクセスを実施するために必要となるストレージオペレーティングシステムを貫通する上記のソフトウェア「パス」は、代替としてハードウェアで実施してもよい。すなわち、本発明の代替実施形態において、ストレージアクセス要求データパスは、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は特定用途向け集積回路（ＡＳＩＣ）の中に埋め込まれた論理回路として実施される場合がある。この種のハードウェア実施形態によれば、クライアント１１０により発行された要求に応答してストレージシステム１２０によって提供されるストレージサービスの性能を向上させることができる。また、本発明の更に別の代替実施形態として、アダプタ１２６、１２８の処理要素は、パケット処理オペレーション、及びストレージアクセスオペレーションの負荷の一部、又は全部をプロセッサ１２２から取り除くように構成される場合があり、それによって、システムによって提供されるストレージサービスの処理能力は、向上する場合がある。当然ながら、本明細書に記載する種々のプロセス、アーキテクチャ、及び手順は、ハードウェアで実施しても、ファームウェアで実施しても、ソフトウェアで実施してもよい。

本明細書では、「ストレージオペレーティングシステム」という用語は通常、ストレージシステムにおいてストレージ機能を実施するためのコンピュータ実行可能コードを意味し、例えば、データアクセスを管理し、ファイルサーバの場合には、ファイルシステムセマンティックを実施することもあるコンピュータ実行可能コードを意味する。その意味で、Ｄａｔａ ＯＮＴＡＰソフトウェアは、マイクロカーネルとして実施されるストレージオペレーティングシステムであって、かつＷＡＦＬファイルシステムセマンティックを実施し、データアクセスを管理するためのファイルシステム２８０を含む、そのようなストレージオペレーティングの一例である。また、ストレージオペレーティングシステムは、ＵＮＩＸやＷｉｎｄｏｗｓ ＸＰのような汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施してもよいし、あるいは、本明細書に記載するようなストレージアプリケーションに合わせて構成された構成変更機能を備えた汎用オペレーティングシステムとして実施してもよい。

さらに、当業者には分かるように、本明細書に記載する本発明の技術は、いかなるタイプの特殊目的のコンピュータ（例えばファイルサーバ、ファイラ、又はマルチプロトコルストレージアプライアンス）にも、汎用のコンピュータにも適用することができ、例えば、ストレージシステム１２０として実施され、又はストレージシステム１２０を含むスタンドアロンのコンピュータ、あるいはその一部にも適用することができる。本発明とともに有利に使用されるストレージシステムアプライアンスの一例は、２００２年８月８日に出願された「Protocol Storage Appliance that Provides Integrated Support for File and Block Access Protocols」と題する米国特許出願第１０／２１５，９１７号に記載されている。また、本発明の教示は、種々のストレージシステムアーキテクチャに適合させることが可能であり、限定はしないが、例えば、ネットワーク・アタッチド・ストレージ環境、ストレージ・エリア・ネットワーク、あるいは、クライアントコンピュータやホストコンピュータに直接取り付けされたディスクアセンブリにも適用することが可能である。したがって、「ストレージシステム」という用語は、ストレージ機能を実施するように構成され、他の装置又はシステムに関連する何らかのサブシステムだけでなく、そのような構成も含むものとして広い意味で捉えなければならない。

Ｃ．オンディスク・ファイルシステム構造
例示的実施形態として、Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムでは、ファイル（又は、他のデータコンテナ）は、ディスク１３０への記憶に適したｉｎｏｄｅデータ構造として表現される。図３は、ｉｎｏｄｅ３００を示す略ブロック図である。ｉｎｏｄｅ３００は、メタデータ部３１０、及びデータ部３５０を有することが好ましい。各ｉｎｏｄｅ３００のメタデータ部３１０に記憶される情報はファイルを表し、例えば、ファイルのタイプ３１２（例えば、通常、ディレクトリ、仮想ディスクなど）、ファイルのサイズ３１４、ファイルのタイムスタンプ（アクセス、及び／又は変更）３１６、並びに、ファイルの所有者、例えばユーザＩＤ（ＵＩＤ３１８）、及びグループＩＤ（ＧＩＤ３２０）を含む。ただし、タイプフィールド３１２に規定されたファイル（ｉｎｏｄｅ）のタイプによって、各ｉｎｏｄｅのデータ部３５０の中身は、異なる解釈をされる場合がある。例えば、ディレクトリｉｎｏｄｅのデータ部３５０は、ファイルシステムによってコントロールされるメタデータを有する一方、通常ｉｎｏｄｅのデータ部は、ファイルシステムデータを有する場合がある。後者の場合、データ部３５０は、ファイルに関連するデータの表現物を含む場合がある。

通常オンディスクｉｎｏｄｅのデータ部３５０は、ファイルシステムデータ、又はポインタを含む場合があり、後者は、ファイルシステムデータを記憶するために使用されるディスク上の４ＫＢデータブロックを参照する。好ましくは、ディスク上のデータをアクセスするときにファイルシステムとＲＡＩＤシステム２４０の間の効率を向上させるために、各ポインタは論理ｖｂｎを含む。ｉｎｏｄｅのサイズには制限があるため（例えば、１２８バイト）、６４バイト以下のサイズのファイルシステムデータは、その全部が、そのｉｎｏｄｅのデータ部の中にに完全に表現される。一方、ファイルシステムデータのサイズが、６４バイトよりも大きく、且つ６４ＫＢ以下であった場合、ｉｎｏｄｅ（例えば、第１レベルｉｎｏｄｅ）のデータ部は、最大で１６個までのポインタを含み、各ポインタが、ディスク上の４ＫＢのデータブロックを参照する。

また、データのサイズが６４ＫＢよりも大きく、且つ６４メガバイト（ＭＢ）以下である場合、ｉｎｏｄｅ（例えば、第２レベルｉｎｏｄｅ）のデータ部３５０にある各ポインタは、１０２４個のポインタを有する間接ブロック（例えば、第１レベルブロック）を参照し、各ポインタが、ディスク上の４ＫＢデータブロックを参照する。６４ＭＢよりも大きなサイズのファイルシステムデータについては、ｉｎｏｄｅ（例えば、第３レベルｉｎｏｄｅ）のデータ部３５０にある各ポインタは、１０２４個のポインタを含む二重間接ブロック（例えば、第２レベルブロック）を参照し、さらに、各ポインタが、間接（例えば、第１レベル）ブロックを参照する。そして、その間接ブロックが、１０２４個のポインタを有し、各ポインタが、ディスク上の４ＫＢのブロックを参照する。ファイルをアクセスする場合、ファイルの各ブロックは、ディスク１３０からバッファキャッシュ１７０へロードされる場合がある。

オンディスクｉｎｏｄｅ（又は、ブロック）が、ディスク１３０からバッファキャッシュ１７０へロードするとき、それに対応するコア内構造が、オンディスク構造に埋め込まれる。例えば、ｉｎｏｄｅ３００の周りを囲む点線は、オンディスクｉｎｏｄｅ構造のコア内表現を示している。コア内構造は、オンディスク構造、及びメモリ上のデータ（ディスク上に無い）の管理に必要となる他の情報を記憶する一つのメモリブロックである。他の情報には、例えば、「ダーティ」ビット３６０がある。例えば、書き込みオペレーションによる命令に従って、ｉｎｏｄｅ（又はブロック）内のデータが更新／変更された後、変更されたデータは、ダーティビット３６０を使用して、「汚れた」ものとしてマーキングされ、その後、そのｉｎｏｄｅ（ブロック）をディスクに「フラッシュ」（記憶）できるようにする。ｉｎｏｄｅ、及びｉｎｏｄｅファイルを含む、ＷＡＦＬファイルシステムのコア内構造、及びオンディスクフォーマット構造については、１９９８年１０月６日に発行された「Method for Maintaining Consistent States of a File System and for Creating User-Accessible Read-Only Copies of a File System」と題するDavid Hitz他による米国特許第５，８１９，２９２号に開示、及び記載されている。

Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム（例えば、ＷＡＦＬファイルシステム）は、自分が有しているアクティブファイルシステムの「スナップショット」を生成する機能を有する場合がある。「アクティブファイルシステム」とは、データの書き込みと読み出しが両方とも可能なファイルシステムであり、より一般的に言えば、読み出しＩ／Ｏオペレーションと書き込みＩ／Ｏオペレーションのいずれにも応答するアクティブ記憶手段である。なお、「スナップショット」は、ネットワーク・アプライアンス，インコーポレイテッドの商標であり、本明細書では、永久的コンシステンシ・ポイント（ＣＰ）イメージを指して使用される。永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）とは、名前によるアクセスが可能な、或る時点におけるデータの空間保守的な読み出し専用イメージであり、何らかの過去の時点におけるそのデータ（例えば、ストレージシステム）の一貫性のあるイメージを提供する。具体的には、ＰＣＰＩは、ストレージデバイス（例えばディスク、又は他の永久的メモリ）に記憶されるアクティブファイルシステム、ファイル、又はデータベースのような記憶要素のある時点における表現であり、自分自身を他の時点において作成された他のＰＣＰＩから区別する名前、その他の識別子を有する。ＷＡＦＬファイルシステムの場合、ＰＣＰＩは、全てのメタデータを含めむ、ファイルシステムに関する全ての情報を有するアクティブファイルシステムイメージである。ＰＣＰＩは、イメージが作成された特定時点におけるアクティブファイルシステムに関する他の情報（メタデータ）を更に有する場合がある。本明細書では、ネットワークアプライアンスの商標権を損なうことなく、「ＰＣＰＩ」と「スナップショット」を交換可能に使用することができる。

Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、規則正しいスケジュールに基づいて一般に生成される複数のＰＣＰＩをサポートする場合がある。用語の一般性を制限することなく、各ＰＣＰＩは、例えば、アクティブファイルシステムに変更が加えられるのに従って、アクティブファイルシステムから段々と変化してゆくファイルシステムのコピーを意味する場合がある。ＷＡＦＬファイルシステムでは、アクティブファイルシステムが新たなディスク位置に書き込まれるときに、ＰＣＰＩは、その場に留まるため、アクティブファイルシステムは、ＰＣＰＩから変化する。各ＰＣＰＩは、所定の時点で作成された記憶要素（例えば、アクティブファイルシステム）の復元可能バージョンであり、上記のように、「読み出し専用」アクセスが可能で、かつ「空間保守的」である。空間保守的とは、複数のＰＣＰＩにおける記憶要素の共通部分が、同じファイルシステムブロックを共有することを意味する。種々のＰＣＰＩ間の創意は、余分なストレージブロックを必要とする。記憶要素の複数のＰＣＰＩは、各ＰＣＰＩがそれぞれディスク空間を消費する複数の独立したコピーではない。従って、ファイルシステムに対するＰＣＰＩの作成は、何もエンティティをコピーする必要がないため、即座に行われる。読み出し専用アクセス属性は、ＰＣＰＩが、アクティブファイルシステムにおいて単一の書き換え可能イメージに密接に結合されているため、ＰＣＰＩに変更を加えることは出来ないことを意味する。アクティブファイルシステム上のファイルと、ＰＣＰＩ上の同じファイルとの間のこの密接な結合により、複数の「同じ」ファイルを使用する必要性は無くなる。ＷＡＦＬファイルシステムの例として、ＰＣＰＩについては、ネットワーク・アプライアンスにより出版されたＴＲ３００２に、「File System Design for a NFS File Server Appliance」と題してDavid Hitz他により記載され、また、「Method for Maintaining Consistent Status of a File System and for Creating User-Accessible Read-Only Copies of a File System」と題するDavid Hitzによる米国特許第５，８１９，２９２号にも記載されており、これらはいずれも、参照により完全に説明されたものとして本明細書に援用される。

簡単に言えば、ＰＣＰＩは、アクティブファイルシステムと一緒にディスク上に記憶され、ストレージオペレーティングシステムからの要求に応じて、ストレージシステムのメモリにロードされる。ＰＣＰＩ、及びアクティブファイルシステムのオンディスク構成は、図４に示す例示的なファイルシステムｉｎｏｄｅ構造４００に関する以下の説明から理解できる。ファイルシステム情報（ｆｓｉｎｆｏ）ブロック４０２は、ファイルシステムに関連するｉｎｏｄｅファイルを表す情報を含むｉｎｏｄｅファイル４０５のｉｎｏｄｅを有する。例示的なファイルシステムｉｎｏｄｅ構造として、ｉｎｏｄｅファイル４０５のｉｎｏｄｅは、ｉｎｏｄｅファイル間接ブロック４１０を参照する（指し示す）ポインタを含む。ｉｎｏｄｅファイル間接ブロック４１０は、ｉｎｏｄｅファイルブロックを参照する一組のポインタを有し、各ｉｎｏｄｅファイルブロックは、ｉｎｏｄｅ４１７のアレイを含み、さらに、ｉｎｏｄｅ４１７は、間接ブロック４１９へのポインタを含む。間接ブロック４１９は、ファイルデータブロック４２０Ａ、４２０Ｂ、及び４２０Ｃへのポインタを含む。ファイルデータブロック４２０（Ａ〜Ｃ）はそれぞれ、例えば、４キロバイト（ＫＢ）のデータを記憶する能力を有する。

ファイルシステムが、自分が有するアクティブファイルシステムのＰＣＰＩを生成するとき、図５に示すように、ＰＣＰＩ ｆｓｉｎｆｏブロック５０２が生成される。ＰＣＰＩ ｆｓｉｎｆｏブロック５０２は、ｉｎｏｄｅファイル５０５のＰＣＰＩ ｉｎｏｄｅを含む。ｉｎｏｄｅファイル５０５のＰＣＰＩｉｎｏｄｅは、実質的に、ｉｎｏｄｅやブロックのような共通部分をアクティブファイルシステムとの間で共有しているファイルシステム４００のｉｎｏｄｅファイル４０５のｉｎｏｄｅの複製である。例えば、例示的なファイルシステム構造５００は、図４に示すように、ｉｎｏｄｅファイル間接ブロック４１０、ｉｎｏｄｅ４１７、間接ブロック４１９、及びファイルデータブロック４２０Ａ〜Ｃを含む。ユーザが、あるファイルデータブロックに変更を加えると、ファイルシステムは、その新たなデータブロックをディスクに書き込み、新たに作成されたブロックを指し示すようにアクティブファイルシステムを変更する。図６は、あるファイルデータブロックに変更が加えられた後の、例示的なｉｎｏｄｅファイルシステム構造６００を示している。この例では、ファイルデータブロック４２０Ｃに変更が加えられ、ファイルデータブロック４２０Ｃ´になっている。その結果、変更されたファイルデータブロックの中身は、例示的ファイルシステムの関数として、ディスク上の新たな位置に書き込まれる。新たな位置に書き込まれるため、間接ブロック６１９を書き換える必要がある。そして、間接ブロック６１９が書き換えられた結果、ｉｎｏｄｅ６１７も書き換える必要がある。同様に、ｉｎｏｄｅファイル間接ブロック６１０、及びｉｎｏｄｅファイル６０５のｉｎｏｄｅも、書き換える必要がある。

このように、或るファイルデータブロックに変更が加えられた後、ＰＣＰＩ ｉｎｏｄｅ５０５は、元のｉｎｏｄｅファイル間接ブロック４１０へのポインタを含み、さらに、元のｉｎｏｄｅファイル間接ブロック４１０が、ｉｎｏｄｅ４１７、及び間接ブロック４１０を通して、元のファイルデータブロック４２０Ａ、４２０Ｂ、及び４２０Ｃを指し示す。また、新たに書き込まれた間接ブロック６１９は、未変更のファイルデータブロック４２０Ａ、及び４２０Ｂへのポインタを含む。すなわち、アクティブファイルシステムのファイル内の未変更のデータブロックは、ＰＣＰＩファイル内の対応するデータブロックとの間で、アクティブファイルシステム上でＰＣＰＩファイルのものとは異なるものに変更されたデータブロックだけを共有する。

しかしながら、間接ブロック６１９は、アクティブファイルシステムの新たな構成を表す変更後のデータブロック４２０Ｃ´へのポインタをさらに含む。ｉｎｏｄｅファイル６０５に対し、新たな構造６００を表す新たなｉｎｏｄｅが決められる。なお、それらのブロックの再利用や上書きは、それらのブロックが全てのＰＣＰＩから開放されるまで、いずれかのＰＣＰＩブロック(例えば、５０５、４１０、及び４２０Ｃ）に記憶されるメタデータ（図示せず）によって防止される。従って、ｉｎｏｄｅファイル６０５のアクティブファイルシステムｉｎｏｄｅは、新たなブロック６１０、６１７、６１９、４２０Ａ、４２０Ｂ、及び４２０Ｃ´を指し示しているが、ＰＣＰＩが完全に開放されるまで、古いブロック５０５、４１０、及び４２０Ｃも維持される。

本発明の一実施形態によれば、バックアップオペレーションの際に、ストレージシステムの１以上のクライアントからの複数のボリューム、ファイルシステム、クオータツリー（ｑｔｒｅｅ）のようなデータ集合を合併し、ストレージシステム上の例えばボリュームのような単一のデータ集合の中に記憶することができる。合併により、複数のソースデータ集合を単一のエンティティとしてバックアップストレージシステム１２０上で管理することが可能になる。複数の集合を合併するように構成されたバックアップストレージシステム１２０の例示的ファイルシステム７００を図７に示す。この例示的実施形態では、クライアントの記憶されたファイルシステムを有するストレージシステムに関連するストレージボリュームに、ボリューム１というラベルが付けられている（７０５）。ボリューム７０５は、バックアップクライアント１〜３に関連するディレクトリ７１０〜７３０を含む。

バックアップオペレーションの際、バックアップストレージシステム１２０は、例えば、「System and Method for Managing a Plurality of Snapshots」と題する米国特許出願第１０／１０１，９０１号に記載のバックアップ／リストアオペレーションを実施することにより、各クライアントのファイルシステムを適当なディレクトリに複製する。従って、各クライアントディレクトリは、クライアントに関連するファイルシステムの、実質的にルート、すなわち最上位ディレクトリになる。クライアントディレクトリ７１０、７２０、及び７３０は、クライアントファイルシステムのレプリカ、すなわちバックアップを含む。例えば、ディレクトリ７１０は、クライアント１（７１５）に関連するファイルシステムのバックアップコピーを記憶する。同様に、クライアント２ディレクトリ７２０は、クライアント２（７２５）に関連するファイルシステムのバックアップコピーを記憶し、クライアント３ディレクトリ７３０は、クライアント３（７３５）に関連するファイルシステムのバックアップコピーを記憶する。ファイルシステム７００の単一のＰＣＰＩを生成することにより、バックアップストレージシステム１２０は、各クライアントについて個別のボリュームを予約することなく、クライアントが有しているファイルシステムのそれぞれのＰＣＰＩを効率的に生成した。

Ｄ．ＰＣＰＩを使用しているストレージシステムのためのデータ重複解消
本発明は、１以上の永久的コンシステンシ・ポイント・イメージ（ＰＣＰＩ）を使用しているストレージシステムにおけるデータ重複解消を管理するシステム、及び方法を提供する。具体的には、ＰＣＰＩをバックアップの形で使用しているバックアップストレージシステムにおいて、バックアップ管理モジュールは、データ重複解消モジュールとの間で情報をやりとりし、バックアプストレージシステム中の１以上の、例えばボリュームのようなデータ集合に対し、データ重複解消を実施するように構成される。動作として、バックアップ管理モジュールは、ソースストレージシステム（「ソース」）から転送要求を受信し、それに応じて、ソースからバックアップストレージシステム上の宛先ボリュームへのデータ集合の転送を開始する。複数の転送を同時に実施することにより、複数のソースを同じ宛先ボリュームへバックアップする場合もある。所与の宛先ボリュームへの最後のデータ転送が完了すると、バックアップ管理モジュールは、ファイルシステムと協働し、宛先ボリュームの第１のＰＣＰＩを生成する。次に、バックアップ管理モジュールは、データ転送中に生成された一時ファイルのクリーンアップオペレーションを実施し、その後、宛先ボリュームの第２のＰＣＰＩを生成する。次に、バックアップ管理モジュールは、第３のＰＣＰＩ、すなわち目標ＰＣＰＩを生成し、その後、その目標ＰＣＰＩを１以上のクライアントへエキスポートする。

目標ＰＣＰＩが生成されると、転送要求は完了したものとみなされ、転送されたデータの、バックアップストレージシステムのクライアントによるアクセスが許可される。また、目標ＰＣＰＩが生成されると、バックアップ管理モジュールは、データ重複解消モジュールに警告を発し、目標ＰＣＰＩに含まれるデータの重複解消を開始させる。データ重複解消モジュールは、同一のデータブロックを唯一つだけ有する状態になるまで、同一のデータブロックを識別し、削除することにより、データ重複解消手順を実施する。データ重複解消手順が完了すると、バックアップストレージシステムのアクティブファイルシステムの重複解消は完了するが、エキスポートされた目標ＰＣＰＩは、依然として重複解消されていない。これに応答して、バックアップ管理モジュールは、変更された目標ＰＣＰＩを生成し、エキスポートする。その後、以前の目標ＰＣＰＩは削除することができ、それによって、ファイルシステムの状態のエキスポートされたＰＣＰＩのイメージは、重複解消済み状態へと移行される。

図８は、本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムにおけるデータ重複解消を管理する手順８００のステップの詳細を示すフロー図である。手順８００は、ステップ８０５から開始され、ステップ８１０へと進み、そこで、バックアップ管理モジュール２８４は、１以上のバックアップクライアントから転送要求を受信し、それに応じて、ソースからの転送を開始する。すなわち、クライアント（すなわち、ソース）は、新たなバックアップオペレーションを開始すべきことを知らせる要求をバックアップ管理モジュールへ送信することができる。これに応答し、バックアップ管理モジュールは、転送されたデータをソースから受信し、ストレージシステムが有するファイルシステムの中にバックアップを生成する。本明細書では、「ソース」とは、ファイルシステム、ボリューム、及び／又はｑｔｒｅｅといったデータ集合をバックアップのために、ストレージシステム上の同じ宛先ボリュームへ転送する１以上のクライアントを意味する。データ転送は、ステップ８１５において最後のデータ転送が完了するまで続けられる。なお、データ転送に要する時間は、様々に異なる場合がある。すなわち、例えば、単一のソースは、複数のデータ集合を転送する場合があり、各転送は、異なる量の時間を消費する場合がある。最後のデータ転送が完了すると、ステップ８３０において、バックアップ管理モジュール２８４は目標ＰＣＰＩを生成し、エキスポートする。目標ＰＣＰＩをエキスポートすることは、バックアップ管理モジュール２８４が、目標ＰＣＰＩをストレージシステムのクライアントから見える状態にし、アクセス可能な状態にすることを意味する。

目標ＰＣＰＩが生成され、エキスポートされると、転送は完了したものとみなされ、データは、ストレージシステムからアクセス可能な状態にされる。ステップ８３５において、バックアップ管理モジュール２８４は、重複解消モジュール２８６に警告を発し、宛先ボリュームへ転送されたデータの重複解消を開始させる。本発明の一実施形態によれば、重複解消モジュールは、「Method and Apparatus for Identifying and Eliminating Duplicate Data Blocks and Sharing Data Blocks in a Storage System”と題するLing Zheng他による上記米国特許出願第１１／１０５，８９５に記載されている重複解消技術を使用する場合がある。ただし、本発明の代替実施形態によれば、いかなるデータ重複解消技術を使用してもよい。重複解消完了時点で、各ブロックは重複しないものでなければならず、すなわち、同一のデータを有する２つのデータブロックがあってはならない。

なお、重複解消モジュール２８６は、もし、他の重複解消手順が進行中であることを検出した場合、それに応答して、第１の重複解消プロセスが完了する時まで、第２の重複解消プロセスを開始しない。重複解消手順が完了すると、ステップ８４０において、重複解消モジュール２８６はバックアップ管理モジュール２８４に警告を発し、完了を伝える。ステップ８４５において、バックアップ管理モジュール２８４は、次の転送が開始されたか否かを判定する。すなわち、バックアップ管理モジュール２８４は、重複解消手順の進行中にソースからの第２の転送が開始されたか否かを判定する。ステップ８５０において、何も転送が行われていなければ、手順８００はステップ８５５へと分岐し、バックアップ管理モジュール２８４は、変更された目標ＰＣＰＩを生成し、エキスポートする。さらに、バックアップ管理モジュール２８４は、目標ＰＣＰＩを削除し、その後、手順８００はステップ８６０において終了する。一方、ステップ８５０において転送が開始されていた場合、手順８００はステップ８６０へと分岐し、終了する。

図９は、本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムにおけるＰＣＰＩの管理を示す図である。まず、ステップ９０５において、バックアップオペレーション、例えば、ストレージシステムのバックアップ１、バックアップ２、及びバックアップ３が開始される。これらのバックアップオペレーションに要する時間は、異なる場合がある。例えば、バックアップ２は、バックアップ１やバックアップ３の完了に要する時間よりもはるかに長い時間を完了までに要する場合がある。手順８００を参照して上で説明したように、９１０の時点で、バックアップオペレーションの最後の転送は完了し、９２０の時点で、目標ＰＣＰＩが生成される。従って、９２０の時点で、目標ＰＣＰＩはクライアントにエキスポートされ、クライアントからアクセスできる状態にされる。目標ＰＣＰＩが生成されると、重複解消手順が開始され、それが完了すると、ステップ９２５で、変更された目標ＰＣＰＩが生成される。この変更されたＰＣＰＩを生成するときに、元の目標ＰＣＰＩは削除され（開放され）、それによって重複解消状態へと移行する。

図１０は、本発明の一実施形態による、ＰＣＰＩを使用しているストレージシステムにおけるＰＣＰＩの管理を示す図である。環境９００と同様に、バックアップオペレーションの第１のセットは、９０５の時点で開始され、対応するデータ転送は、９１０の時点で終了する。次に、目標ＰＣＰＩが生成され、９２０の時点で、データ重複解消手順が開始される。データ重複解消手順は、９２５の時点で完了する。一方、重複解消手順の終了より前の１００５の時点で、バックアップオペレーションの第２のセットが開始される。この第２のセットに対応するデータ転送は、１０１０の時点で終了する。１０２０の時点で、第２の目標ＰＣＰＩが生成され、第２のデータ重複解消が行われる。第２のデータ重複解消が完了すると、１０２５の時点で、変更された目標ＰＣＰＩが生成される。この時点で、第２の目標ＰＣＰＩは消去されるが、９２０の時点で生成された元の目標ＰＣＰＩは維持される。

図１１は、本発明の代替実施形態による、ＰＣＰＩを使用しているストレージシステムにおいてデータ重複解消を実施する手順１１００のステップを詳細に示すフロー図である。このような代替実施形態は、長い保有期間を有する目標ＰＣＰＩが生成され、その目標ＰＣＰＩを削除することができない場合に使用されることがある。手順１１００は、ステップ１１０５から開始され、ステップ１１１０へ進み、そこで、バックアップ管理モジュール２８４は、１以上のバックアップクライアントから転送要求を受信し、それに応じて、ソースからの転送を開始する。すなわち、クライアント（すなわち、ソース）は、新たなバックアップオペレーションを開始すべきことを知らせる要求をバックアップ管理モジュールへ送信することができる。これに応答し、バックアップ管理モジュールは、ソースから送信されたデータを受信し、ストレージシステムが有しているファイルシステムの中に、バックアップを生成する。データ転送は、最後の転送がステップ１１５で完了するまで継続される。

最後のデータ転送が完了すると、次にバックアップ管理モジュール２８４は、ステップ１１３０において、重複解消モジュール２８６に警告を発し、宛先ボリュームの目標ＰＣＰＩの重複の重複解消を開始させる。重複解消手順が完了すると、ステップ１１３５において、重複解消モジュール２８６は、バックアップ管理モジュール２８４に警告を発し、完了を伝える。次に、バックアップ管理モジュール２８４は、ステップ１１４０において、目標ＰＣＰＩを生成し、エキスポートする。目標ＰＣＰＩが生成され、エキスポートされると、転送は完了したものとみなされ、データは、ストレージシステムからアクセス可能な状態にされる。そして、手順はステップ１１４５において終了する。上記のように、この代替実施形態は、ＰＣＰＩが、（実質的に）長い保有期間を有する場合に使用されることがある。手順１１００は、重複解消手順が完了するまで目標ＰＣＰＩを生成しないことにより、確実に、重複解消されたデータだけが、目標ＰＣＰＩに記憶されるようにする。

図１２は、手順１１００を参照して上で説明したような代替実施形態による、ＰＣＰＩの管理を示す図である。１２１０の時点で最後のデータ転送が完了すると、それに応じて、１２０５の時点で、バックアップオペレーションは解消される。データ重複解消手順は、この時点で開始される。これが、手順８００を参照して上で説明した実施形態と本実施形態との違いである。重複解消手順が完了すると、１２２０の時点で、目標ＰＣＰＩが生成される。従って、環境１２００において、クライアントは、データの重複解消が済むまで、データをアクセスすることができない。このようにする必要性は、例えば、長い保有期間を有するＰＣＰＩが生成される場合に発生する。

図１３は、本発明の一実施形態によるＰＣＰＩの管理を示す図である。実施形態によっては、バックアップオペレーションを含むデータ転送が、同じ時点で開始されない場合がもる。すなわち、環境１３００では、バックアップオペレーションは、１３０５の時点で開始されるが、全てのバックアップが、その時点でデータ転送を開始するとは限らない。１３１０の時点で、目標ＰＣＰＩが生成され、重複解消手順が開始される。重複解消手順が完了すると、１３１５の時点で、変更された目標ＰＣＰＩが生成され、目標ＰＣＰＩは削除される。

図１４は、本発明の代替実施形態による、重なり合うデータ転送によるＰＣＰＩの管理を示す図である。環境１３００と同様に、まず１３０５の時点で、バックアップオペレーションに関連する３つのデータ転送の第１のセットが開始され、それが、１３１０の時点で、第１の目標ＰＣＰＩの生成とともに終了する。重複解消手順は１３１０の時点でも開始される。一方、データ転送の第１のセットが完了する前に、バックアップ４、５、及び６が開始される。後者３つの転送は、１４０５の時点で終了し、第２の目標ＰＣＰＩが生成される。しかしながら、第２の目標ＰＣＰＩが生成されたとき、第１の重複解消手順は依然として進行中である。

したがって、１４１０の時点で第１の重複解消手順が完了したときに、例えば、バックアップ４が、バックアップ１のインクリメンタルバックアップである場合のように、
新たなバックアップのうちのいずれかが、インクリメンタルバックアップでない限り、
変更された目標ＰＣＰＩは生成されない。代わりに、第２の重複解消手順が開始され、１４１５の時点で第２の重複解消手順が完了すると、変更された第２の目標ＰＣＰＩが生成され、第２の目標ＰＣＰＩ（１４０５の時点で前回生成されたもの）は削除される。

もう一度まとめると、本発明は、１以上の永久的コンシステンシー・ポイント・イメージ（ＰＣＰＩ）を使用しているストレージシステムにおけるデータ重複解消を管理するシステム、及び方法を提供する。具体的には、バックアップの一形態としてＰＣＰＩを使用しているバックアップストレージシステムにおいて、バックアップ管理モジュールは、データ重複解消モジュールとの間で情報をやりとりし、バックアップストレージシステム内の例えばボリュームやファイルシステムのような１以上のデータ集合に対し、データ重複解消を実施するように構成される。動作として、バックアップ管理モジュールは、ソースストレージシステムから転送要求を受信すると、それに応じて、ソースからバックアップストレージシステム上の宛先ボリュームへのデータ集合の転送を開始する。最後のデータ転送が完了すると、バックアップ管理モジュールは次に、目標ＰＣＰＩを生成し、その後、その目標ＰＣＰＩを１以上のクライアントへエキスポートする。

目標ＰＣＰＩが生成されると、転送要求は完了したものとみなされ、転送されたデータは、バックアップストレージシステムのクライアントからアクセス可能な状態にされる。さらに、目標ＰＣＰＩが生成されると、バックアップ管理モジュールは、データ重複解消モジュールに警告を発し、目標ＰＣＰＩに含まれるデータの重複解消を開始させる。データ重複解消モジュールは、同一のデータブロックの中から一つだけを有する状態になるまで、同一のデータブロックを識別し、削除することにより、重複解消手順を実施する。例えば、この重複解消手順は、目標ＰＣＰＩをエキスポートする宛先となるクライアントにとって透過的に行われる。重複解消手順が完了すると、バックアップ管理モジュールは、変更された目標ＰＣＰＩを生成し、エキスポートする。その後、以前の目標ＰＣＰＩは削除することができ、それによって、ファイルシステムの状態のエキスポートされたＰＣＰＩが有するイメージを重複解消済み状態に移行させる。従って、本発明によれば、非同期ミラーの透過的な重複解消が可能となり、同時に、宛先ボリュームを読み出し専用レプリカとしてエキスポートすることが可能となり、すなわち、重複解消手順が実行されている最中に、目標ＰＣＰＩをクライアントから使用可能にすることが可能となる。

なお、本発明は、ソースがストレージシステムからなるバックアップストレージシステム環境を例として書かれている。しかしながら、本発明の原理は、異なるソースシステムを有する環境においても使用することができる。例えば、ソースは、データベース管理システムや電子メールサーバなどのようなアプリケーションを実行しているコンピュータから成る場合もある。ソースは、自分の有しているデータのＰＣＰＩを生成し、それを宛先へ転送する場合があり、そこで目標ＰＣＰＩが生成され、エキスポートされる。次に、重複解消プロセスが実施され、それが終了すると、変更されたＰＣＰＩが生成され、エキスポートされる。そのような複製は、災害復旧やフェイルオーバオペレーションなどに使用されることがある。

また、本明細書の説明は、ストレージ重複解消を例として書かれているが、本発明の原理は、通信リンク上での重複解消を提供するためにも使用される場合がある。そのような代替実施形態では、送信側システムは、データの伝送に使用される帯域幅の大きさを最小限に抑えるために、上記のデータ重複解消技術を実施する場合がある。このような通信ベースの重複解消は、例えば、バックアップ階層が規定され、データが第１のストレージシステムへバックアップされ、それがさらに第２のストレージシステムへとバックアップされるような場合に発生する。そのような場合、第１のストレージシステムに対する重複解消の結果、第２のストレージシステムへのその後のバックアップオペレーションにおいて消費される帯域幅が低減される。

上記の説明は、本発明の特定の幾つかの実施形態に関するものである。しかしながら、当業者には明らかなように、それらの実施形態の利点の一部、又は全部を維持しながらも、記載した実施形態に対して種々の変形や変更を施すことが可能である。例えば、本発明の教示は、当然ながら、ソフトウェア（コンピュータ上で実行されるプログラム命令を含むコンピュータ読取可能媒体を含む）でも、ハードウェアでも、ファームウェアでも、あるいはそれらの組み合わせでも実施することが可能である。さらに、本明細書の説明は、ファイルシステムを例として書かれているが、本発明は、ＬＵＮ、及び／又は他のブロックベースのストレージのようなファイルシステム以外のストレージにも使用することが可能である。従って、本明細書の説明は単なる例として捉えるべきものであり、本発明の範囲を制限する意図はない。従って、添付の特許請求の範囲の目的は、そのような変形や変更も、本発明の真の思想、及び範囲に含めることにある。

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