JP2004038928A - ２つのスナップショット間の変化を判定して宛先スナップショットに送信するシステム及び方法 - Google Patents

Abstract

【課題】スナップショット複製手段の汎用性及び有用性を向上させる。
【解決手段】ソースファイルシステムの２ハ゛ーシ゛ョンのスナッフ゜ショットを構成するフ゛ロックのスキャン（スキャナによる）を利用して、各スナッフ゜ショットの論理ファイルフ゛ロック索引のスキャンの際に識別されたフ゛ロックホ゛リューム番号の差異により変更されたフ゛ロックを識別することで、ソースファイルシステムスナッフ゜ショットの変化を宛先の複製ファイルシステムに遠隔非同期複製すなわちミラーリンク゛するためのシステム及び方法。ファイルに関するフ゛ロックのツリーを調べ、ハ゛ーシ゛ョン間で変更のないホ゜インタはハ゛イハ゜スして下方へ進み、ツリーの階層の変化を識別する。そしてこれらの変更を宛先ミラーすなわち複製スナッフ゜ショットに送信する。宛先では、ソース変更を用いて宛先スナッフ゜ショットを更新する。既に宛先上に存在するあらゆる消去または変更されたｉｎｏｄｅは、テンホ゜ラリテ゛ィレクトリすなわち「一時」テ゛ィレクトリに移動され、再利用する場合、再構築された複製スナッフ゜ショットテ゛ィレクトリに再リンクされる。
【選択図】　図１０

Description

【０００１】
【発明の属する技術分野】
本発明はファイルサーバを用いたデータの記憶に関し、詳しくは遠隔の記憶場所に記憶されたデータのネットワークを介したミラーリングまたは複製に関する。
【０００２】
【従来の技術】
ファイルサーバは、ディスク等の記憶装置上での情報の編成に関するファイルサービスを提供するコンピュータである。ファイルサーバまたはファイラーには、ディスク上で情報をディレクトリ及びファイルの階層構造として論理的に編成するためのファイルシステムを実施するストレージオペレーティングシステムが含まれる。「ディスク上」の各ファイルは、ディスクブロック等のデータ構造の集まりとして実現され、情報を格納するように構成される。一方、ディレクトリは、他のファイル及びディレクトリに関する情報を格納する特別な形態のファイルとして実現される。
【０００３】
ファイラーは、クライアント／サーバ形態の情報配送に従って動作するようにさらに構成され、多数のクライアントがファイラー等のサーバ上に格納されたファイルにアクセスできるようになっている。この形態の場合、クライアントは、直接接続や、ポイント・ツー・ポイントリンク、共用ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）またはインターネット等の公衆網上で実施される仮想施設ネットワーク（ＶＰＮ）等のコンピュータネットワークを介してファイラーに「接続」するコンピュータ上で、データベースアプリケーション等のアプリケーションを実行している場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージを（パケットの形で）ファイラーに発行することによって、ファイルシステムのサービスをファイラーに要求することができる。
【０００４】
一般的なタイプのファイルシステムは「定位置書き込み」ファイルシステムであり、その一例はバークレイ・ファーストファイルシステムである。「ファイルシステム」はディスク等の記憶装置上のデータ及びメタデータの構造を一般に意味し、ファイルシステムによってそれらのディスクに対するデータの読み書きが可能になる。定位置書き込みファイルシステムの場合、ｉｎｏｄｅやデータブロック等のデータ構造のディスク上での位置が通常、固定になっている。ｉｎｏｄｅはファイルに関するメタデータ等の情報を記憶するのに用いられるデータ構造であり、データブロックはそのファイルの実際のデータを記憶するのに用いられるデータ構造である。ｉｎｏｄｅに保持される情報には、例えばそのファイルの所有者、そのファイルのアクセス権、そのファイルのサイズ、そのファイルのタイプ及びデータブロックのディスク上の位置に対する参照などが含まれる。ファイルデータの位置に対する参照は、ポインタとしてｉｎｏｄｅに設けられ、そのファイルのデータ量に応じて、間接ブロックの参照、即ちデータブロックへの参照をさらに含む場合もある。ｉｎｏｄｅ及びデータブロックに対する変更は、固定位置書き込みファイルシステムに従って「定位置」で行なわれる。ファイルの更新がそのファイルのデータ量を超えるものである場合、さらにデータブロックが割り当てられ、そのデータブロックを参照するように適当なｉｎｏｄｅが更新される。
【０００５】
他のタイプのファイルシステムとしては、ディスク上のデータを上書きしないＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムがある。ディスクからそのディスク上のデータブロックがメモリに取得され（読み出され）、新たなデータで汚される場合、そのデータブロックがディスク上の新たな位置に格納される（書き込まれる）ので、書き込み効率が最適になってる。Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上で実質的に連続的に配置されるように、まず最適なレイアウトを推定する。この最適なレイアウトによって、特にディスクに対するシーケンシャル読み出し処理に関して、効率的なアクセス処理が可能になる。ファイラー上で動作するように構成されたＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手できるＷｒｉｔｅ　Ａｎｙｗｈｅｒｅ　Ｆｉｌｅ　Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムである。ＷＡＦＬファイルシステムは、ファイラー及び関連ディスクストレージのプロトコルスタック全体のうちの一部としてマイクロカーネル内で実施される。このマイクロカーネルは、ネットワークアプライアンス社のＤａｔａ　ＯＮＴＡＰストレージオペレーティングシステムの一部として提供され、ネットワーク取り付けされたクライアントからのファイルサービス要求を処理する。
【０００６】
本明細書で用いられるように「ストレージオペレーティングシステム」という用語はデータアクセスを管理するコンピュータ上で実行可能なコンピュータ実行可能コードを意味し、ファイラーの場合、このコードはカリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手可能なＤａｔａ　ＯＮＴＡＰ（Ｒ）ストレージオペレーティングシステム等のファイルシステムセマンティックを実施するものであり、Ｄａｔａ　ＯＮＴＡＰストレージオペレーティングシステムはマイクロカーネルとして実施され、Ｗｒｉｔｅ　Ａｎｙｗｈｅｒｅ　Ｆｉｌｅ　Ｌａｙｏｕｔ（ＷＡＦＬ（Ｒ））ファイルシステムを実現する。ストレージオペレーティングシステムは、ＵＮＩＸ（Ｒ）やＷｉｎｄｏｗｓ（Ｒ）　ＮＴ等の汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施することもできるし、本明細書に記載するようなストレージアプリケーションとして構成された設定可能な機能を有する汎用オペレーティングシステムとして実施することもできる。
【０００７】
ディスクストレージは通常、ストレージ空間の全体的な論理的配置を定義する、物理的記憶ディスクを含む１以上のストレージ「ボリューム」として実施される。現在利用可能なファイラー実施形態は、多数の個別のボリューム（例えば１５０以上）を使用することができる。各ボリュームにはそのボリュームに固有のファイルシステムが関連付けられ、その意味で、ボリュームとファイルシステムは一般に同義語として用いられる。ボリューム内のディスクは通常、１以上のグループのＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ（Ｉｎｅｘｐｅｎｓｉｖｅ）　Ｄｉｓｋｓ）に編成される。ＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所定数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ化されたデータに関するパリティ情報を適当にキャッシュすることによって、データ記憶の信頼性／完全性を向上させている。ＷＡＦＬファイルシステムの一例では、ＲＡＩＤ４実施形態が有利に用いられている。この実施形態では、１グループのディスクにわたってデータをストライピングし、ＲＡＩＤグループのうちの選択されたディスク内で個別にパリティをキャッシュする必要がある。本明細書に記載するように、ボリュームは通常、ＲＡＩＤ４または同等の高信頼性の実施形態に従って配置された、少なくとも１台のデータディスク及び１台の関連パリティディスク（データ／パリティの場合もある）パーティションを含む。
【０００８】
ファイラー、ファイラーに関連するディスク、または、ストレージインフラストラクチャの何らかの部分に故障が発生したときの信頼性を向上させ、災害普及を容易にするため、基礎的データ及び／又は該データを編成するファイルシステムのうちのいくらか又は全部を「ミラーリング」すなわち複製することが一般的である。例えばミラーは、離れたサイトに作成及び格納され、主要な格納場所やそのインフラストラクチャに真の災害（例えば洪水、停電、戦争活動など）が発生した際の復元の可能性を向上させる。ミラーは、ファイルシステムに対する最新の変更を把握するため、管理者によって設定された所定の時間間隔で更新されるのが一般的である。更新の一般的な一形態では、ｉｎｏｄｅとブロックで構成されるストレージサイトのアクティブファイルシステムを取り込み、ネットワーク（周知のインターネット等）を介して概して「スナップショット」を遠隔のストレージサイトに送信する、「スナップショット」プロセスを使用する。一般に、スナップショットは、ある時点でのファイルシステムのイメージ（通常は読み出し専用）であり、アクティブファイルシステムと同じ一次記憶装置に格納され、アクティブファイルシステムのユーザがアクセスできるようになっている。「アクティブファイルシステム」は、現在の入出力処理が向けられている対象となるファイルシステムを意味する。一連のディスク等の一次記憶装置はアクティブファイルシステムを格納するものであり、テープドライブ等の二次記憶装置はアクティブファイルシステムのバックアップを格納するために用いられる。
【０００９】
スナップショットを作成した後、起こり得る災害復旧に備えてその時点で作成されたスナップショットを残し、アクティブファイルシステムが再確立される。スナップショットを作成するたびに古いアクティブファイルシステムが新たなスナップショットになるので、新たなアクティブファイルシステムは何らかの変更を記録し続ける。様々な時間ベースの基準及びその他の基準に応じて、所定数のスナップショットが維持される。スナップショットを作成する処理の詳細については、「ＩＮＳＴＡＮＴ　ＳＮＡＰＳＨＯＴ」と題したＢｌａｋｅ　Ｌｅｗｉｓ他による米国特許出願第０９／９３２５７８号明細書に記載されており、この出願はここで参照することにより完全に説明したものとして本明細書に取り込まれる。また、ＷＡＦＬファイルシステムに固有のＳｎａｐｓｈｏｔ（Ｒ）機能については、ネットワークアプライアンス社が発行している「Ｆｉｌｅ　Ｓｙｓｔｅｍ　Ｄｅｓｉｇｎ　ｆｏｒ　ＮＦＳ　Ｆｉｌｅ　Ｓｅｒｖｅｒ　Ａｐｐｌｉａｎｃｅ」と題したＤａｖｉｄ　Ｈｉｔｚ他によるＴＲ３００２、及び、同所有者の「ＭＥＴＨＯＤ　ＦＯＲＭＡＩＮＴＡＩＮＩＮＧ　ＣＯＮＳＩＳＴＮＴ　ＳＴＡＴＥＳ　ＯＦ　Ａ　ＦＩＬＥ　ＳＹＳＴＥＭ　ＡＮＤ　ＦＯＲ　ＣＲＥＡＴＩＮＧ　ＵＳＥＲ−ＡＣＣＥＳＳＩＢＬＥ　ＲＥＡＤ−ＯＮＬＹ　ＣＯＰＩＥＳ　ＯＦ　Ａ　ＦＩＬＥ　ＳＹＳＴＥＭ」と題したＤａｖｉｄ　Ｈｉｔｚ他による米国特許第５８１９２９２号明細書にさらに詳しい説明があり、これらはここで参照することにより取り込まれる。
【００１０】
ファイルシステムの大きさが数十ギガバイトや数百ギガバイト（数テラバイトと同じ）に及ぶ場合、ネットワークを介してファイルシステム全体をリモート（宛先）サイトに完全に複製することは、かなり不便である。遠隔地にデータ複製するためのこの完全バックアップ方法は、ネットワークの帯域幅に激しい負担をかける場合があり、複製先と複製元の両方ファイラーの処理能力にも負担をかける場合がある。一解決方法として、スナップショットをファイルシステムボリュームのうちの変更を受けた部分のみに制限するということが行なわれている。従って、図１は従来技術によるボリュームベースのミラーリングを示すものであり、この図において、複製元ファイルシステム１００はネットワークリンク１０４を介して宛先記憶サイト１０２（サーバとそれに取り付けられた記憶装置で構成される。図示せず）に接続されている。宛先１０２は、管理者によって設定された所定の時間間隔で周期的にスナップショットの更新を受信する。これらの時間間隔は、帯域幅、データの重要性、変更の頻度、及び、ボリューム全体のサイズ等を含む様々な基準をもとにして選択される。
【００１１】
簡単にまとめると、ソースは、時間をあけて、そのボリュームの１対のスナップショットを作成する。これらのスナップショットは、データをファイラーの不揮発性メモリに送信する送信処理の部分で作成することができ、あるいは他の手段によって作成することもできる。「新たな」スナップショット１１０は、そのボリュームのアクティブファイルシステムの最新のスナップショットである。「古い」スナップショット１１２は、そのボリュームの古いスナップショットであり、宛先のミラーに複製されているファイルシステムイメージに一致するはずのものである。注意して欲しいのは、ファイルサーバは、新たなスナップショット１１２の作成が終われば、ファイルサービス要求に対する作業を自由に続けられるということである。この新たなスナップショットは、現在のボリューム状態を完全に表現するものではなく、その時刻に至るまでの活動状態のチェックポイントとして働くものである。相違検出器１２０は古いスナップショットと新たなスナップショットを調べる。具体的には、相違検出器は、各スナップショットのブロックのリストを１ブロックづつ検査して、そこに配置されているブロック同士を比較する。Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの場合、スナップショットがブロックを参照している限りそのブロックは再利用されないので、データの変更は新たなブロックに書き込まれる。変更が確認された場合（データを意味する「×」の存在または不在で図示する）、相違検出器１２０は、図２に示す判断処理２００によってそのデータを宛先１０２へ送信するか否かを判定する。この判断処理２００は、古いブロックと新しいブロックとを次のような手順で比較する。（ａ）新／旧ブロック対１３０のように古いブロックにも新しいブロックにもデータがない場合（２００の場合）、転送可能なデータはない。（ｂ）新／旧ブロック対１３２のように古いブロックにはデータがあるが新しいブロックにはデータがない場合（２０４の場合）、そのようなデータは転送が済んでいるので（新たな宛先スナップショットポインタはいずれもそのデータを無視するので）、新たなブロック状態は転送しない。（ｃ）新／旧ブロック対１３４のように古いブロックと新たなブロックとの両方にデータが存在する場合（２０６の場合）、何も変更がなされていないので、そのブロックデータは既に前のスナップショットに転送されている。（ｄ）最後に、新／旧ブロック対１３６のように古いブロックにはデータがないが新たなブロックにはデータがある場合（２０８の場合）、変更されたデータブロックをネットワークを介して転送し、変更されたブロック１４２のように、宛先の変更されたボリュームスナップショット集合１４０の一部になるようにする。例示のＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステム構成の場合、これらの変更されたブロックは、ストレージアレイの新たな未使用の位置に書き込まれる。変更されたブロックがすべて書き込まれると、基礎ファイルシステム情報ブロック、すなわち、新たなスナップショットのルートポインタが宛先に送信される。このファイルシステム情報ブロックが宛先に送信されると、前のファイルシステム情報を置き換えて変更されたブロック構造を指し示すようにすることにより、宛先のファイルシステム全体が更新される。この時点で、変更が宛先ボリュームスナップショットの最新の差分更新として送信される。このファイルシステムは、ソースにある「新たな」スナップショットを正確に表現する。その後、さらなる変更差分から新しい「新たな」スナップショットが作成される。
【００１２】
ボリュームベースでスナップショットの遠隔ミラーリングを行なう方法については、同所有者の「ＦＩＬＥ　ＳＹＳＴＥＭ　ＩＭＡＧＥ　ＴＲＡＮＳＦＥＲ」と題したＳｔｅｖｅｎ　Ｋｌｅｉｍａｎ他による米国特許出願第０９／１２７４９７号明細書、及び、Ｓｔｅｖｅｎ　Ｋｌｅｉｍａｎ他による「ＦＩＬＥ　ＳＹＳＴＥＭ　ＩＭＡＧＥ　ＴＲＡＮＳＦＥＲ　ＢＥＴＷＥＥＮ　ＤＩＳＳＩＭＩＬＡＲ　ＦＩＬＥ　ＳＹＳＴＥＭＳ」と題した米国特許出願第０９／４２６４０９号明細書に詳しい説明があり、これら両方がここで参照することにより本明細書に取り込まれる。
【００１３】
このボリュームベースの方法は、ソースから遠隔の記憶先へ漸進的にミラーリングするのに有効ではあるが、ボリューム全体についての変更を検査して、それらの変更を１ブロックづつ送信しなければならないという点で、非効率で時間のかかる方法である。言い換えると、この検査は、ブロックに含まれるファイル、ｉｎｏｄｅ及びデータ構造に関する基礎情報を何も考慮することなく、ブロックに着目して行われる。宛先が一連のボリュームに編成されているので、ソースと宛先との間には、直接ボリューム単位のマッピングが確立される。ここでも、１ボリュームは１テラバイト以上もの情報を含む場合があり、変更を検査して比較する１ブロックづつの方法は、相当なプロセッサオーバヘッドとそれに関連する処理時間を必要とする。多くの場合、検査中のルートｉｎｏｄｅブロックの下方にあるサブブロックにわずかな変更が施されているだけである。しかしながら、そのボリューム内のあらゆるブロックのリストを検査しており、ブロックのグループ分け（ファイル、ｉｎｏｄｅ構造など）の多くに変更がないという事実は考慮されていない。さらに、ボリューム全体のサイズ及び範囲が大きくなるにつれて、グループによっては頻繁に変更されるグループもあり、それらのグループの複製は、あまり頻繁に変更されない他のグループの複製よりも頻繁に更新することが望ましいので、ミラーリングしているデータはサブグループに分割することが極めて望ましい。さらに、元のサブグループと複製された（スナップショットの）サブグループとを１つのボリュームに混在させ、ボリューム全体を移動させることなく特定の重要データを遠隔地に移動することが望ましい。従って、全体よりも少ないボリュームのミラーリングを可能にするボリュームの下位編成と、変更されたブロックをスキャンして特定するための、もっと洗練された方法が望まれている。
【００１４】
このようなボリュームの下位編成の１つが、周知のＱｔｒｅｅである。Ｑｔｒｅｅは、本明細書に記載される例示的ストレージシステム等で実施されるように、ボリュームのファイルシステムにおけるサブツリーである。Ｑｔｒｅｅの重要な特徴は、あるＱｔｒｅｅが与えられると、そのＱｔｒｅｅへの所属についてシステム内のあらゆるファイル及びディレクトリを迅速に検査することができるので、Ｑｔｒｅｅはファイルシステムを個別のデータ集合に編成するための優れた手段として機能するということである。スナップショットを作成するデータのソース及び宛先として、Ｑｔｒｅｅを使用することが望ましい。
【００１５】
【発明が解決しようとする課題】
宛先に複製されたスナップショットがＱｔｒｅｅであれば、そのスナップショットは、災害復旧やデータ配布等、他の用途にも利用することができる。しかしながら、ユーザまたはプロセスがアクセスしようとしたとき、宛先のアクティブファイルシステム上にあるスナップショットは、ソーススナップッショットを受信中であったり、ソーススナップショットからの更新を処理中であったりする場合がある。干渉されることなくスナップショットの更新を完了できるようにする方法が強く望まれている。同様に、スナップショットを初期の状態に戻す必要がある場合、そのような復元すなわち「巻き戻し」を容易にする方法も望まれている。様々な時点における複数のスナップショットを処理するための様々なその他の技術は、スナップショット複製手段の汎用性及び有用性を向上させるものである。
【００１６】
さらに、宛先スナップショットが更新される速度は、変更データをソースから宛先のアクティブファイルシステムへ送信可能な速度にも、依存する場合がある。ファイル消去及びファイル変更の効率を向上させる方法も望まれている。
【００１７】
【課題を解決するための手段】
本発明は、ソースファイルシステムの２バージョンのスナップショットを構成するブロックのスキャン（スキャナを介した）であって、各スナップショットの論理ファイルブロック索引をスキャンした際に特定されるボリュームブロック番号の差異に基づいて各々のスナップショットにおける変更されたブロックを特定するスキャンを利用して、ソースファイルシステムスナップショットにおける変更を宛先複製ファイルシステムに遠隔非同期複製すなわちミラーリングするためのシステム及び方法を提供することにより、従来技術の欠点を克服する。バージョン間で変更のなかったポインタをバイパスし、Ｔｒｅｅの階層における変更を識別するように下方へ移動しながら、ファイルに関するブロックのＴｒｅｅの中を移動する。これらの変更は、宛先のミラーすなわち複製スナップショットに送信される。この方法によって、通常のファイル、ディレクトリ、ｉｎｏｄｅ及び任意の他の階層構造を効率的にスキャンし、それらのバージョン間の差異を判定することが可能になる。
【００１８】
例示的実施形態によると、各スナップショットに対する論理ファイルブロックの索引に沿ったスキャナを用いたこのソーススキャンは、２つのソーススナップショット間で変更のあったボリュームブロック番号を探し出す。ディスクブロックが常にディスク上の新たな位置に再書き込みされるので、差異は、個々のブロックの基礎とするｉｎｏｄｅの変化を示す。スキャナを用いると、未変更のブロックは、それらのｉｎｏｄｅが変更されていないので、有効に見過ごされる。変更のあったブロックをスキャナから受信するｉｎｏｄｅ採集器プロセスを用いて、ソースは、選択されたＱｔｒｅｅ（または他のボリューム下位構成）に特に関連する変更されたブロックからｉｎｏｄｅを取り出す。この採集器プロセスは、２つのスナップショット間でバージョンが変更されたｉｎｏｄｅを探し出し、その変更されたバージョンを取り出す。ｉｎｏｄｅは同じであるがファイルには変更が施されている場合（ｉｎｏｄｅの生成番号が異なることで分かる）、それぞれのｉｎｏｄｅの２つのバージョンを両方とも取り出す。一方のバージョンで変更のあったｉｎｏｄｅは他方のバージョンでそれらのｉｎｏｄｅ以外のデータブロックを指し示すので、バージョンが変更された（２つのスナップショット間で）ｉｎｏｄｅは、キューに入れられ、一連のｉｎｏｄｅハンドラ／ワーカーに転送され、該ハンドラが、ｉｎｏｄｅの「ツリー」の下方へ向かってファイルオフセットをスキャンし（これもスキャナを用いて）、基礎とするブロックにおける差異がそれらのブロックのブロックポインタによって識別されるまでスキャンを続けることにより、基礎とするブロックにおける変化を解決する。非同期（遅延）方法の場合、宛先ファイルシステムの更新のためにネットワークを介して送信されるのは、ツリーの変更だけである。宛先ファイルシステムは、読み出し専用でユーザにエクスポートされる。これによって、複製者だけしか複製ファイルシステムの状態を変更できないことが保証される。
【００１９】
例示的実施形態では、変更データのデータストリームのネットワークを介した送信には、ファイルシステム非依存のフォーマットが用いられる。このフォーマットは、一意の識別子を有する単独ヘッダの集合で構成される。ヘッダが後続のデータを指し示す場合もあるし、ストリーム内に関連データが含まれる場合もある。例えば、「消去ファイル」ヘッダの内部には、ソーススナップショットで消去されたファイルに関する情報が含まれる場合がある。先ずディレクトリ活動がすべて送信され、その後ファイルデータが送信される。ファイルデータは、終端ヘッダ（フッタ）が設定されるまで規定のヘッダで分離された様々なサイズの塊で送信される。宛先では、このフォーマットをアンパックし、その中に含まれるｉｎｏｄｅをネットワーク上に送信し、それらを新たなディレクトリ構造にマッピングする。受信されたファイルデータブロックは、それらのオフセットに従って対応する宛先ファイルに書き込まれる。ｉｎｏｄｅマップは、ソースのｉｎｏｄｅ（ファイル）を宛先のｉｎｏｄｅ（ファイル）にマッピングするマップを格納する。ｉｎｏｄｅマップは、生成番号も保持する。（ｉｎｏｄｅ番号、生成番号）のタプルによって、システムは、ファイルに対して高速アクセスするためのファイルハンドルを作成することが可能になる。また、このタプルによってシステムは、ファイルが消去された際の変化を追跡し、そのｉｎｏｄｅ番号を新たに作成したファイルに再割り当てすることが可能になる。宛先での新たなディレクトリツリーの作成を容易にするため、宛先ミラープロセスの最初のディレクトリステージは、前記フォーマットでソースディレクトリ情報を受信し、消去されたファイルまたは移動されたファイルをすべてテンポラリなすなわち「一時的な」ディレクトリに移動する。移動されたそれらの一時的ファイルは、一時的ディレクトリからそれらのファイルが移動された先のディレクトリにハードリンクされる。新たに作成されたソースファイルがマップに入れられ、そのディレクトリツリーに組み込まれる。ディレクトリツリーが作成された後、ファイルデータの転送を開始する。ソースからのファイルデータに対する変更は、対応する複製ファイル（ｉｎｏｄｅマップによって識別される）に書き込まれる。データストリーム転送が完了すると、一時的ディレクトリを消去し、リンク先のないあらゆるファイル（様々な消去されたファイルを含む）を永久に消去する。一実施形態では、複数の個別のソースＱｔｒｅｅ、または、異なるソースボリュームから作成された他の下位組織を、１つの宛先ボリューム上に複製／ミラーリングすることができる。
【００２０】
本発明は、複製された宛先ファイルシステムスナップショットをソースファイルシステムスナップショットの変化分を用いて更新するためのシステム及び方法において、宛先アクティブファイルシステム上で変更されたファイル及び消去されたファイルをそれらのファイルが再利用されるまでずっと一時的ディレクトリに関連付けておくことを可能にするテンポラリすなわち「一時的」ディレクトリを用いて、宛先上でのソース更新情報からの新たなディレクトリツリーの作成を容易にすることによって、従来技術の欠点を克服する。さらに、ソースｉｎｏｄｅ番号から宛先ｉｎｏｄｅ番号へのマッピングを行なうｉｎｏｄｅマップを宛先上に設けることで、ｉｎｏｄｅ／生成番号のタプルを用いた宛先ツリーの作成を容易にしている。このｉｎｏｄｅマップにより、ソースファイルシステムと宛先との再同期が可能になる。また、このｉｎｏｄｅマップによって、２以上の宛先スナップショットを、それら各々のソースを有するマップに基いて、互いに関連付けることが可能になる。
【００２１】
例示的実施形態では、ファイルシステム非依存のフォーマットを用いて、ソースの基礎スナップショット及び差分スナップショットに関して変更のあったファイルデータブロックのデータストリームが送信される。受信したファイルデータブロックは、それらのオフセットに従って対応する宛先ファイルに書き込まれる。ｉｎｏｄｅマップは、ソースのｉｎｏｄｅ（ファイル）を宛先のｉｎｏｄｅ（ファイル）にマッピングするマップを格納する。ｉｎｏｄｅマップは、生成番号も保持する。（ｉｎｏｄｅ番号、生成番号）のタプルによって、システムは、ファイルに対して高速アクセスするためのファイルハンドルを作成することが可能になる。また、このタプルによってシステムは、ファイルが消去された際の変化を追跡し、そのｉｎｏｄｅ番号を新たに作成したファイルに再割り当てすることが可能になる。宛先での新たなディレクトリツリーの作成を容易にするため、宛先ミラープロセスの最初のディレクトリステージは、前記フォーマットでソースディレクトリ情報を受信し、消去されたファイルまたは移動されたファイルをすべてテンポラリなすなわち「一時的な」ディレクトリに移動する。移動されたそれらの一時的ファイルは、一時的ディレクトリからそれらのファイルが移動された先のディレクトリにハードリンクされる。新たに作成されたソースファイルがマップに入れられ、そのディレクトリツリーに組み込まれる。ディレクトリツリーが作成された後、ファイルデータの転送を開始する。ソースからのファイルデータに対する変更は、対応する複製ファイル（ｉｎｏｄｅマップによって識別される）に書き込まれる。データストリームの転送が完了すると、一時的ディレクトリを消去し、リンク先のないあらゆるファイル（様々な消去されたファイルを含む）を永久に消去する。一実施形態では、複数の個別のソースＱｔｒｅｅ、または、異なるソースボリュームから作成された他の下位構成を、１つの宛先ボリューム上に複製／ミラーリングすることができる。
【００２２】
別の例示的実施形態では、複製ファイルシステムそれ自体のスナップショットを作成することにより、第１のエキスポートされたスナップショットを作成する。この第１のエキスポートされたスナップショットは第１の状態に対応する。複製スナップショットがさらに変更または更新された後、天災や通信障害が発生した場合、複製ファイルシステムに対するそれ以上の変更を停止／凍結し、続いて、凍結された複製ファイルシステムから第２の状態を表す第２のエキスポートされたスナップショットを作成する。複製ファイルシステムは、第２の状態と第１の状態とのデータの差異を判定し、それらの変化分を用いて第１の状態を再現することにより、第２の状態から第１の状態に「巻き戻す」ことができる。
【００２３】
さらに別の例示的実施形態では、ソーススナップショットから転送されたｉｎｏｄｅを、ｉｎｏｄｅマップを用いて宛先にある複製／ミラーファイルシステムのｉｎｏｄｅにマッピングし、ソースの状態と宛先の状態とを再同期させる。宛先は新たな「ソース」になり、古い「ソース」に対するｉｎｏｄｅマップの転送が新たな「宛先」にネゴシエートされる。受信した古いｉｎｏｄｅマップは、ソース上に格納され、反転手順によってアクセスされて、新たなソースのｉｎｏｄｅ数に等しいＮ個のｉｎｏｄｅを有する新たな宛先マップが生成される。次いで新たな宛先は、新たなソースエントリに関連する各宛先について、その格納されたソースマップからエントリを可能であれば作成する。関連する生成番号もマッピングされ、これによって必要なファイルアクセスタプルが生成される。新たなソース索引上で新たな宛先をもたないエントリにはすべてゼロエントリとしてマークが付される。反転ｉｎｏｄｅマップが完成すると、新たなソースはその変更されたデータで新しい宛先を更新できるようになる。
【００２４】
関連実施形態では、同じソースの２つの複製／ミラースナップショットが互いに鏡像関係になるようにすることができる。上記反転実施形態のように、新たな「ソース」（古い複製）がそのｉｎｏｄｅマップを宛先システムに転送する。次いで宛先システムは、２つのシステムのｉｎｏｄｅ間の関係を判定する。「連想」プロセスは、両方のｉｎｏｄｅマップを同時に調べる（例えば、ｉｎｏｄｅ番号単位で同時に）。このプロセスは、元のソースからの各ｉｎｏｄｅについて、ｉｎｏｄｅマップの各々から「宛先ｉｎｏｄｅ／生成」を取り出す。次いでこのプロセスは、新たなソースを新たなｉｎｏｄｅマップの適当なマップ索引として扱う。このプロセスは、新しいソース生成番号を、宛先ｉｎｏｄｅ／生成とともに格納する。
【００２５】
【発明の実施の形態】
Ａ．ネットワーク及びファイルサーバ環境
さらなる背景として、図３は、本発明に各々有利に用いられる、ソースファイルサーバ３１０及び宛先ファイルサーバ３１２からなる一対の相互接続されたファイルサーバを有するストレージシステム環境３００を示す略ブロック図である。説明上、このソースファイルサーバは１以上のソースボリューム３１４を管理するネットワークコンピュータであり、ソースボリューム３１４の各々がストレージディスク３６０のアレイ（以下で更に説明する）を有している。同様に、宛先ファイラー３１２も、ディスク３６０のアレイから構成される１以上の宛先ボリューム３１６を管理する。ソースファイルサーバと宛先ファイルサーバ、すなわちファイラーは、ローカルエリアネットワークや周知のインターネット等のワイドエリアネットワークで構成されるネットワーク３１８を介して接続される。各ファイラー３１０、３１２に含まれる適当なネットワークアダプタは、ネットワーク３１８を介した通信をサポートする。ここでも説明上、ソースファイラー及び宛先ファイラー３１０、３１２の各々における似たような構成要素は、類似の参照符号で示している。本明細書で用いられるように、「ソース」という用語は本発明の対象データの移動元の場所として大まかに定義され、「宛先」という用語はデータの移動先の場所として大まかに定義される。ネットワークで接続されたソースファイラー及び宛先ファイラーは本明細書で用いられるソース及び宛先の一例であり、ソース及び宛先は、ダイレクトリンク、すなわちループバック（ローカルなソースと宛先の間でデータストリームを伝達するための単一コンピュータ内部の「ネットワーク」構成）によってリンクされたコンピュータ／ファイラーである場合もあり、その場合ソースと宛先は同じファイラーになる。以下で更に説明するように、ソース及び宛先は、ボリュームのソース下位構成及びボリュームの宛先下位構成であるものとして広く解釈される。実際、少なくとも１つの特別な場合、ソース下位構成及び宛先下位構成は、様々な時点で同じものになる場合がある。
【００２６】
ネットワーク接続されたソースファイラー及び宛先ファイラーからなる一対の例の場合、各ファイラー３１０及び３１２には、スタンドアロンのコンピュータを含めて、任意のタイプの専用コンピュータ（例えばサーバ）または汎用コンピュータを用いることができる。ソースファイラー及び宛先ファイラー３１０、３１２の各々は、システムバス３４５で相互接続されたプロセッサ３２０、メモリ３２５、ネットワークアダプタ３３０及びストレージアダプタ３４０を含む。また各ファイラー３１０、３１２は、情報をディスク上でディレクトリ及びファイルの階層構造として論理編成するファイルシステムを実現するストレージオペレーティングシステム４００（図４）も含む。
【００２７】
当業者であれば、本明細書に記載する本発明の方法は、ストレージシステムとして実現されたスタンドアロンのコンピュータを含めて、任意のタイプの専用コンピュータ（例えばファイルサービス装置）または汎用コンピュータに適用できることが分かるであろう。そのため、ファイラー３１０及び３１２は各々、大まかに、及び代替として、ストレージシステムと呼ばれる場合もある。また、本発明の教示は様々なストレージシステムアーキテクチャに適用することができ、限定はしないがそれらのアーキテクチャには、ネットワークに取り付けられたストレージ環境、ストレージエリアネットワーク、及び、クライアント／ホストコンピュータに直接取り付けられたディスクアセンブリなどが含まれる。
【００２８】
例示的実施形態では、ソフトウェアプログラムコードを記憶するため、メモリ３２５には、プロセッサ及びアダプタによってアドレス指定可能な記憶場所が含まれる。メモリは、ランダムアクセスメモリ（ＲＡＭ）の形態に構成され、電源サイクルまたはその他リブート処理によってクリアされるのが通常である（すなわち、メモリは「揮発性」メモリである）。次に、プロセッサ及びアダプタは、そのソフトウェアコードを実行してデータ構造を操作するように構成された処理要素及び／又は論理回路で構成される。一般に、ストレージオペレーティングシステム４００は、その一部がメモリに存在し、処理要素によって実行され、とりわけファイラーが実施するファイルサービスをサポートする記憶処理を呼び出すことによって、ファイラーの機能を構成する。当業者であれば、本明細書に記載する本発明の方法に関するプログラム命令の格納及び実行には、様々なコンピュータ読み取り可能な媒体を含めて、他の処理手段及び記憶手段を用いることも可能であることが分かるであろう。
【００２９】
ネットワークアダプタ３３０は各ファイラー３１０、３１２をネットワーク３１８に接続するのに必要な機械回路、電気回路及び信号回路を含み、ネットワーク３１８はポイント・ツー・ポイント接続や、ローカルエリアネットワーク等の共用媒体からなる。さらに、ソースファイラー３１０は、クライアント／サーバモデルの情報配送に従って、宛先ファイラー３１２と対話することができる。従って、例えばＴＣＰ／ＩＰその他のネットワークプロトコル形態にカプセル化されたパケット３５５をネットワーク３１８を介して交換することにより、クライアントはファイラーのサービスを要求することができ、ファイラーはクライアントから要求されたサービスの結果を返すことができる。
【００３０】
ストレージアダプタ３４０は、ファイラー上で実行されているストレージオペレーティングシステム４００（図４）と協働して、クライアントから要求された情報にアクセスする。この情報は、ストレージアダプタ３４０を介して各ファイラーに取り付けられたディスク３６０上に格納されている場合もあるし、本明細書で定義されるようなストレージシステムの他のノードに格納されている場合もある。ストレージアダプタ３４０は、従来の高性能ファイバーチャネルシリアルリンク接続形態等、Ｉ／Ｏ相互接続構成によってディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を有している。情報はストレージアダプタによって取得され、以下で詳しく説明するように、その情報をパケットに成形して宛先サーバへ送信する場合、システムバス３４５を介してネットワークアダプタ３３０に転送する前に、スナップショット手順の一部としてプロセッサ３２０によって処理される。
【００３１】
各ファイラーは、ネットワークアダプタ３３０を介して１以上のクライアント３７０と相互接続される場合もある。クライアントは、ファイルサービスの要求をソースファイラー及び宛先ファイラー３１０，３１２のそれぞれに送信し、それらの要求に対する応答をＬＡＮその他のネットワーク（３１８）を介して受信する。データは、クライアントと個々のファイラー３１０、３１２との間で、共通インターネットファイルシステム（ＣＩＦＳ）プロトコルまたはＮＦＳ等の他の適当なプロトコルのカプセル化として定義されたデータパケット３７４を用いて転送される。
【００３２】
一例示的なファイラー実施形態では、各ファイラー３１０，３１２は、データのフォールトトレランスなバックアップを可能にする不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）３３５を含む場合があり、ファイラートランザクションの完全性を確保して電源故障その他の故障によるサービス停止を切り抜けることができる場合がある。このＮＶＲＡＭのサイズは、ファイラーの実施形態及び機能に応じて決まる。通常は、特定時間（例えば数秒分）のトランザクションのログをとるのに十分なだけのサイズにする。各クライアント要求が完了した後、その要求の結果を要求しているクライアントに返す前に、ＮＶＲＡＭはバッファキャッシュと並行して満たされる。
【００３３】
一例示的実施形態では、ディスク３６０は複数のボリューム（例えばソースボリューム３１４及び宛先ボリューム３１６）に配置され、各ボリュームがそのボリュームに関連するファイルシステムを有するようになっている。これらのボリュームは、各々１以上のディスク３６０を有する。一実施形態では、好ましいＲＡＩＤ４構成に従って、物理ディスク３６０がＲＡＩＤグループに構成され、いくつかのディスクがストライプ化されたデータを格納し、いくつかのディスクがそのデータについて個別パリティを格納する場合がある。しかしながら、他の構成（例えばパリティが複数のストライプに分散されたＲＡＩＤ５など）も考えられる。この実施形態の場合、最小で、１台のパリティディスクと１台のデータディスクを使用する。しかしながら、典型的な実施形態では、ＲＡＩＤグループ１つ当たり３台のデータディスクと１台のパリティディスクが含まれ、１ボリューム当たり複数のＲＡＩＤグループが含まれる。
【００３４】
Ｂ．ストレージオペレーティングシステム
ディスク３６０に対する一般的なアクセスを容易にするため、ストレージオペレーティングシステム４００（図４）は、情報をディスク上でディレクトリ及びファイルの階層構造として論理編成するＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施する。「ディスク上」の各ファイルはデータ等の情報を格納するように構成されたディスクブロックの集まりとして実現され、ディレクトリは他のファイル及びディレクトリが格納された特別な形態のファイルとして実現される。上で説明及び定義したように、本明細書で説明する例示的実施形態の場合、ストレージオペレーティングシステムはカリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手可能なＮｅｔＡｐｐ　Ｄａｔａ　ＯＮＴＡＰ（Ｒ）オペレーティングシステムであり、このオペレーティングシステムはＷｒｉｔｅ　Ａｎｙｗｈｅｒｅファイルレイアウト（ＷＡＦＬ（Ｒ））ファイルシステムを実施する。任意の適当なファイルシステムを使用することが可能であるから、「ＷＡＦＬ」という用語を用いた場合であっても、この用語は本発明の教示に適合可能な任意のファイルシステムを意味するように広く解釈すべきである。
【００３５】
例示的ファイラーの各々について、好ましいストレージオペレーティングシステムの構成をまず簡単に説明する。しかしながら、明らかに、本発明の原理は様々な代替ストレージオペレーティングシステムアーキテクチャを用いて実施することもできると考えられる。さらに、ソースファイラー及び宛先ファイラー３１０、３１２の各々で実施される特定の機能は、異なる場合もある。図４に示すように、例示的ストレージオペレーティングシステム４００は、ネットワークドライバ（例えばイーサネット（Ｒ）ドライバ）のメディアアクセス層を含む、一連のソフトウェア層から構成される。このオペレーティングシステムは更に、インターネット・プロトコル（ＩＰ）層４１０、並びに、ＩＰ層がサポートする搬送手段であるトランスポート・コントロール・プロトコル（ＴＣＰ）層４１５及びユーザ・データグラム・プロトコル（ＵＤＰ）層４２０を含む。ファイルシステムプロトコル層は、複数プロトコルのデータアクセスを可能にするため、ＣＩＦＳプロトコル４２５、ＮＦＳプロトコル４３０、及び、ハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ）プロトコル４３５をサポートする。さらに、ストレージオペレーティングシステム４００は、ＲＡＩＤプロトコル等のディスクストレージプロトコルを実施するディスクストレージ層４４０、及び、スモール・コンピュータ・システム・インタフェース（ＳＣＳＩ）等のディスク制御プロトコルを実施するディスクドライバ層４４５を含む。
【００３６】
これらのディスクソフトウェア層とネットワークプロトコル層及びファイルシステムプロトコル層との橋渡しをするのが、ストレージオペレーティングシステム４００のファイルシステム層４５０である。一般にファイルシステム層４５０は、ディスク上で例えば４キロバイト（ＫＢ）のデータブロックを用いたブロックベースのフォーマット表現を有するファイルシステムを実施し、ｉｎｏｄｅを用いてファイルを表現する。このファイルシステムは、トランザクション要求に応じて、要求されたデータが「コア内」すなわちファイラーのメモリ３２５に存在しない場合、そのデータをボリュームからロード（取得）する処理を行なう。情報がメモリに存在しない場合、ファイルシステム層４５０は、ｉｎｏｄｅ番号を用いてｉｎｏｄｅファイル内に索引を付け、適当なエントリにアクセスしてボリュームブロック番号を取得する。次いでファイルシステム層４５０は、そのボリュームブロック番号をディスクストレージ（ＲＡＩＤ）層４４０に渡し、ＲＡＩＤ層４４０がそのボリュームブロック番号をディスクブロック番号にマッピングして、そのディスクブロック番号をディスクドライバ層４４５の適当なドライバ（例えば、ファイバーチャネルディスク相互接続上で実施されるＳＣＳＩのカプセル化）に送信する。次いでディスクドライバは、ディスクのそのディスクブロック番号にアクセスして要求されたデータをメモリ３２５にロードし、ファイラー３１０、３１２で処理する。要求が完了すると、ファイラーは、ＣＩＦＳ規格に規定されている従来の受領応答パケットを、個々のネットワーク接続３７２を介してクライアント３７０に返す。
【００３７】
ファイラーで受信されたクライアント要求についてデータストレージアクセスを実施しなければならない上記ストレージオペレーティングシステムを通るソフトウェア「パス」４７０は、代替としてハードウェアで実施することも、あるいはハードウェアとソフトウェアの組み合わせで実施することもできる。従って、本発明の代替実施形態では、ストレージアクセス要求データパス４７０が、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の内部に実現される論理回路として実施される場合がある。この種のハードウェア実施形態は、クライアント３７０が発行したファイルシステム要求パケット３７４に応答してファイラー３１０、３１２によって提供されるファイルサービスの性能を向上させることができる。
【００３８】
ファイルシステム層４５０の上に重なるのは、本発明の例示的形態によるスナップショット・ミラーリング（複製）・アプリケーション４９０である。以下で詳細に説明するように、（ソース側では）このアプリケーションは、スナップショットをスキャンして、スナップショットの変化をソースファイラー３１０から宛先ファイラー３１２へネットワークを介して送信する働きがある。（宛先側では）このアプリケーションは、受信した情報を基にしてミラースナップショットを更新する働きがある。従って、ソースアプリケーション及び宛先アプリケーションの特定機能は、以下で説明するように、異なる場合がある。スナップショット・ミラーリング・アプリケーション４９０は、ＴＣＰ／ＩＰ層４１５，４１０に対する直接リンク４９２、及びファイルシステムスナップショット手段（４８０）に対する直接リンク４９４に示すように、通常の要求パス４７０の外側で動作する。このアプリケーションは、ファイルシステム層と対話してファイルの受領応答を受信するので、ファイルベースのデータ構造（具体的にはｉｎｏｄｅファイル）を用いてソースのスナップショットを宛先に複製することができる。
【００３９】
Ｃ．スナップショット手順
例示のＷＡＦＬファイルシステムに固有のＳｎａｐｓｈｏｔ（Ｒ）機能については、Ｄａｖｉｄ　Ｈｉｔｚ他による「Ｆｉｌｅ　Ｓｙｓｔｅｍ　Ｄｅｓｉｇｎ　ｆｏｒ　ａｎ　ＮＦＳ　Ｆｉｌｅ　Ｓｅｒｖｅｒ　Ａｐｐｌｉａｎｃｅ」と題したＴＲ３００２に詳しい説明があり、この文献はここで参照することにより本明細書に取り込まれる。「Ｓｎａｐｓｈｏｔ」がネットワークアプライアンス社の登録商標であることに注意して欲しい。この用語は、この特許の目的で、Ｐｅｒｓｉｓｔｅｎｔ　Ｃｏｎｓｉｓｔｅｎｃｙ　Ｐｏｉｎｔ（ＣＰ）Ｉｍａｇｅを指すために用いられている。Ｐｅｒｓｉｓｔｅｎｔ　Ｃｏｎｓｉｓｔｅｎｃｙ　Ｐｏｉｎｔ　Ｉｍａｇｅ（ＰＣＰＩ）とは、記憶装置（例えばディスク等）に格納されたストレージシステムをある時点で表現したものであって、特にアクティブファイルシステムをある時点で表現したものであり、そのＰＣＰＩを他の時点で作成されたＰＣＰＩから区別する名称その他一意の識別子を有する。また、ＰＣＰＩには、そのイメージが作成された時点でのアクティブファイルシステムに関するその他の情報（メタデータ）が含まれる場合もある。「ＰＣＰＩ」という用語と「スナップショット」という用語は、ネットワークアプライアンス社の商標権から外れることなく、交換可能に用いられる。
【００４０】
スナップショットは、何らかの規則的なスケジュールで作成されるのが一般的である。このスケジュールは大きな変化の影響を受ける。さらに、ファイラーに保持されるスナップショットの数も極めて不定である。格納手段が１つの場合、複数の最近のスナップショットは連続して格納し（例えば４日分のスナップショットを各々４時間の間隔で）、複数のそれよりも古いスナップショットはもっと時間間隔を広げて（例えば前の週に関する日毎のスナップショット及び前の数ヶ月についての週毎のスナップショットなど）保持する場合がある。スナップショットは、アクティブファイルシステムと共に格納され、以下で詳しく説明するように、ストレージオペレーティングシステム４００またはスナップショットミラーアプリケーション４９０から要求があったときに、ファイラーメモリのバッファキャッシュに呼び出される。しかしながら、本発明の教示の中で、様々なスナップショット作成手段及び時間調節手段を用いることができると考えられる。
【００４１】
例示的実施形態による例示的ファイルシステムｉｎｏｄｅ構造５００を図５に示す。このｉｎｏｄｅファイルのｉｎｏｄｅ、すなわちもっと普通に「ルート」ｉｎｏｄｅ５０５は、所与のファイルシステムに関するｉｎｏｄｅファイル５０８を表す情報を保持している。この例示的ファイルシステムｉｎｏｄｅ構造の場合、ルートｉｎｏｄｅ５０５は、ｉｎｏｄｅファイル間接ブロック５１０へのポインタを保持している。ｉｎｏｄｅファイル間接ブロック５１０は、１以上のｉｎｏｄｅファイル直接ブロック５１２を指しており、ｉｎｏｄｅファイル直接ブロック５１２の各々はｉｎｏｄｅファイル５０８を構成するｉｎｏｄｅ５１５への一連のポインタを保持している。図示の問題となるｉｎｏｄｅファイル５０８はｉｎｏｄｅ５１５を構成するボリュームブロックに編成され、ｉｎｏｄｅ５１５はファイルデータ（または「ディスク」）ブロック５２０Ａ、５２０Ｂ及び５２０Ｃへのポインタを保持している。この図の場合、単にｉｎｏｄｅ自体がファイルデータブロックへのポインタを保持しているように単純化して図示している。例示の実施形態では、ファイルデータブロック５２０（Ａ〜Ｃ）の各々は、４キロバイト（ＫＢ）のデータを格納するようになっている。しかしながら、１つのｉｎｏｄｅ（５１５）によって所定数を超えるファイルデータブロックが参照される場合、１以上の間接ブロック５２５（仮想的に示す）が用いられるということに注意して欲しい。それらの間接ブロックは、それらに関連するファイルデータブロックを指す（図示せず）。あるｉｎｏｄｅ（５１５）が間接ブロックを指している場合、そのｉｎｏｄｅがさらにファイルデータブロックも指すことはありえず、その逆も言える。
【００４２】
ファイルシステムは、所与のファイルシステムのスナップショットを作成する場合、図６に示すようなスナップショットｉｎｏｄｅを作成する。スナップショットｉｎｏｄｅ６０５は、実質的にファイルシステム５００のルートｉｎｏｄｅ５０５の複製である。従って例示のファイルシステム構造６００は、図５に図示したものと同じｉｎｏｄｅファイル間接ブロック５１０、ｉｎｏｄｅファイル直接ブロック５１２、ｉｎｏｄｅ５１５、及び、ファイルデータブロック５２０（Ａ〜Ｃ）を有する。ユーザがファイルデータブロックを変更した場合、ファイルシステム層は、その新たなデータブロックをディスクに書き込み、新たに作成したブロックを指すようにアクティブファイルシステムを変更する。ファイル層は、その新たなデータをスナップショットに保持されるブロックには書き込まない。
【００４３】
図７は、ファイルデータブロックが変更された後の例示的ｉｎｏｄｅファイルシステム構造７００を示している。この例の場合、ディスクブロック５２０Ｃに格納されたファイルデータが変更された。例示のＷＡＦＬファイルシステムは、この変更された内容をディスク上の新たな位置である５２０Ｃ’に書き込む。新たな位置に書き込むため、ディスクブロック（５１５）に格納されたｉｎｏｄｅファイルデータは、ブロック５０２Ｃ’を指すように書き換えられる。この変更によって、ＷＡＦＬは、５１５にある変更されたデータについて新たなディスクブロック（７１５）を割り当てる。同様に、ｉｎｏｄｅファイル間接ブロック５１０をブロック７１０に書き換え、直接ブロック５１２をブロック７１２に書き換え、新たに変更されたｉｎｏｄｅ７１５を指すようにする。従って、ファイルデータブロックの変更が終った後、スナップショットｉｎｏｄｅ６０５は、元のｉｎｏｄｅファイルシステム間接ブロック５１０へのポインタを保持し、ｉｎｏｄｅ５１５へのリンクを有している。このｉｎｏｄｅ５１５は、元のファイルデータブロック５２０Ａ、５２０Ｂ、及び、５２０Ｃへのポインタを保持している。しかしながら、新たに書き込まれたｉｎｏｄｅ７１５は、未変更のファイルデータブロック５２０Ａ及び５２０Ｂへのポインタしか有していない。またｉｎｏｄｅ７１５は、アクティブファイルシステムの新たな構成を表す変更されたファイルデータブロック５２０Ｃ’へのポインタも保持している。新たなファイルシステムルートｉｎｏｄｅ７０５は、新たな構造７００を表すように確立される。何らかのスナップショットを作成したブロック（例えばブロック５１０、５１５１及び５２０Ｃ）にあるメタデータは、それらがすべてのスナップショットから開放されるまで、再利用や上書きから保護されることに注意して欲しい。従って、アクティブファイルシステムルート７０５が新たなブロック７１０、７１２、７１５及び５２０Ｃ’を指していても、古いブロック５１０、５１５及び５２０Ｃは、スナップショットが完全に開放されるまで保持される。
【００４４】
本発明の例示的実施形態では、ソースは、２つのスナップショット、すなわち、宛先上の複製ファイルシステムのイメージを表す「ベース」スナップショットとソースシステムが宛先に複製しようとしているイメージである「差分」スナップショットとを用いて、宛先にミラーされたリモートスナップショットに必要な更新を実施する。一例では、ソースの立場から、差分スナップショットは最新のスナップショットを含み、ベーススナップショットはあまり最近のものではないスナップショットを含み、最新の変更の集合を宛先に提供することを可能にする。次にこの手順について、さらに詳しく説明する。
【００４５】
Ｄ．遠隔ミラーリング
スナップショットを作成するための一般的な手順の説明が終わったので、ソースファイラー３１０（図３）から遠隔の宛先ファイラー３１２へのスナップショット情報のミラーリングについてさらに詳しく説明する。上で概説したように、ボリューム全体における変更されたブロックの比較に基づくスナップショットの変更差分の伝送は、ファイルシステムスナップショット全部ではなく、データの変更差分だけを転送し、小さくて高速な変更を可能にするので、有利である。しかしながら、本発明の例示的実施形態によると、宛先ミラースナップショットの遠隔差分更新について、さらに効率的及び／又は多用途な手順が考えられる。本明細書で用いられるように、「複製スナップショット」、「複製スナップショット」または「ミラースナップショット」という用語は、適当なスナップショットを保持する宛先ボリューム上のファイルシステムを大まかに指すものとして解釈すべきである（例えばスナップショットのスナップショットが含まれる）。
【００４６】
上で簡単に述べたように、この手順は、Ｑｔｒｅｅと呼ばれるボリュームの下位構成の利点を得ることができる。Ｑｔｒｅｅは、従来のＵＮＩＸ（Ｒ）ファイルシステムやＷｉｎｄｏｗｓ（Ｒ）ファイルシステムにおけるパーティションサイズによるデータの集まりに対する制限と同様の働きがあるが、ディスク上の特定領域のブロックに結び付けられていないので、制限の実質的変更について柔軟性がある。ディスクの特定の集まり（例えばｎ台のディスクからなるＲＡＩＤグループ）にマッピングされ従来のパーティションに比較的似ているボリュームとは異なり、Ｑｔｒｅｅは、ボリュームよりも高レベルで実施されるので、高い柔軟性を提供することができる。Ｑｔｒｅｅは、基本的に、ストレージオペレーティングシステムのソフトウェアにおける抽象概念である。実際、各ボリュームは複数のＱｔｒｅｅを有する場合がある。Ｑｔｒｅｅの粒度は、わずか数キロバイトの記憶容量にすることができる。Ｑｔｒｅｅ構造は、適当なファイルシステム管理者によって定義することもできるし、かかる制限を設定する適当な権限を有するユーザによって定義することもできる。
【００４７】
上で説明したＱｔｒｅｅ構成は例示的なものであり、本発明の原理はボリューム全体の方法を含めて、様々なファイルシステム構成に適用することができることに注意して欲しい。Ｑｔｒｅｅが例示の実施形態による便利な構成であることの理由の一つは、ｉｎｏｄｅファイルに識別子を利用できるからである。
【００４８】
宛先におけるソースの複製のためにデータを宛先に転送する元になる２つのソーススナップショットにおける変更を計算する処理についてさらに説明する前に、図５〜図７に示すファイルブロック構造をもう一度大まかに参照しておく。ファイルのあらゆるデータブロックは、ディスクブロック（又はボリュームブロック）にマッピングされる。あらゆるディスク／ボリュームブロックは、個別のボリュームブロック番号（ＶＢＮ）を用いて一意に数えられる。各ファイルは、それらのデータブロックへのポインタを保持する１つのｉｎｏｄｅで表現される。これらのポインタはＶＢＮであり、ｉｎｏｄｅの各ポインタフィールドは内部にＶＢＮを有し、ファイルシステム（またはディスク制御）層に対する要求により適当なディスク／ボリュームブロックを読み出すことによって、ファイルのデータがアクセスされる。このディスクブロックのＶＢＮは、ｉｎｏｄｅのポインタフィールドに配置される。スナップショットは、ある時点でｉｎｏｄｅおよびそのｉｎｏｄｅの中のＶＢＮフィールドすべてを取り込む。
【００４９】
ｉｎｏｄｅ内のＶＢＮ「ポインタ」の最大数を超えてスケーリングするため、「間接ブロック」が用いられる。実質的に、ディスクブロックは、データブロックのＶＢＮが割り当てられ、それらＶＢＮで満たされ、次いでｉｎｏｄｅポインタがその間接ブロックを指す。大きなツリー構造を作ることができる複数階層の間接ブロックが存在する場合がある。間接ブロックは間接ブロック内のＶＢＮが変更されるたびに毎回、通常のデータブロックと同じ方法で変更され、その間接ブロックの変更されたデータについて新たなディスク／ボリュームブロックが割り当てられる。
【００５０】
１．ソース
図８は、ソース環境８００内部のスナップショットｉｎｏｄｅの例示的ペアを示している。例示的実施形態において、これらは、２つのスナップショットのｉｎｏｄｅファイル、すなわち、ベース８１０及び差分８１２を表している。これら２つのスナップショットは２つの時点で作成されたものであり、ベースは複製の現在のイメージを表し、差分はその複製を更新するイメージを表すものであることに注意して欲しい。２つのスナップショットの差異によって、いずれの変更を作成して遠隔の複製／ミラーに送信すべきかが決まる。各ｉｎｏｄｅファイルは、ストレージオペレーティングシステムのスナップショットマネージャ（図４の４８０）による指示に従って、ソースファイルシステムのディスク上のバッファキャッシュからソースファイルサーバメモリのバッファキャッシュにロードされる。一実施形態において、ベーススナップショット及び差分スナップショットは、ストレージオペレーティングシステムで使用されるときにストレージオペレーティングシステムにロードされる（一度に全部ではなく）。各スナップショットｉｎｏｄｅファイル８１０、８１２は、一連のストレージブロック８１４に編成される。この例の場合、ベースｉｎｏｄｅファイル８１０はボリュームブロック番号５、６、及び７で記されたストレージブロックを含み、差分スナップショットｉｎｏｄｅファイルは例えばボリュームブロック番号３、５、６、及び８のボリュームブロック番号のストレージブロックを含む。各ブロックの内部は、所定数のｉｎｏｄｅ８１６に編成される。ボリュームブロックには、それらが基礎にしている論理ファイルブロックの配置に基づいて、図示の順番で索引が付される。
【００５１】
Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルレイアウトの例の場合、ストレージブロックは、直ぐに上書きされたり、再利用されたりすることがない。従って、一連のボリュームブロックで構成されたファイルを変更すれば、常に新たな（新しく書き込まれた）ボリュームブロック番号が発生することになるので、その番号は古いブロックに対する適当な論理ファイルブロックオフセットとして検出することができる。ベーススナップショットｉｎｏｄｅファイルと差分スナップショットｉｎｏｄｅファイルの間の索引の所与のオフセットに変更されたボリュームブロック番号が存在することは、基礎とするｉｎｏｄｅのうちの１以上、及び、そのｉｎｏｄｅが指しているファイルに変更があったことを意味している。しかしながら、本システムはｉｎｏｄｅやポインタの変更のインジケータに他のインジケータを用いることもでき、これは固定位置ファイルシステムが実施される場合に望ましい。
【００５２】
スキャナ８２０は、索引をサーチし、ボリュームブロック番号その他の識別子を比較して、変更されたベース／差分ｉｎｏｄｅファイルスナップショットブロックを見付ける。図８の例では、ベーススナップショットｉｎｏｄｅファイル８１０のブロック４は、ファイルスキャン順番で、差分スナップショットｉｎｏｄｅファイル８１２のブロック３に対応している。これは、１以上の基礎とするｉｎｏｄｅの変更を示している。さらに、ベーススナップショットｉｎｏｄｅファイルのブロック７は、差分スナップショットｉｎｏｄｅファイルのブロック８のように見える。両ファイルにおけるブロック５及び６は、変更されていないので、何もｉｎｏｄｅその他の情報を更に処理することなく、高速にスキャンされる。従って、両スナップショットにおいて同じ索引でスキャンされたブロックは有効にバイパスして、スキャン時間を削減することができる。
【００５３】
変更があったものとして識別されたブロック対（例えばブロック７及び８）は、ｉｎｏｄｅ採集器プロセス８３０を含むソースプロセスの残りの部分に転送される。ｉｎｏｄｅ採集器は、転送されたブロックの中から（ＱｔｒｅｅＩＤに基づいて）ミラーされている選択されたＱｔｒｅｅの一部である特定のｉｎｏｄｅを識別する。この例の場合、ＱｔｒｅｅＩＤ　Ｑ２が選択されているので、ｉｎｏｄｅファイルメタデータにこの値を有するｉｎｏｄｅが「取り出され」、さらに処理される。選択さえたＱｔｒｅｅの一部ではない他のｉｎｏｄｅ（例えばＱｔｒｅｅＩＤがＱ１及びＱ３のｉｎｏｄｅ）は、採集器プロセス８３０によって破棄または無視される。複数のＱｔｒｅｅＩＤを選択し、選択されたＱｔｒｅｅ関連のうちの１つを有するｉｎｏｄｅのグループを、採集器プロセスによって抜き出すこともできる。
【００５４】
次いで、変更されたブロックから適切に「取り出された」ｉｎｏｄｅは、変更されたｉｎｏｄｅ８４２の実行中リストすなわちキュー８４０に入れられる。これらのｉｎｏｄｅは、図示のように不連続の番号で記される。キュー８４０内の各ｉｎｏｄｅは、ｉｎｏｄｅハンドラまたはワーカー８５０、８５２及び８５４に渡され、それらのｉｎｏｄｅワーカーが利用できるようになる。図８Ａは、ｉｎｏｄｅ採集器プロセス８３０が与えられたｉｎｏｄｅをワーカーで処理するためにキューに渡すか否かを判定するのに使用するルールの基本集合の詳細を示す表８３５である。
【００５５】
ｉｎｏｄｅ採集器プロセス８３０は、（１）対象ｉｎｏｄｅ（与えられたｉｎｏｄｅ番号）のベーススナップショットのバージョンが選択されたＱｔｒｅｅに割り当て及び配置される（ボックス８６０）のか、（２）対象ｉｎｏｄｅの差分スナップショットのバージョンが選択されたＱｔｒｅｅに割り当て及び配置される（ボックス８６２）のかを問い合わせる。ベースバージョン及び差分バージョンがいずれも選択されたＱｔｒｅｅに割り当て及び配置されない場合、両ｉｎｏｄｅを無視し（ボックス８６４）、ｉｎｏｄｅバージョンの次のペアを参照する。
【００５６】
ベースｉｎｏｄｅは選択されたＱｔｒｅｅに割り当て及び配置されないが、差分ｉｎｏｄｅは選択されたＱｔｒｅｅに割り当て及び配置される場合、これは差分ファイルが追加されたことを意味しているので、適当なｉｎｏｄｅ変更をワーカーに送信する（ボックス８６６）。同様に、ベースｉｎｏｄｅは選択されたＱｔｒｅｅに割り当て及び配置されるが、差分ｉｎｏｄｅは選択されたＱｔｒｅｅに割り当て及び配置されない場合、これはベースファイルが消去されたことを意味しているので、これがデータストリームの形で宛先に送信される（ボックス８６８）。
【００５７】
最後に、ベースｉｎｏｄｅ及び差分ｉｎｏｄｅが両方とも選択されたＱｔｒｅｅに割り当て及び配置される場合、プロセスは、ベースｉｎｏｄｅと差分ｉｎｏｄｅが同じファイルを表すものであるか否かを問い合わせる（ボックス８７０）。それらが同じファイルを表している場合、そのファイルまたはそのメタデータ（パーミッション、所有者、パーミッションなど）は変更された可能性がある。これは、採集器プロセスによって検査されている様々なバージョンのｉｎｏｄｅ番号に対する異なる生成番号で示される。この場合、変更されたファイルが送信され、以下で説明するように、ｉｎｏｄｅは、正確な変更を判定するためにバージョンの比較を行なうように働く（ボックス８７２）。ベース及び差分がまったく同じファイルではない場合、これは、ベースファイルの消去及び差分ファイルの追加を意味している（ボックス８７４）。そのような場合、採集器によって差分ファイルの追加がワーカーキューに記入される。
【００５８】
図８Ｂは、ベーススナップショット８１０における変更されたブロックの例（ブロック１０）、及び、差分スナップショット８１２における変更されたブロック（ブロック１２）の例の各々に含まれる情報の詳細を示している。ｉｎｏｄｅ２８００は、ベースｉｎｏｄｅファイルにも差分ｉｎｏｄｅファイルにも割り当てられていない。これは、そのファイルがファイルシステムに追加されたことを意味している。また、ｉｎｏｄｅ採集器プロセスは、このｉｎｏｄｅが適当なＱｔｒｅｅ　Ｑ２（この例の場合）に配置されていることも記している。このｉｎｏｄｅは、ファイル全体が新しいものであるという注釈とともに、変更されたｉｎｏｄｅキューに送信され、処理される。
【００５９】
ｉｎｏｄｅ２８０１は、両方のｉｎｏｄｅファイルに割り当てられている。このｉｎｏｄｅは、適当なＱｔｒｅｅ　Ｑ２に配置され、２バージョンのこのｉｎｏｄｅが同じ生成番号を共有している。この時点ではファイルデータ自体に変更があったか否かが分からないので、ｉｎｏｄｅ採集器はこのペアを変更されたｉｎｏｄｅキューに送信し、ワーカーがいずれのデータに変更があったかを判定する。ｉｎｏｄｅ２８０２は、ベースｉｎｏｄｅファイルに割り当てられているが、差分ｉｎｏｄｅファイルには割り当てられていない。このｉｎｏｄｅのベースバージョンは、適当なＱｔｒｅｅ　Ｑ２にあった。これは、このｉｎｏｄｅが消去されたことを意味している。ｉｎｏｄｅ採集器は、同様にこの情報をワーカーに送信する。最後に、ｉｎｏｄｅ２８０３は、ベースｉｎｏｄｅファイルに割り当てられていて、差分ｉｎｏｄｅファイルにも再割り当てされている。ｉｎｏｄｅ採集器８３０は、２つのバージョン間で（＃１と＃２の間で）生成番号が変更されたからであることから、これを判断することができる。このｉｎｏｄｅが表すファイルはｉｎｏｄｅ２８００と同様にＱｔｒｅｅに追加されているので、このｉｎｏｄｅは、ファイル全体が新しいものであるという注釈とともに、変更されたｉｎｏｄｅキューに送信され、処理される。
【００６０】
所与の時点で、所定数のワーカーがキュー８４０に対して処理を行なう。例示の実施形態の場合、ワーカーの機能は、キュー内のｉｎｏｄｅグループに対して並行で行なわれる。つまり、ワーカーは、特に順番なくいったんキューからｉｎｏｄｅを取得すると、それらが利用可能になるや否や、さらなるｉｎｏｄｅをキューから自由に処理することができる。スキャン８２０及び採集器８３０など、他のプロセスも、順番全体の中でインタリーブされる。
【００６１】
ワーカーの機能は、ファイル及びディレクトリの各スナップショットのバージョン間の変化を判定することである。上記のように、ソーススナップショットミラーアプリケーションは、２つのスナップショットにおけるｉｎｏｄｅの２つのバージョンを分析して、それらのｉｎｏｄｅのポインタを比較するようになっている。それらのポインタの２つのバージョンが同じブロックを指している場合、そのブロックは変更されなかったことが分かる。また、間接ブロックへのポインタが変更されなかった場合、その間接ブロックにデータの変更はないので、間接ブロックのポインタが変更されることもありえず、従って、ツリーの下方にあるデータブロックに変更はなかったことになる。これが意味するのは、２つのスナップショット間でほとんど変更されていない巨大なファイルの場合、そのツリー内の各データブロックに対するＶＢＮ「ポインタ」を読み飛ばすことにより、それらのデータブロックのＶＢＮに変更があったか否かの確認をスキップすることができるということである。
【００６２】
例として、ワーカー８５０の処理を図９に示す。ワーカー８５０は、変更のあったｉｎｏｄｅ対を受信すると、各ｉｎｏｄｅ（ベース及び差分の各々）９１０及び９１２をスキャンして、各々のブロック間でファイルオフセットが一致するか否かを判定する。この例の場合、ブロック６及び７が一致しない。次いで、ブロック６及び７各々の下方へスキャンを続け、基礎とする間接ブロック８／９（９２０）及び８／１０（９２２）に到達する。ここでも、ファイルオフセット比較は、ブロック８が両方とも共通ブロック９３０に到達したことを示す（従って変更されていない）。逆に、ブロック９及び１０は、オフセットが異なるため一致せず、変更されたブロック９４０及び９４２を指している。変更されたブロック９４２及び上記メタデータは、宛先の複製スナップショット（以下で説明する；図８も参照）に伝送するため、単独で取り出すことができる。例示の実施形態のツリーは４階層の深さまであるが、この手順は、いかなる階層数にも適用することができる。また、ツリーは複数の変更されたブランチを含む場合があり、ワーカーは、それらの変更がすべて識別されるまで、それらのブランチの各々を再帰的にたどらなければならない場合もある。従って、各ｉｎｏｄｅワーカーは、以下に説明する方法で伝送するために、それらの変更をネットワークに提供する。特に、古い、消去されたブロックに関する新たなブロック及び情報が宛先に送信される。同様に、変更されたブロックに関する情報も送信される。
【００６３】
注意して欲しいのは、この例ではほとんどあらゆるデータ構造がファイルになっているので、上記のプロセスは、ファイルデータだけでなく、ディレクトリ、アクセスコントロールリスト（ＡＣＬ）、及び、ｉｎｏｄｅファイル自体にも適用することができるということである。
【００６４】
さらに注意して欲しいのは、このソース手順は、ボリュームｉｎｏｄｅファイル全体を含む、あらゆる粒度のファイルシステム構成に適用することができるということである。本来のＱｔｒｅｅ構成を用いることにより、そのボリュームの既知のサブセットを複製するための迅速で効率的な方法が得られる。
【００６５】
２．ソースと宛先の間の通信
図１０を参照すると、ソーススナップショットから複製された宛先スナップショットへの変更の伝送が、概観１０００に図示されている。既に説明したように、古いスナップショット及び新たなスナップショットは、対象ボリュームのＱｔｒｅｅその他の選択された下位構成に対応する変更されたｉｎｏｄｅを、ｉｎｏｄｅ採集器８３０に提示する。これらの変更されたｉｎｏｄｅはキュー８４０に配置され、次いで、ｉｎｏｄｅワーカー８５０、８５２及び８５４の集合が、各々のツリーの変更を調べる。ｉｎｏｄｅワーカーは各々、変更情報を含むメッセージ１００２、１００４及び１００６をソースパイプライン１０１０に送信する。このパイプラインはファイルシステムデータを１つのデータストリームにパッケージングしてネットワーク層に送信するための手段を実現する方法の一例にすぎないことに注意して欲しい。これらのメッセージは先ず受信器１０１２にルーティングされ、受信器がこれらのメッセージを収集し、ネットワークを介して送信すべきスナップショット変更情報を含むグループとしてそれらのメッセージをアセンブラ１０１４に送信する。ここでも、本明細書に記載する「ネットワーク」は、ソースと宛先が同じファイルサーバ、ボリューム上にある場合でも、ソース下位構成から宛先下位構成へのボリューム下位構成（例えばＱｔｒｅｅ）変更データの伝達を容易にするいかなるものも含むように広く解釈しなければならず、実際、（「ＳＹＳＴＥＭ　ＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＲＥＭＯＴＥ　ＡＳＹＮＣＨＲＯＮＯＵＳ　ＭＩＲＲＯＲＩＮＧ　ＵＳＩＮＧ　ＳＮＡＰＳＨＯＴＳ」と題する、上で取り込まれた米国特許出願に記載されている巻き戻しの場合では、）異なる時点で同じ下位構成になっている。同じボリュームに戻る経路として用いられる「ネットワーク」の一例は、ループバックである。アセンブラ１０１４は、ネットワーク３１８を介して情報のデータストリームを送信するため、宛先が予測及び理解することのできる特別なフォーマット１０２０を作成する。ネットワーカー１０１６は、その組み立てられたデータストリームを受信して、それをネットワーク層に転送する。このフォーマットは、ＴＣＰ／ＩＰ等、信頼性の高いプロトコルの中にカプセル化されるのが普通である。カプセル化はネットワーク層で実施することができ、この層が例えばフォーマットされた複製データストリームのＴＣＰ／ＩＰパケットを作成する。
【００６６】
フォーマット１０２０について、以下でさらに説明する。概して、このフォーマットの使用は、複数のプロトコル属性（例えば、ＵＮＩＸ（Ｒ）のパーミッション、ＮＴのアクセスコントロールリスト（ＡＣＬ）、複数のファイル名、ＮＴストリーム、ファイルタイプ、ファイル作成／変更など）を有することによって予測される。また、このフォーマットは、ストリーム内のデータ（すなわち、ファイル中の特定データのオフセット位置や、ファイルがファイルオフセット中に空の状態を保つ必要がある「ホール」を有するか否か）を識別ものでなければならない。また、ファイルの名称もこのフォーマットで中継しなければならない。さらに一般的に言うと、このフォーマットは更に、基礎とするネットワークプロトコルや装置（テープやローカルディスク／不揮発性記憶装置の場合）プロトコル及びファイルシステムとは無関係なものにする必要があり、つまり、その情報をシステム「不認識」なものにし、特定のオペレーティングシステムに束縛されないものにすることによって、異なるベンダーのソースシステムと宛先システムがその情報を供給できるようにする必要がある。従って、このフォーマットは、データストリームの外部に何も情報を必要としない自己表現的なものにする必要がある。このような方法で、第１のタイプのソースファイルディレクトリを別のタイプの宛先ファイルディレクトリに直ちに変換することができる。また、ソースオペレーティングシステムまたは宛先オペレーティングシステムに対する新たな改良が古いバージョンの互換性に悪影響を与えないようにする際に、拡張性も可能になる。具体的には、オペレーティングシステムによって認識されないデータ集合（例えば新しいヘッダ）は、必ず無視されるようにするか、あるいは、システムクラッシュその他の望ましくない故障をトリガすることなく予測的方法で処理されるように（すなわち、ストリームが下位互換になる）しなければならない。また、このフォーマットは、ファイルシステム全体の表現も、何らかのファイルまたはディレクトリ内部の変更されたブロック／情報だけの表現も、伝達できるものにしなければならない。さらに、このフォーマットは、ネットワーク及びプロセッサのオーバヘッドを最小限にしなければならない。
【００６７】
変更された情報は、ネットワークを介して転送され、宛先パイプライン部分１０３０で受信される。このパイプラインも、ネットワークからＴＣＰ／ＩＰパケットをＴＣＰ／ＩＰにカプセル化されたスナップショット複製データストリームフォーマット１０２０に読み出すためのネットワーカー１０３２を含む。データ読み取り及びヘッダ分離器１０３４は、様々なフォーマットヘッダ（以下で説明する）に格納された情報に作用することで、入ってきたフォーマット１０２０を認識して応答する。ファイル書き込み器１０３６は、そのフォーマットから取り出したファイルデータを宛先ファイルシステム内の適当な位置に配置する役割がある。
【００６８】
宛先パイプライン１０３０は、データ及びディレクトリ情報を、以下で詳しく説明するメイン宛先スナップショットミラープロセス１０４０に転送する。宛先スナップショットミラープロセス１０４０は、受信したスナップショット変更に基づいて宛先側に新たな複製ファイルシステムディレクトリ階層を構築するディレクトリステージ１０４２から構成される。簡単に説明すると、このディレクトリステージは、受信したフォーマットされた情報に基づいて、ファイルを消去または移動するものである。宛先からソースへのｉｎｏｄｅのマップが生成され、更新される。この方法で、ソースファイルシステムのｉｎｏｄｅ番号は、宛先ファイルシステムの対応する（しかしながら通常は異なる）ｉｎｏｄｅ番号に関連付けられる。変更または消去されたディレクトリエントリ１０５２がディレクトリステージ内の適当なディレクトリ再構築ステージで再利用されるか、または複製スナップショットから除去されるまでそれらエントリを維持するため、テンポラリすなわち「一時的」ディレクトリ１０５０が作成されることに注意して欲しい。さらに、宛先ミラープロセスのファイルステージ１０４４は、ディレクトリステージで作成したファイルを、関連ファイルヘッダから分離した情報に基づいてデータに格納する。
【００６９】
ソーススナップショット変更を編成するフォーマットを、図１１及び図１２に概略的に示す。例示の実施形態の場合、このフォーマットは、約４ＫＢのブロックに編成される。しかしながら、ヘッダのサイズ及び構成は、実施形態によって様々に異なるものでよい。特定の「ヘッダタイプ」によって識別される４ＫＢヘッダ（図１１の符号１１００）が存在する。ほぼ２メガバイト（２ＭＢ）毎の変更データについて、基本データストリームヘッダ（「データ」）が設けられる。図１１を参照すると、４ＫＢの単体ヘッダには、３つの部分、すなわち１ＫＢの汎用部分、２ＫＢの非汎用部分、及び、１ＫＢの拡張部分が含まれる。拡張部分は使用されないが、最近のバージョンでは利用することができる。
【００７０】
汎用部分１１０２には、ヘッダタイプ１１１０の識別子が含まれる。ヘッダタイプ単体（すなわち、後に関連データを伴わないヘッダ）は、データストリームの開始、データストリームの一部の終端、データストリームの終端、ヘッダにカプセル化された消去されたファイルのリスト、または、ＮＴ　ｓｔｒｅａｍｄｉｒの関係を示すことができる。最近のバージョンのＷｉｎｄｏｗｓ（Ｒ）　ＮＴは、複数のＮＴ「ストリーム」を特定のファイルネームに関連付けることができる。ストリームに関する説明は、Ｋａｙｕｒｉ　Ｐａｔｅｌ他による「ＳＹＳＴＥＭ　ＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＲＥＰＲＥＳＥＮＴＩＮＧ　ＮＡＭＥＤ　ＤＡＴＡ　ＳＴＲＥＡＭＳ　ＷＩＴＨＩＮ　ＡＮ　ＯＮ−ＤＩＳＫ　ＳＴＲＵＣＴＵＲＥ　ＯＦ　Ａ　ＦＩＬＥ　ＳＹＳＴＥＭ」と題した米国特許出願第０９／８９１１９５号に記載があり、その教示はここで参照することにより広く本発明に取り込まれる。また、汎用部分１１０２には、ヘッダが壊れていないことを確認するためのチェックサム１１１２も含まれる。さらに、ソース及び宛先が複製の進行を追跡するために用いる「チェックポイント」１１１４等、その他のデータも設けられる。ヘッダタイプのリストを設けることにより、宛先は比較的容易に下位互換モードで動作することができ、つまり、宛先バージョンの制限内で認識できるヘッダは普通に処理する一方、宛先が理解できないヘッダタイプ（比較的新しいバージョンのソースから供給される）はもっと簡単に無視することができる。
【００７１】
ヘッダ１１００の非汎用部分１１０４のデータの種類は、ヘッダタイプに応じて決まる。基本的なヘッダの場合、その非汎用部分には、後続のデータ送信に使用するファイルオフセット（１１２０）、消去ファイル（ソース側でもう使用しなくなったファイルやその生成番号の変更をリストする単体ヘッダ）、または、その他ヘッダ固有の情報（１１２４、以下で説明する）に関する情報が含まれる。この場合も、データストリームフォーマット内の適当な位置に様々な単体ヘッダが挿入される。各ヘッダは、データ集合（消去されたファイル等）または後続の情報（ファイルデータ等）を参照するように構成される。
【００７２】
図１２は、例示の複製データストリームのフォーマット１０２０をさらに詳細に表したものである。複製データストリームのフォーマットは、「データストリームの開始」という種類の単体データストリームヘッダ１２０２で始まる。このヘッダには、データストリームの属性を記述するソースによって生成された非汎用部分１１０４のデータが格納される。
【００７３】
フォーマット１０２０において、次の一連のヘッダは、様々な「パート１」情報（１２０４）を定義する。重要なのは、送信される各ディレクトリデータ集合の前に、非汎用データを有しない基本ヘッダがくることである。変更されたディレクトリだけが送信され、それらは特定の順番で到着する必要がない。また、何らかの特定ディレクトリからのデータが連続している必要もない。各ディレクトリエントリは、４ＫＢブロックにロードされる。あふれたものは、いずれも新たな４ＫＢブロックにロードされる。各ディレクトリエントリは、後ろに１以上の名称が続くヘッダである。各ディレクトリエントリは、続いてｉｎｏｄｅ及びディレクトリ名を記述する。ＮＴストリームディレクトリも送信される。
【００７４】
パート１フォーマット情報１２０４は、関連ＡＣＬを有するあらゆるファイルについてＡＣＬ情報も提供する。ＡＣＬの関連ファイルデータより前にＡＣＬを送信することにより、宛先はファイルデータが書き込まれる前にＡＣＬを設定することができるようになる。ＡＣＬは、「通常の」ファイルフォーマットで送信される。消去ファイル情報（上記の）は、こうした情報と共に１以上の単体ヘッダの非汎用部分１１０４（もしあれば）に含められて送信される。この情報を前もって送信することにより、ディレクトリ構築機は、移動と消去を区別することができるようになる。
【００７５】
パート１フォーマット情報１２０４は、ＮＴストリームディレクトリ（ｓｔｒｅａｍｄｉｒ）関係情報も保持する。１以上の単体ヘッダ（もしあれば）は、ＮＴストリームを含む宛先ファイルサーバのあらゆる変更されたファイルまたはディレクトリを、それらのストリームに変更があったか否かに関わらず通知する。この情報は、ヘッダ１１００（図１１）の非汎用部分１１０４に含められる。
【００７６】
パート１フォーマット情報１２０４は、複製データストリームにおける、シンボリックリンク、名前付きパイプ、ソケット、ブロックデバイス、または、キャラクタデバイスのあらゆる変更について、特別なファイルを含む。それらのファイルは、複製ファイルシステムにファイルを格納する前にその複製ファイルシステムを作成するためのインフラストラクチャを構築する際に、宛先を補助するのに必要となるため、最初に送信される。特別なファイルは、ＡＣＬに似たものであり、通常ファイルの形態で送信される。
【００７７】
様々なパート１情報１２０４を送信した後、このフォーマットは、「データストリームのパート１の終端」ヘッダ１２０６を必要とする。これは、非汎用部分１１０４にデータを有しない基本ヘッダである。このヘッダは、パート１が終ったので今度はファイルデータを期待するということを宛先に告げるものである。
【００７８】
パート１情報の後、このフォーマットは、ファイル及びストリームデータ１２０８を与える。ファイル内のあらゆる２ＭＢ以下の変更されたデータについて、基本ヘッダ１２１０が設けられ、その後にファイルデータ１２１２自体が続く。これらのファイルは、特定の順番で書き込む必要のないデータ、または、連続している必要のないデータで構成される。さらに、図１１のヘッダを参照すると、この基本ヘッダには、汎用部分１１０２内部の（この例の場合）「ホールアレイ」１１３２と協働する、非汎用部分１１０４に関連するブロック番号データ構造１１３０が含まれる。ホールアレイは空き空間を意味している。この構造は、実質的に、ホールアレイからファイル内の対応するブロックへのマッピングを提供する。この構造は、データブロックまたはホールを書き込むべき場所を宛先に指示する。
【００７９】
一般に、ファイル（１２１２）は、４ＫＢの塊で書き込まれ、最大でも５１２個の塊（２ＭＢ）ごとに基本ヘッダを有する。同様にストリーム（これも１２１２）も、４ＫＢ塊の通常ファイルのように送信され、ヘッダ間が最大でも２ＭＢになっている。
【００８０】
最後に、複製データストリームフォーマット１０２０の終端には、「データストリームの終端」というタイプの単独ヘッダからなるフッタ１２２０で印が付けられる。このヘッダは、非汎用部分１１０４（図１１）に何もデータを持たない。
【００８１】
３．宛先
遠隔の宛先（例えば、遠隔のファイルサーバ、遠隔のボリューム、遠隔のＱｔｒｅｅ、又は同様のＱｔｒｅｅなど）は、ネットワークを介してソースファイルサーバからフォーマットされた情報を受信すると、新たなＱｔｒｅｅを作成するか、または、既存のミラーＱｔｒｅｅ（または、他の適当な組織的構造）を変更し、それをデータで埋める。図１３は、宛先スナップショットミラープロセス１０４０の詳細を示すものである。上で簡単に説明したように、このプロセスは、２つの主要部分、すなわちディレクトリステージ１０４２とデータ又はファイルステージ１０４４から構成される。
【００８２】
ディレクトリステージ１０４２は、ソースからデータストリームを送信する際に、最初に呼び出される。このステージは、複数の個別部分から構成される。これらの部分は、すべてパート１フォーマット（非ファイル）のデータを取り扱うように設計される。例示的実施形態において、パート１のデータは、宛先に読み込まれ、ファイルとしてローカルに格納され、次いでローカル記憶装置から処理される。しかしながら、このデータはリアルタイムに到着するように処理することも可能である。
【００８３】
具体的には、ディレクトリステージ１０４２の最初の部分は、消去されたファイルヘッダの処理（１３１０）を含む。消去されたファイルについては、ｉｎｏｄｅマップ内のエントリが消去され、複製された宛先スナップ上のマッピングされたｉｎｏｄｅとソーススナップ上のｉｎｏｄｅとの関連が切断される。
【００８４】
次に、ディレクトリステージは、ツリークリーニング処理（１３１２）を請け負う。このステップは、複製されたスナップショットディレクトリ１３３０から、ソーススナップショット上で変更のあったディレクトリエントリをすべて除去する。データストリームフォーマット（１０２０）は、いずれのディレクトリエントリが追加または消去されたかを示す。実際、このフォーマットには、ベースバージョンのディレクトリからのディレクトリエントリと、差分バージョンのディレクトリからのディレクトリエントリとの両方が存在する。宛先スナップショットミラーアプリケーションは、このフォーマットされたデータストリームを宛先ディレクトリフォーマットに変換し、各エントリがｉｎｏｄｅ番号、関連名称のリスト（例えば、様々なマルチプロトコルネーム）及び、「作成」又は「消去」値を含むようにする。一般に、各ファイルは、そのファイルに関連する生成番号を有する。タプルを形成するｉｎｏｄｅ番号及び生成番号は、ファイルシステム内部でディレクトリがファイルにアクセスするために用いられる。ソースはこのタプル情報を前記フォーマットで宛先に送信し、適当なタプルが宛先システムに格納される。既存の宛先ファイルに関して、古くなった生成番号は、そのファイルがソースから消去されたことを示している。生成番号の使用については、以下でさらに説明する。
【００８５】
宛先は、ベースディレクトリエントリを消去として処理し、差分ディレクトリエントリを追加として処理する。移動またはリネームされたファイルは、消去（古いディレクトリからの、または古い名称の）として処理された後、追加（新たなディレクトリに対する、または新たな名称の）として処理される。消去その他の変更がなされたディレクトリ１０５２は、テンポラリすなわち「一時的」ディレクトリに移動され、ユーザがその場所にアクセスできないようにされる。変更されたエントリはアクティブファイルシステムの対象から完全に除去してしまうのではなく、一時的ディレクトリによって側に移動しておくことが可能になる。一時的ディレクトリエントリ自体がデータを指しているので、データが消去されたり、ディレクトリへのリンクが失われたりすることを、完全に防止することができる。
【００８６】
宛先に対するＱｔｒｅｅの基礎転送の際には、データストリーム内のファイル及びディレクトリすべてについての幅優先探索として、Ｑｔｒｅｅのルートからディレクトリステージツリー構築プロセスが実施される。次いでディレクトリステージは、ツリー構築プロセスを実施し、それらのファイルについてのスタブエントリを用いてすべてのディレクトリを構築する。しかしながら、図示の差分ディレクトリステージ（１０４２）は、本明細書に典型的に記載されるように、ツリー構築プロセス（１３１４）の基礎転送とは異なり、ソースと宛先との両方に現在存在するすべての変更されたディレクトリ（すなわち、転送より前に存在していた変更されたディレクトリ）を含むディレクトリキューから開始される。次いで差分ディレクトリステージツリー構築プロセスは、上で幅優先方法と呼んだ方法に従って、残りのディレクトリを処理する。
【００８７】
効率を高めるため、ソース側は、パス名ではなく、ｉｎｏｄｅ番号及びディレクトリブロックに依存している。通常、宛先上の複製ディレクトリツリー（この例の場合、Ｑｔｒｅｅ）のファイルは、ソース上で対応するファイルがすでに使用されているｉｎｏｄｅ番号の受信を待機することができない（可能であっても）。そのため、宛先にはｉｎｏｄｅマップが作成される。図１４に全体を示すこのマップ１４００によって、ソースは、ソース上の各ファイルを宛先に関連付けることが可能になる。このマッピングは通常、ファイルオフセットに基づく。例えば、「ｉｎｏｄｅ８７７にオフセット２０ＫＢ」を有する受信されたソースブロックは、宛先ｉｎｏｄｅ９９１２に複製される。次いでこのブロックは、宛先ファイルの適当なオフセットに書き込むことができる。
【００８８】
詳しくは、ｉｎｏｄｅマップ１４００の各エントリは、ソーススナップショット上の各ｉｎｏｄｅについてエントリを有する。マップの各ｉｎｏｄｅエントリ１４０２には、ソースｉｎｏｄｅ番号（１４０４）が索引付けされていて、このソースｉｎｏｄｅ番号を介してアクセスすることができる。これらのソースｉｎｏｄｅは、マッピングされる宛先ｉｎｏｄｅの順番とは無関係に、連続的かつ単調増加する順番でマップにリストされる。このマップは、各ソースｉｎｏｄｅ番号（１４０４）の下に、マッピングされたｉｎｏｄｅがソース上の現在のファイルと一致することを検証するためのソース生成番号（１４０６）、宛先ｉｎｏｄｅ番号（１４０８）、及び、宛先生成番号（１４１０）を含む。上記のように、ｉｎｏｄｅ番号と生成番号は、合わせて対応するファイルシステムの関連ファイルに直接アクセスするのに必要なタプルを構成する。
【００８９】
格納される宛先に関してソース生成番号が上向きにインクリメントされるので、ソース生成番号を維持することにより、宛先は、ソース上でファイルの変更や消去があったか否か（及び、そのソースに関する再割り当てされたｉｎｏｄｅ）を判定することができる。ｉｎｏｄｅの変更があったことをソースが宛先に通知する場合、ソースはタプルを宛先に送信する。このタプルは、ソースシステム上のｉｎｏｄｅを一意に識別する。まったく新しいファイルやディレクトリを作成（例えば「作成」）しなければならないことをソースが宛先に示すたびに、宛先ファイルシステムはそのファイルを作成する。宛先は、そのファイルを作成すると、自分のｉｎｏｄｅマップ１４００の新たなエントリにデータを登録する。既存のファイルやディレクトリを消去しなければならないことをソースが宛先に示すたびに、宛先は、そのファイルを消去し、ｉｎｏｄｅマップのエントリをクリアする。注意して欲しいのは、ファイルを変更する場合、ソースは、使用されるタプル及びデータを送信するだけでよいということである。宛先は、ｉｎｏｄｅマップからそのソースｉｎｏｄｅのエントリをロードする。ソース生成番号が一致した場合、そのファイルは宛先上に既に存在しているので変更しなけらばならないということが分かる。宛先は、ｉｎｏｄｅマップに記録されたタプルを用いて宛先ｉｎｏｄｅをロードする。最後に、宛先は、そのｉｎｏｄｅを用いることにより、ファイル変更を適用することができる。
【００９０】
ツリー構築プロセスの一部として、再利用されるエントリは、一時的ディレクトリから複製スナップショットディレクトリ１３３０に「移動」して戻される。従来、ファイルの移動は、移動するファイルの名前と移動される先のファイルの名前とを知っている必要があった。一時的ディレクトリでは、この移動されるファイルの元の名前を簡単に得ることができない。また、完全な移動には２つのディレクトリ（一時ディレクトリ及び複製スナップショット）を変更しなければならず、さらなるオーバヘッドを伴う場合がある。
【００９１】
しかしながら、例示の実施形態では、宛先で受信されたソースｉｎｏｄｅがｉｎｏｄｅマップ１４００のｉｎｏｄｅを指していれば、ディレクトリステージが所望のファイル名を有するファイルエントリを作成する（現在の構築スナップショットディレクトリ１３３０に）。この名称は、ソースで作成された名称と同じでよい。スナップショットディレクトリ１３３０上のそのファイルと一時ディレクトリのエントリとの間に、ハードリンク１３３２を作成する（例えば、ＵＮＩＸ（Ｒ）ベースのリンクは、１つのファイルに複数の名前を割り当てることができる）。エントリをそのようにリンクすることによって、そのエントリは、一時的ディレクトリとスナップショットディレクトリ自体のファイルとの両方によって指し示されることになる。データストリーム転送の最後に一時的ディレクトリのルートが最終的に消去される場合（一時的を削除することにより）、そのハードリンクはそのエントリに対して維持され、一時ディレクトリ内の特定エントリが消去されたり再利用されたりしないことを保証し（そのエントリのリンク数が１以上であると仮定した場合）、新たなディレクトリ上のそのファイルからデータへのパスが維持される。新しく構築したツリーに最終的に関連付けられることになるあらゆる一時エントリが同時にハードリンクされ、これによって一時ディレクトリの消去に対処する。逆に、再リンクされなかった一時エントリは残らず、事実上一時ディレクトリが消去されたときに永久に消去される。
【００９２】
マッピング及び生成番号の使用によって、ソースからのデータストリームにおける高価な（処理上の観点から）従来の完全なパス名（または相対パス名）の使用を回避できることが、分かったはずである。ソース上で変更されたファイルは、ソースや宛先にディレクトリをロードすることなく、宛先上で更新することができる。これによって、ソースから必要となる情報、及び、必要な処理量が制限される。また、ソースはディレクトリ処理のログを維持する必要もない。同様に、宛先は、現在のファイルシステム状態の集中的知識を維持する必要がないので、複数のサブディレクトリを同時に処理することができる。最後に、ソース及び宛先はいずれも、自動的に消去されたファイル等、消去されたファイルを明示的に追跡する必要がない。むしろ、ソースが消去されたファイルのリストを送信するだけで、宛先はこのリストを用いてｉｎｏｄｅマップを確認することができる。このように、ファイルを消去するためにツリーを複数回にわたって選択的に検査する必要はなく、転送の終了時に一時ディレクトリを単に除去することが、唯一のファイルクリーニングステップである。
【００９３】
ディレクトリステージ１０４２は、ツリー構築中（サブステップ１３１６）にディレクトリを処理する際に、ディレクトリ上に何らかのＡＣＬを設定する。上記のように、ファイルに対するＡＣＬ及びＮＴストリームの関係は、適当な単体ヘッダに格納される。その後、以下で説明するファイルステージで、それらのＡＣＬがファイルに設定される。ＮＴストリームは、ファイル自体が作成されるときに、そのファイルに作成される。ＮＴストリームは、実際にはディレクトリであるため、そのエントリはディレクトリフェイズの一部で処理される。
【００９４】
新たなディレクトリツリーは、データを有しないファイルや、古いデータを有するファイルを保持する場合がある。「パート１の終端」フォーマットヘッダを読み出すと、宛先ミラープロセス１０４０は、ファイルステージ１０４４に入り、そこでディレクトリツリーによって参照されるスナップショットデータファイル１３４０をデータ（例えば変更データ等）で埋める。図１５は、ソースから受信したファイルデータ１５０２を書き込むための単純化した手順１５００を示している。概して、４ＫＢブロックに入れられた各（最大）２ＭＢのデータは、対応するｉｎｏｄｅ番号に到着する。対応するエントリ１４０２は、ｉｎｏｄｅマップ１４００から調べられる。そのデータから適当なオフセット１５０４が導出され、それが所定の空の宛先スナップショットファイル１３４０に書き込まれる。
【００９５】
ディレクトリステージ１０４２及びデータステージ１０４４の終わりで、すべてのディレクトリ及びファイルが処理されると、ソースからのデータストリーム転送は完了し、新たに複製されたスナップショットが自動的にユーザにエキスポートされる。この時点で、一時ディレクトリ１０５０（まだ再構築ツリーに「移動」して戻されていない何らかのエントリを含む）の内容が消去される。
【００９６】
宛先上での複製スナップショットの最初の作成（「レベル０」転送）の後、上記の一般的手順が続く。レベル０転送と通常更新との違いはベーススナップショットが存在しないことであり、そのためこの比較は、差分スナップショットの情報を、変更ではなく常に追加及び作成として処理する。宛先ミラーアプリケーションは、既に知っている何らかのディレクトリを処理することにより、ツリー構築を開始する。宛先で作成される最初のディレクトリは、単に複製スナップショットのルートディレクトリ（Ｑｔｒｅｅルート）である。宛先ルートはｉｎｏｄｅマップ上に存在する。ソースは最終的にルート（ルートが到着するまで受信した他のファイルはバッファリングすることができる）を送信し、そのルートが既存の宛先ルートにマッピングされる。次いで、ルートで参照するファイルが宛先で受信及び読み出しされるにつれて、「作成」プロセスで、それらがマッピングされる。最終的に、ディレクトリ全体が作成され、次いでデータファイルが格納される。この後、複製ファイルシステムが完了する。
【００９７】
Ｅ．巻き戻し（ロールバック）
上記のように、ソース及び宛先は一般に、異なる時点で同じＱｔｒｅｅになる可能性がある。この場合、「巻き戻し」手順を用いることにより、スナップショットに対する変更差分が未完成になる可能性があると考えられる。本質的に、図８を参照する上記のベーススナップショット更新プロセス及び差分スナップショット更新プロセスは、災害から復旧させ、アクティブファイルシステムを所与のスナップショットの状態に戻すように、逆方向に実施される。
【００９８】
図１６を参照すると、この図は、例示的実施形態による一般的な巻き戻し手順を表している。進行中の処理として、ステップ１６０５で「第１」のスナップショットを作成する。この第１のスナップショットは、宛先上の複製スナップショットのエキスポートされたスナップショットである場合がある。一時的に、ソースからの差分更新によって、対象の宛先アクティブファイルシステム（複製スナップショット）が変更される（ステップ１６１０）。
【００９９】
パニック、クラッシュ、更新失敗等の非常事態に応答して、ユーザが開始したコマンドを終了させるため、ロールバックが開始される（ステップ１６１５）。この条件は、複製スナップショットの次の差分更新が適切に行なわれなかった場合の他、データの正確な像を反映しなかった場合などである。
【０１００】
ロールバックの開始に応じて、複製スナップショットに対するさらなる変更／更新が、停止される（ステップ１６２０）。これによって、アクティブファイルシステムを停止直後に次のステップ（下記ステップ１６２５）でアクティブファイルシステムから作成される第２のスナップショットに反映すべき状態とは異なる状態にする可能性がある、さらなる変更を回避することができる。アクティブファイルシステムに対する変更は、ファイルシステムを読み出し専用状態にしたりすべてのアクセスを拒否させる等、様々な方法を用いて停止させることができる。一実施形態では、「ＳＹＳＴＥＭ　ＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＲＥＤＩＲＥＣＴＩＮＧ　ＡＣＣＥＳＳ　ＴＯ　Ａ　ＲＥＭＯＴＥ　ＭＩＲＲＯＲＥＤ　ＳＮＡＰＳＨＯＴ」と題した上記米国特許出願に記載されているように、アクティブファイルシステムのｉｎｏｄｅルックアップのために二次的な階層を導入することによって、アクティブファイルシステムに対するアクセスをエキスポートされたスナップショットにリダイレクトしている。
【０１０１】
停止させた後、次に、変更されたアクティブファイルシステムのうちの最も新しい状態にある「第２」のエキスポートされたスナップショットを作成する（ステップ１６２５）。
【０１０２】
次にステップ１６３０で、第２のスナップショットと第１のスナップショットの変更差分を計算する。これは、図８及び図９を参照した上記手順に従って行ない、第２のスナップショットをベースとして用い、第１のスナップショットを差分として用いる。次にステップ１６３５で、計算された変更差分をアクティブファイルシステム（現在の状態で凍結されている）に適用する。この変更は、アクティブファイルシステムが最終的に第１のスナップショットに保持された状態に「巻き戻」されるように適用される（ステップ１６４０）。これが、巻き戻す必要がある緊急事態の前のアクティブファイルシステムの状態である。
【０１０３】
特定の状況では、ステップ１６２５によるアクティブファイルシステムのさらなる更新に対する停止や凍結を解除し、アクティブファイルシステムを変更やユーザ介入に対して再びアクセス可能にする場合もある（ステップ１６４５）。しかしながら、巻き戻し（下記）等の特定処理の場合、巻き戻されたＱｔｒｅｅは、複製処理による更なる変更についての制御下で維持される。
【０１０４】
この実施形態による巻き戻しの利点は、個別のログを維持したり、多量のシステムリソースを消費したりすることなく、複製されたデータ集合に対する一連の変更を元に戻すことが可能になるという点である。さらに、巻き戻しの方向、すなわち過去から現在であるか現在から過去であるかが、ほとんど問題にならない。さらに、一時ディレクトリを使用し、ファイルを消去しないことにより、この巻き戻しは、既存のＮＦＳクライアントに悪影響を与えることがない。各ＮＦＳクライアントは、ｉｎｏｄｅ番号とそのファイルの生成とを含むファイルハンドルによって、ファイルにアクセスする。システムがファイルを消去して再作成する場合、そのファイルは別のｉｎｏｄｅ／生成タプルを有することになる。そのため、ＮＦＳクライアントは、ファイルをリロード（古くなったファイルハンドルに関するメッセージを見る）することなくそのファイルにアクセスすることができない。しかしながら、一時ディレクトリによって、リンクの切れたファイルは、転送の終了時まで待たせることできる。そのため、上記の巻き戻しは、ＮＦＳクライアントが通知を出すことなく、一時ディレクトリに移動されただけのファイルを復活させることができる。
【０１０５】
ｉｎｏｄｅマップ反転
宛先複製スナップショットは、例えばソースＱｔｒｅｅスナップショットを再構築するためにソースでも必要になる場合があり（換言すれば、ソースと宛先の役割が逆になる）、一般的な巻き戻しを利用するためには、ソースと宛先の間にｉｎｏｄｅマップが適切に関連付けられている必要がある。この理由は、それらの個々のツリーにおいて、ソースｉｎｏｄｅが宛先ｉｎｏｄｅと一致しないからである。同じ理由で宛先ツリーを構築するためにｉｎｏｄｅマップが使用され、巻き戻しの間、ソースは、宛先から戻ってきたあらゆるｉｎｏｄｅの性質を判定するためにマッピングを用いる必要がある。しかしながら、宛先のｉｎｏｄｅマップは、ソースが使用するのに便利な形態で情報が有効に索引付けされていない。むしろ、ソースは、適当な値を得るために、マップに提示された順番でランダムに探しまわらなければならない場合がある。
【０１０６】
ソース中心のｉｎｏｄｅマップを生成する一方法は、マップエントリの「反転」である。図１７は、この反転を実施する手順１７００を詳細に示したものである。反転処理は、他の理由に関する災害復旧手順の一部として開始された巻き戻しの一部として（自動的に、又はユーザ指示で）開始される（ステップ１７０５）。次に、宛先及びソースは、ネゴシエーションをしてｉｎｏｄｅマップファイルを宛先からソースに転送する。このネゴシエーションは、適当な誤り訂正及び受領応答を含む既知の転送方法で行なうことができる（ステップ１７１０）。これにより、ｉｎｏｄｅが宛先からソースに転送されて格納される。
【０１０７】
次に、ソースは、各ｉｎｏｄｅについて１つのエントリを有する空のｉｎｏｄｅマップファイルを、ソースＱｔｒｅｅに作成する（ステップ１７１５）。次いで、新たな宛先は、カウンタをＮ＝１（この例の場合）で初期化する（ステップ１７２０）。Ｎは、新たな宛先Ｑｔｒｅｅ上のｉｎｏｄｅ数を表す変数である。
【０１０８】
ステップ１７２５で、新たな宛先は、格納しているｉｎｏｄｅマップファイル（すなわち、古い宛先／新たなソースからのマップ）における古い宛先に関連付けられたエントリの中から、Ｎ番目のｉｎｏｄｅを探しだす。次に、新たな宛先は、そのようなエントリが存在するか否かを判定する（判断ステップ１７３０）。エントリが存在しない場合、新たなソース（古い宛先）のＮ番目のｉｎｏｄｅが割り当てられていないことを表すゼロエントリを、新たなｉｎｏｄｅマップファイルに作成する。しかしながら、新たなソース／古い宛先のＮ番目のｉｎｏｄｅが存在した場合、判断ステップ１７３０はステップ１７４０に分岐し、新たなｉｎｏｄｅマップファイル（ステップ１７１５で作成されたもの）に新しいエントリを作成する。この新たなエントリは、新たなソース（古い宛先）のＮ番目のｉｎｏｄｅを適切な新しい宛先（古いソース）ｉｎｏｄｅにマッピングする。代替の実施形態として、この新たなｉｎｏｄｅマップはマッピングを開始する前にマップの全てのフィールドをゼロエントリにしておくこともでき、その場合、「ゼロエントリ」の作成にはｉｎｏｄｅマップに配置された既存のゼロエントリを残しておくことも含まれると広く考えられる。
【０１０９】
次いで手順１７００は、Ｎが古い宛先ファイルシステムのｉｎｏｄｅ数に等しいか否かをチェックする（判断ステップ１７４５）。等しければ、ｉｎｏｄｅマップファイルが完成し、手順は終了する（ステップ１７５０）。逆に、マッピングすべきｉｎｏｄｅがさらに存在する場合、カウンタを１だけインクリメントする（ステップ１７５５でＮ＝Ｎ＋１）。同様に、新たなｉｎｏｄｅマップにゼロエントリが作成された場合も、手順１７００は判断ステップ１７４５に分岐し、カウンタをインクリメント（ステップ１７５５）するか、終了するか（ステップ１７５０）を判断する。ステップ１７５５でカウンタがインクリメントされた場合、手順はステップ１７２５に戻り、そこでインクリメントされたＮ番目のｉｎｏｄｅを探す。
【０１１０】
例えば、図１８は、３つの例示的エントリ１８０２、１８０４及び１８０６を順番に含む、例示的な古い宛先ｉｎｏｄｅマップファイル１８００を示すものである。フィールド１４０４、１４０６（ソースｉｎｏｄｅ番号及び宛先ｉｎｏｄｅ番号）、１４０８、１４１０（ソース生成番号及び宛先生成番号）については、図１４を参照して上で説明した。エントリ１８０２は、（古い）ソースｉｎｏｄｅ７２が（古い）宛先ｉｎｏｄｅ６０５にマッピングされることを示している。同様に、エントリ１８０４はソースｉｎｏｄｅ８３を宛先ｉｎｏｄｅ３２８にマッピングし、エントリ１８０６はソースｉｎｏｄｅ１９０を宛先ｉｎｏｄｅ１５０にマッピングする。
【０１１１】
図１９は、反転手順１７００に従って、図１８の古いｉｎｏｄｅマップファイル１８００から生成された例示的な新しいｉｎｏｄｅマップファイル１９００を示すものである。この新たなマップファイルには、新たなソース（古い宛先）ｉｎｏｄｅ１９０２、新たな宛先（古いソース）ｉｎｏｄｅ１９０４、新たなソース（古い宛先）生成番号１９０６、及び、新たな宛先（古いソース）生成番号１９０８についてのフィールドが含まれる。反転の結果、新たなソースｉｎｏｄｅ１５０に関するエントリ１９１０は、適当な索引順番に存在し、新たな宛先ｉｎｏｄｅ１９０（および生成番号）とペアになる。次に（一連の連続した、間にある新たなソースｉｎｏｄｅ１５１〜３７２に関するエントリ１９１４の後）、新たなソースｉｎｏｄｅ３２８に関するエントリ１９１２は、新たな宛先ｉｎｏｄｅ８３にマッピングされる。同様に、間にある新たなソースｉｎｏｄｅ３２９〜６０４に関するエントリ１９１８の後、新たなソースｉｎｏｄｅ６０５に関するエントリ１９１６が新たな宛先ｉｎｏｄｅ７２にマッピングされる。間にあるソースｉｎｏｄｅは、他の新しく存在する宛先ｉｎｏｄｅへのマッピングを有する場合もあるし、あるいは、新たなソースｉｎｏｄｅ６０６に関するエントリ１９３０に示すように（記憶している古いソースｉｎｏｄｅマップ（１８００）上に新たな宛先ｉｎｏｄｅがなにも検出されなかった場合に、手順１７００のステップ１７３５で設けられるように）、ゼロ値を有する場合もある。
【０１１２】
Ｇ．ｉｎｏｄｅマップ関連
同一ソースの２つの複製／ミラースナップショットは、互いにミラー関係を確立することができる。これら２つのスナップショットは、元のソースに関する２つの異なる時点での表現である。図２０は、元のソース２００１が２つの複製／ミラースナップショット、すなわち宛先スナップショットＡ（２００２）及び宛先スナップショットＢ（２００４）を生成する、一般的な環境２０００を示すものである。各宛先スナップショットＡ及びＢ（２００２及び２００４）は、元のソース２００１から転送されたデータストリームのｉｎｏｄｅをマッピングするのに用いられる、ｉｎｏｄｅマップＡ及びＢ（２０１２及び２０１４の各々）に関連している。
【０１１３】
図示の例は、宛先スナップショットＡ（２００２）が、変更を転送して宛先スナップショットＢ（２００４）にミラーを作成するように、準備しているところである。しかしながら、逆の場合、すなわち宛先スナップショットＢがミラーを宛先スナップショットＢに作成する場合も考えられる。従って、宛先スナップショットＡ（２００２）は、宛先スナップショットＡからの複製データに対して所望の宛先システムとして機能する宛先スナップショットＢ（２００４）に転送を行なう際、新たなソースになる。上記の反転実施形態のように、新たなソース２００２は、そのｉｎｏｄｅマップＡ２０１２を宛先システム２００４に転送する。次いで宛先システム２００４は、２つのシステムのｉｎｏｄｅ間の関係を判定する。この場合、新たなソースシステム及び新たな宛先システムはいずれも、古いソース２００１の索引を外して各々のツリーを参照するようにした、各々のｉｎｏｄｅマップＡ及びＢ（２０１２及び２０１４）を有する。２つの個別ｉｎｏｄｅマップが存在する場合、「連携」プロセス２０１６はそれらのｉｎｏｄｅマップを１ｉｎｏｄｅづづ同時に調べる。このプロセスは、元のソース２００１の各ｉｎｏｄｅについて、ｉｎｏｄｅマップＡ及びＢの各々から「宛先ｉｎｏｄｅ／生成番号」を取り出す。次いでこのプロセスは、その新たなソースを、新たに関連づけられたｉｎｏｄｅマップ２０１８に関する適当なマップ索引として扱う。関連マップは、新たなソース索引番号に関する新たなソース生成番号が格納され、さらに各索引エントリがｉｎｏｄｅマップＢ（２０１４）から取り出した新たな宛先ｉｎｏｄｅ／生成番号に関連付け／マッピングされる。この新たなマップは、上記の原理に従って新たな宛先２００４で使用され、様々な時点に関する新たなソースでの変更に基づいて、そのディレクトリにツリーが構築される。
【０１１４】
例えば、マップＡでは古いソースＯＳｉｎｏｄｅ番号５５（ＯＳ５５）が古い宛先スナップショットＡのｉｎｏｄｅ８７（Ａ８７）にマッピングされ、マップＢではＯＳ５５が古い宛先Ｂのｉｎｏｄｅ９９（Ｂ９９）にマッピングされている場合を仮定する。Ｂを新たな宛先にし、Ａを新たなソースにするためには、共通索引ＯＳ５５に基づいて各々のマップからＡ８７及びＢ９９を取り出すプロセスを用いて、関連マップを作成する。関連マップには、新たなソースエントリ／新たな宛先エントリ　８７／９９が格納される。このマップには、古いマップＡ及びＢからのそれらの値を有する関連生成番号も含まれる。この手順は２つの古い宛先システムに適用されているが、本明細書に記載される方法に従う様々な方法により、３以上のシステムに適用することも可能であると考えられる。
【０１１５】
上記が本発明の例示的実施形態の詳細な説明である。本発明の思想及び範囲から外れることなく様々な変更及び追加を行なうことができる。例えば、図示の相互接続されたソースサーバ及び／又は宛先サーバの数は、異なる数にしてもよい。実際、ソースサーバと宛先サーバは同一マシンにすることもできる。複数のソースがデータを宛先に転送することができ、またその逆可能であると広く考えられる。同様に、サーバの内部アーキテクチャやそれらのストレージアレイ、並びに、ネットワーク接続及びプロトコルは、すべて大きく異るものでよい。様々なソースサーバ及び宛先サーバ上で用いられるオペレーティングシステムも異なっていてよい。さらに、本明細書に記載されるオーレーティングシステム及び手順はいずれも、ハードウェア、ソフトウェア、コンピュータ上で実行されるプログラム命令を有するコンピュータ読み取り可能な媒体、あるいは、ハードウェアとソフトウェアの組み合わせで実施することができる。
【図面の簡単な説明】
【図１】従来の実施形態によるネットワークを介したソースファイルサーバから宛先ファイルサーバへのボリュームスナップショットの遠隔ミラーリングを示す略ブロック図である。
【図２】従来の実施形態により図１の相違検出器がソースファイルサーバから宛先ファイルサーバへブロックの変更を送信すべきか否かを判定するために用いる判断テーブルである。
【図３】本発明の原理を実施するソースファイルサーバ及び宛先ファイルサーバを含む、例示的ネットワーク及びファイルサーバ環境を表す略ブロック図である。
【図４】図３のファイルサーバで使用される例示的ストレージオペレーティングシステムを示す略ブロック図である。
【図５】例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図６】スナップショットｉｎｏｄｅを含む、図５の例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図７】データブロックが書き替えられた後の図６の例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図８】スナップショットミラーリングプロセスのソースでの例示的処理を示す略ブロック図である。
【図８Ａ】図８のスナップショットミラーリングプロセスにおいてｉｎｏｄｅ採集器プロセスと共に用いられる判断テーブルである。
【図８Ｂ】図８Ａのｉｎｏｄｅ採集器プロセスを示す例示的なベーススナップショットブロック及び差分スナップショットブロックを示す詳細な概略図である。
【図９】図８のスナップショットミラーリングプロセスとともに用いられるｉｎｏｄｅワーカーの例示的処理を示す略ブロック図である。
【図１０】ソースファイルサーバスナップショットミラーリングプロセス及び宛先スナップショットミラーリングプロセス、並びに、それらの間の通信リンクを示す略ブロック図である。
【図１１】例示的実施形態によるソースと宛先との間のデータストリーム伝送フォーマットに用いられる単独ヘッダ構造を示す略ブロック図である。
【図１２】例示的実施形態によるソースと宛先との間のデータストリーム伝送フォーマットを示す略ブロック図である。
【図１３】宛先におけるスナップショットミラーリングプロセスのステージを示す略ブロック図である。
【図１４】例示的実施形態によりソースｉｎｏｄｅを宛先スナップショットミラーにマッピングするための一般的なｉｎｏｄｅマップを示す略ブロック図である。
【図１５】宛先スナップショットミラーのソースデータファイルに関連してマッピングされたオフセットへのデータファイルの格納を示す極めて概略的な図である。
【図１６】例示的実施形態によるスナップショット巻き戻し手順を示すフロー図である。
【図１７】例示的実施形態によりソースファイルシステムを宛先ミラースナップショットの状態に巻き戻す、すなわち同期させるための、ｉｎｏｄｅマップ反転手順を示すフロー図である。
【図１８】図１７の反転手順で使用される、宛先にある例示的ｉｎｏｄｅマップを示す略ブロック図である。
【図１９】図１８の反転手順により古いソース（新たな宛先）上に構築された例示的ｉｎｏｄｅマップを示す略ブロック図である。
【図２０】例示的実施形態による一般的ないのでマップ関連付けプロセスを示す略ブロック図である。

Claims (18)

1. ソース上のデータブロックの論理グループにおける変更を識別し、宛先上のデータブロックの論理グループの複製を更新するためのシステムであって、
   Ａ）第１のスナップショット及び第２のスナップショットそれぞれの第１のブロック識別子の集合及び第２のブロック識別子の集合に作用するスキャナであって、前記第１のスナップショット及び前記第２のスナップショットがデータブロックの論理グループの異なるイメージに対応し、前記第１のスナップショットが前記複製に対応し、前記第２のブロック識別子の集合の中から前記第１のブロック識別子の集合のうちの対応するブロック識別子と異なる識別子をサーチすることにより、前記複製に反映されていない変更されたデータブロックを示すようになっているスキャナと、
   Ｂ）前記論理グループのブロックをすべて送信することなく、前記変更されたブロックを宛先に送信することと、
   Ｃ）前記宛先上の複製を前記変更されたブロックで更新することと、
   からなるシステム。
2. 前記スキャナは、変更のないボリュームブロック番号を有するブロックをバイパスしつつ、前記第１及び第２のスナップショットそれぞれの論理ブロック索引に関連付けられたポインタの階層を下方に移動してゆき、変更されたブロック識別子を有する指されているブロックを対応するオフセットにある指されているブロックに関して識別する、請求項１のシステム。
3. 所定の関係を有する検索されたブロックにおけるｉｎｏｄｅを取り出し、前記第１のスナップショット及び前記第２のスナップショットにおけるそれらのｉｎｏｄｅの第１のバージョンと第２のバージョンとの間の変化を示す、ｉｎｏｄｅ採集器をさらに含む、請求項１のシステム。
4. 前記所定の関係がボリュームファイルシステムの下位構成を含む、請求項３のシステム。
5. 前記下位構成前記ボリュームファイルシステム内のＱｔｒｅｅを含む、請求項４のシステム。
6. 前記ｉｎｏｄｅ採集器によって取得され待ち行列に入れられたブロックに対して作用し、取り出された前記ｉｎｏｄｅの各々の第１のバージョンの階層におけるブロック間の変化を、取り出された前記ｉｎｏｄｅの各々の第２のバージョンの階層に関して、前記スキャナを用いて計算する、ｉｎｏｄｅワーカーをさらに含む、請求項４のシステム。
7. 前記ｉｎｏｄｅワーカーは、前記変化を収集し、該変化をデータストリームにパッケージングするパイプラインに転送して、前記宛先ファイルシステムに伝送する、請求項６のシステム。
8. 前記ソースファイルシステムと前記宛先ファイルシステムとの間の変化を送信する拡張可能でファイルシステム非依存なフォーマットをさらに含む、請求項７のシステム。
9. 宛先上のデータブロックの論理グループの複製を、ソース上の対応する論理グループにおける変化を用いて更新するための方法であって、
   Ａ）ソース上の論理グループの第１のスナップショットの第１のブロック識別子の集合が前記複製に対応し、これをソース上の論理グループの第２のスナップショットの第２のブロック識別子の集合と比較することにより、変更された論理グループ内の対応する位置にあるデータブロックを識別することと、
   Ｂ）前記論理グループのブロックをすべて送信することなく、前記変更されたブロックを送信することと、
   Ｃ）前記宛先上の複製を送信された前記変更されたブロックで更新することと、
   からなる方法。
10. 前記第１のスナップショット及び第２のスナップショットは第１及び第２の時点での前記ソース上の論理グループのイメージにそれぞれ対応し、前記比較するステップは、前記第１及び第２のブロック識別子の集合の対応するブロック識別子であって前記第１の時点と前記第２の時点との間で変更がなかったブロック識別子を選択する、請求項９の方法。
11. 前記ソース上の論理グループは階層構造を含み、前記第１及び第２のブロック識別子の集合は、それぞれ前記階層構造に対応する階層的ブロック索引を含み、前記選択するステップは、前記階層的ブロック索引をサーチして変更されたブロックを識別するスキャナによって実施される、請求項１０の方法。
12. 前記第１及び第２のｍブロック識別子の集合のブロック識別子はソース上の論理グループ内の対応する位置にあるデータブロックを参照し、前記選択するステップは、前記論理グループ内の同じ位置にあるデータブロックを参照する前記第１及び第２のブロック識別子の集合のブロック識別子を比較することにより、変更されたブロックを選択する、請求項１１の方法。
13. ｉｎｏｄｅ採集器を用いて所定の関係を有するｉｎｏｄｅを取り出し、前記第１のスナップショット及び前記第２のスナップショットにおけるそれらのｉｎｏｄｅの第１のバージョンと第２のバージョンとの間の変化を示すことをさらに含む、請求項９の方法。
14. 前記所定の関係がボリュームファイルシステムの下位構成を含む、請求項１３の方法。
15. 前記下位構成が前記ボリュームファイルシステム内のＱｔｒｅｅを含む、請求項１４の方法。
16. ソース上のデータブロックの論理グループから変更のデータストリームを受信して、宛先上の論理グループの複製を更新するためのシステムであって、
    Ａ）前記ソース上の論理グループの構造を表すメタデータを読み出し、ソース上の論理グループに対する参照を宛先上の論理グループに対する参照にマッピングして変更されたブロックを識別する、メタデータステージプロセスと、
    Ｂ）マッピングされた前記参照に応じて、前記複製上の論理グループを、前記論理グループ内の対応するオフセットで変更のあった前記ソースからのデータブロックで埋める、データステージプロセスと、
    からなるシステム。
17. ソース上のデータブロックの論理ブロックに対する変更を識別し、宛先上の前記論理グループの複製を更新するためのシステムであって、
    Ａ）前記ソース上の論理グループに関する構造を表すメタデータであって前記ソース上の論理グループのデータブロックに対する第１の参照の集合を含むメタデータを読み出すステップ（ｉ）と、読み出した前記メタデータの複製を生成するステップ（ｉｉ）とを含み、前記第１の参照の集合を宛先上の論理グループのデータブロックに対する第２の参照の集合にマッピングするステップを含む、メタデータステージプロセスと、
    Ｂ）前記複製を前記第２の参照の集合によって参照されるデータブロックで埋めるステップを含み、前記メタデータステージプロセスに応答する、データステージプロセスと、
    からなるシステム。
18. 宛先上の複製を更新するための方法であって、
    Ａ）スナップショットの変更されたデータから、宛先上で消去および変更されたデータの論理グループに関する識別子を読み出し、該消去および変更された論理グループを前記複製の主記憶装置とは別の一時記憶装置に入れることと、
    Ｂ）前記一時記憶装置にある前記消去及び変更された論理グループに対する一連の参照を前記主記憶装置に作成することと、
    Ｃ）前記作成するステップの後、前記主記憶装置にある前記消去及び変更されたデータの論理グループに対する参照を維持しつつ、前記一時記憶装置を再割り当てすることと、
    からなる方法。

Images