(57)【要約】　　　（修正有）【課題】複数のスナップショットが与えられたときにそれを管理するためのシステム及び方法の提供。【解決手段】ファイルシステム内にそのファイルシステムを表す一連のメタデータを含め、ファイルシステムのスナップショットがそれに関連するメタデータを含むようにする。従来のダンプ・リストア技術を用いてバックアップクライアントファイルシステムをバックアップサーバに復元する。次いでバックアップサーバは、ユーザ定義のスナップショット管理スケジュールに従って、そのバックアップサーバに関する一連のバックアップを管理する。こうしたスナップショットの管理には、タイプスタンプを含む様々なパラメタに基くスナップショットの消去が含まれる。【選択図】図３
2004038929.tif 000002
【特許請求の範囲】
【請求項１】
バックアップサーバに関するファイルシステムの複数のスナップショットを管理するための方法であって、
（ａ）ファイルシステムのベースラインスナップショットをバックアップサーバ上に作成するステップと、
（ｂ）前記バックアップサーバに対して差分復元を実施するステップと、
（ｃ）新たなスナップショットを前記バックアップサーバ上に作成するステップと、
（ｄ）前記ベースラインスナップショット及び前記新たなスナップショットを含む複数のスナップショットを、維持方針に従って管理するステップと、
からなる方法。
【請求項２】
前記差分復元を実施するステップは、一連のバックアップクライアントから前記バックアップサーバへの差分復元を実施するステップを含む、請求項１の方法。
【請求項３】
前記ベースラインスナップショットをバックアップサーバ上に作成するステップは、
バックアップクライアントに関するファイルシステムのベースラインダンプを実施し、該ベースラインダンプが前記バックアップサーバ上のベースラインファイルシステムにパイプされるようにするステップと、
前記ベースラインファイルシステムのスナップショットを前記バックアップサーバ上に作成するステップと、
をさらに含む、請求項１の方法。
【請求項４】
二次システムに関するデータブロックの論理グループの複数のスナップショットを管理するための方法であって、
（ａ）前記論理グループのベースラインスナップショットを前記二次システム上に作成するステップと、
（ｂ）少なくとも１つの一次システムから前記二次システムへ差分復元を実施するステップと、
（ｃ）前記二次システムに関する論理グループの新たなスナップショットを作成するステップと、
（ｄ）前記ベースラインスナップショット及び前記新たなスナップショットを含む複数のスナップショットを、維持方針に従って管理するステップと、
からなる方法。
【請求項５】
前記ベースラインスナップショットを作成するステップは、
バックアップクライアントファイルシステムを前記バックアップサーバに関するファイルシステムに複製するステップと、
前記バックアップサーバに関するファイルシステムのベースラインスナップショットを作成するステップと、
をさらに含む、請求項４の方法。
【請求項６】
少なくとも１つのバックアップクライアントに相互接続されたバックアップサーバであって、
少なくとも１つのバックアップクライアントに関するファイルシステムの複製を、前記バックアップサーバに関する１以上のファイルシステム上に作成するための手段と、
前記バックアップサーバに関する１以上のファイルシステムのスナップショットを作成するための手段と、
前記１以上のバックアップクライアントからの差分復元処理に応答して、前記バックアップサーバに関連する１以上のファイルシステムを漸進的に更新するための手段と、
複数のスナップショットを維持方針に従って管理するための手段と、
からなるバックアップサーバ。
【請求項７】
ファイルシステムの自己表現可能なスナップショットを作成するための方法であって、
メタデータファイルをファイルシステムに作成するステップと、
前記メタデータファイルにファイルシステム情報を記憶するステップと、
前記ファイルシステムのスナップショットであって、該スナップショットに前記メタファイルが含まれるスナップショットを作成するステップと、
からなる方法。
【請求項８】
前記ファイルシステム情報が前記ファイルシステムに関する状態情報を更に含む、請求項７の方法。
【請求項９】
ファイルシステムのスナップショットに記憶されたファイルにアクセスするための方法であって、
前記ファイルシステムのルートディレクトリを復元するステップと、
前記ファイルへのパスに関連する一連のディレクトリを復元するステップと、
前記ファイルへのパスに関連しないディレクトリは復元せずに、前記スナップショットから前記ファイルを復元するステップと、
からなる方法。
【請求項１０】
（ａ）ファイルシステムのベースラインスナップショットをバックアップサーバ上に作成するステップと、
（ｂ）前記バックアップサーバに対して差分復元を実施するステップと、
（ｃ）新たなスナップショットを前記バックアップサーバ上に作成するステップと、
（ｄ）前記ベースラインスナップショット及び前記新たなスナップショットを含む複数のスナップショットを、維持方針に従って管理するステップと、
を実施するためのプログラム命令を含むコンピュータ読み取り可能な媒体。
【請求項１１】
バックアップサーバに関するファイルシステムの複数のスナップショットを管理するためのシステムであって、
（ａ）ファイルシステムのベースラインスナップショットをバックアップサーバ上に作成するための手段と、
（ｂ）前記バックアップサーバに対して差分復元を実施するための手段と、
（ｃ）新たなスナップショットを前記バックアップサーバ上に作成するための手段と、
（ｄ）前記ベースラインスナップショット及び前記新たなスナップショットを含む複数のスナップショットを、維持方針に従って管理するための手段と、
からなるシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータ保護及びデータ復元に関し、特にデータの複数のバックアップの管理に関するものである。
【０００２】
【従来の技術】
ファイルサーバは、ディスク等の記憶装置上での情報の編成に関するファイルサービスを提供するコンピュータである。ファイルサーバまたはファイラーには、ディスク上で情報をディレクトリやファイルの階層構造として論理的に編成するためのファイルシステムを実施するストレージオペレーティングシステムが含まれる。「ディスク上」の各ファイルはテキスト等の情報を記憶するように構成されたディスクブロックの集まりとして実現され、ディレクトリは他のファイルやディレクトリに関する情報を記憶する特別な形式のファイルとして実現される。ファイラーはクライアント／サーバ形態の情報配送に従って動作するように構成され、多数のクライアントがサーバ、例えばファイラー上に格納されたファイルにアクセスできるようになっている。この形態の場合、クライアントは、ポイント・ツー・ポイントリンク、共用ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、あるいは、インターネット等の公共ネットワーク上で実施される仮想私設ネットワーク（ＶＰＮ）などのコンピュータネットワークを介してファイラーに「接続」するためのファイルシステムプロトコル等のアプリケーションを、コンピュータ上で実行している場合がある。各クライアントは、ネットワークを介してファイルシステムプロトコルメッセージを（パケットの形態で）ファイラーに発行することによって、ファイラーにサービスを要求することができる。
【０００３】
一般的なタイプのファイルシステムは「定位置書き込み」ファイルシステムであり、その一例は従来のバークレイ・ファーストファイルシステムである。定位置書き込みファイルシステムでは、ｉｎｏｄｅやデータブロック等のデータ構造のディスク上での位置が通常固定されている。ｉｎｏｄｅはファイルに関するメタデータ等の情報を記憶するためのデータ構造であり、データブロックはそのファイルの実際のデータを記憶するのに用いられる構造である。ｉｎｏｄｅに含まれる情報には例えば、ファイルの所有者、ファイルのアクセス権、ファイルサイズ、ファイルタイプ、および、そのファイルに関するデータブロックのディスク上の位置に対する参照などが含まれる。ファイルデータの位置に対する参照はポインタを用いて提供され、そのファイルのデータ量に応じて間接的なブロック、即ちデータブロックに対する参照をさらに参照する場合がある。ｉｎｏｄｅ及びデータブロックに対する変更は、定位置書き込みファイルシステムに従って「定位置」で行なわれる。ファイルの更新によってそのファイルのデータ量が増える場合、さらにデータブロックが割り当てられ、適当なｉｎｏｄｅがそのデータブロックを参照するように更新される。
【０００４】
他のタイプのファイルシステムには、ディスク上のデータを上書きしないＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムがある。ディスクからそのディスク上のデータブロックがメモリに取得され（読み出され）、新たなデータで汚される場合、そのデータブロックがディスク上の新たな位置に格納される（書き込まれる）ので、書き込み効率が最適になってる。Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムは、データがディスク上で実質的に連続で配置されるように、まず最適なレイアウトを推定する。この最適なレイアウトによって、特にディスクに対するシーケンシャル読み出し処理に関して、効率的なアクセス処理が可能になる。ファイラー上で動作するように構成されたＷｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムの一例は、カリフォルニア州サニーベイルにあるネットワークアプライアンス社から入手できるＷｒｉｔｅ　Ａｎｙｗｈｅｒｅ　Ｆｉｌｅ　Ｌａｙｏｕｔ（ＷＡＦＬ）ファイルシステムである。ＷＡＦＬファイルシステムは、ファイラー及び関連ディスクストレージのプロトコルスタック全体のうちの一部としてマイクロカーネル内で実施される。このマイクロカーネルは、ネットワークアプライアンス社のＤａｔａ　ＯＮＴＡＰストレージオペレーティングシステムの一部として提供され、ネットワーク取り付けされたクライアントからのファイルサービス要求を処理する。
【０００５】
本明細書で用いるように、「ストレージオペレーティングシステム」という用語は通常、ファイルシステムセマンティックを実施しデータアクセスを管理するストレージシステム上で動作可能なコンピュータ実行可能コードを意味している。この意味で、Ｄａｔａ　ＯＮＴＡＰソフトウェアは、マイクロカーネルとして実現されるこうしたストレージオペレーティングシステムの一例である。ストレージオペレーティングシステムは、例えばＵＮＩＸ（Ｒ）やＷｉｎｄｏｗｓ（Ｒ）　ＮＴ等の汎用オペレーティングシステム上で動作するアプリケーションプログラムとして実施することもできるし、あるいは、本明細書に記載するようなストレージアプリケーションとして構成された設定可能な機能を有する汎用オペレーティングシステムとして実施することもできる。
【０００６】
ディスクストレージは通常、ストレージ空間の全体的な論理的配置を定義する、物理的記憶ディスクを含む１以上のストレージ「ボリューム」として実施される。現在利用可能なファイラー実施形態は、多数の個別のボリューム（例えば１５０以上）を使用することができる。各ボリュームにはそのボリュームに固有のファイルシステムが関連付けられているので、その意味で、ボリュームとファイルシステムは一般に同義語として用いられる。ボリューム内のディスクは通常、１以上のグループのＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙ　ｏｆ　Ｉｎｄｅｐｅｎｄｅｎｔ（Ｉｎｅｘｐｅｎｓｉｖｅ）　Ｄｉｓｋｓ）に編成される。ＲＡＩＤ実施形態は、ＲＡＩＤグループ内の所定数の物理ディスクにわたってデータ「ストライプ」を冗長書き込みし、そのストライプ化されたデータに関するパリティ情報を適当にキャッシュすることによって、データ記憶の信頼性／完全性を向上させている。ＷＡＦＬファイルシステムの一例では、ＲＡＩＤ４実施形態が有利に用いられる。この実施形態では、１グループのディスクにわたってデータをストライピングし、ＲＡＩＤグループのうちの選択されたディスク内で個別にパリティをキャッシュする必要がある。本明細書で説明するように、ボリュームは通常、ＲＡＩＤ４または同等の高信頼性の実施形態に従って配置された、少なくとも１台のデータディスク及び１台の関連パリティディスク（データ／パリティの場合もある）パーティションを含む。
【０００７】
ファイルサーバ環境において、データ保護は、選択されたボリューム及び／又はファイルシステムのバックアップを作成することにより実施されるのが通常である。これらのバックアップはテープドライブに記憶されるのが一般的である。既知のファイルサーバ構成の中には、ファイルシステムまたはボリューム全体の完全なバックアップを最初に作成するものもある。この完全なバックアップは、選択されたボリュームまたはファイルシステムに格納されたすべてのデータを記憶するものである。その後、時間間隔を設定して差分バックアップを作成する。これらの差分バックアップは、データの完全なバックアップまたは最後の差分バックアップと現在の状態との間の変化分、即ち差分を記録するものである。これらのバックアップ、即ち完全なバックアップと差分バックアップは、いずれもテープに通常書き込まれる。バックアップをテープ装置に書き込むことの主な欠点は、バックアップデータを記憶装置に格納する時にある。バックアップ処理中は、テープバックアップ処理に伴う大きな処理オーバヘッドに起因して、サーバ全体の性能が実質的に低下してしまう。この処理オーバヘッドは、ファイルシステムまたはボリュームを含むディスクから大量のデータをバックアップテープ装置に移動する際に必要となる複製処理によって生じるものである。
【０００８】
テープバックアップからファイルシステムを復元する場合、そのファイルシステムを完全に復元するまでに、多数の差分バックアップが使用される。アクティブファイルシステムを復元するためには、増分すなわち差分バックアップの各々を適切な順番で個別に復元する必要がある。そのため、一連のテープバックアップからファイルシステムを完全に復元するためには、完全なバックアップを最初に復元しなければならない。その後、差分バックアップを適切な順序でファイルシステムに復元する。
【０００９】
テープバックアップシステムは低速であること及びその他上記の欠点があるので、多くの管理者はテープレスのバックアップで代替することを好む傾向がある。市販のテープレスバックアップの一例としては、ニュージャージー州オーシャンポートにあるＣｏｍｍ　Ｖａｕｌｔ　Ｓｙｓｔｅｍｓ社が製造しているＣｏｍｍ　Ｖａｕｌｔ　Ｇａｌａｘｙストレージマネジメントソフトウェアがある。Ｃｏｍｍ　Ｖａｕｌｔ　Ｓｙｓｔｅｍｓ社は、ジュークボックス構成にした光磁気ディスクドライブまたはコンパクトディスクドライブを利用している。この既知の実施形態は、データのランダムアクセスが可能であり、単一ファイル復元が可能である。しかしながら、こうしたジュークボックスシステムの主な欠点は、完全なバックアップ及び差分バックアップの全体を格納するために多数の光ディスクが必要になることである。これらの光ディスクは、記憶され、取り扱われ、変更される必要があるので、損失や損害を受ける可能性がある。
【００１０】
発明の概要
この従来技術の欠点は、複数のスナップショットを管理するシステム及び方法を提供することにより、克服される。管理を容易にするため、スナップショットを作成すべきアクティブファイルシステムに、そのファイルシステムの状態に関するデータを記憶するメタデータファイルを作成する。次いでこの状態情報は様々なアプリケーションに利用され、特定のスナップショットをどのように管理すべきかの判定に用いられる。ファイルシステムのスナップショットにこのメタデータを含めることによって、そのスナップショットは、スナップショットを作成したそのファイルシステムの様々な状態情報を含めることにより、自己表現が可能になる。結果得られるシステムは、遠隔の保存先バックアップサーバに高速かつ低オーバヘッドでテープレスでバックアップすることが可能になる。
【００１１】
スナップショットを生成することが可能なファイルシステムを利用する宛先バックアップサーバは、そのバックアップサーバのバックアップクライアントが従来のバックアップ処理及び復元処理、すなわち複製処理を実施することで、バックアップサーバ上にバックアップクライアントファイルシステムを複製することができるようになっている。バックアップサーバのファイルシステムのスナップショットは、所定の時刻に作成される。次いでバックアップサーバのストレージオペレーティングシステム内のプロセスが、収集したそれらのスナップショットをユーザ定義のスケジュールに従って管理する。この複数のスナップショットの管理機能には、記憶したスナップショットを、例えばそのスナップショットのメタデータに格納されたタイムスタンプ等、様々なパラメタに基いて消去することなどが含まれる。
【００１２】
バックアップクライアントは、ファイルシステム全体を完全に復元することなく、所望のファイルへのパスを選択的に復元することができる。このオンデマンドな復元は、スナップショットが作成されたファイルシステムのルートディレクトリを復元した後、特定ファイルへのパスに含まれるディレクトリだけを復元することによって、実施される。部分的に復元されたこのディレクトリのｉｎｏｄｅには、ファイル及び／又はディレクトリについて更にバックアップサーバにアクセスすべきことを、バックアップクライアントのファイルシステムに警告するマークが付けられる。
【００１３】
【発明の実施の形態】
Ａ．ネットワーク環境
図１は、本発明の原理を実施する例示的ネットワーク環境１００を示す略ブロック図である。ネットワーク１００は、ネットワーククラウド１０２を取り囲むように構成される。このネットワーククラウドは、ローカルネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）である場合もあるし、インターネットを介した通信リンクを利用する仮想私設網（ＶＰＮ）である場合もあり、あるいは、ＬＡＮ、ＷＡＮ及びＶＰＮ実施形態の組み合わせで構成することもできる。説明のため、ネットワーククラウドという用語は、許容されるあらゆるネットワークを含むように広く解釈すべきである。ネットワーククラウド１０２は様々なクライアント１０４を相互接続する。また、ネットワーククラウドには、ファイルサーバ２００も取り付けられる。以下で説明するこのファイルサーバは、相互接続されたストレージボリューム１０６の集合１０８の記憶及びデータに対するアクセスを制御するように構成される。ファイルサーバには、テープドライブ１１０が接続される。既知のバックアップ例として、ファイルサーバ２００は、ディスク１０６上に記憶されたデータをテープドライブ１０６にバックアップする場合がある。ネットワーククラウドに取り付けられた各装置は、周知のトランスファー・コントロール・プロトコル／インターネット・プロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト・トランスファー・プロトコル（ＨＴＴＰ）、シンプルネットワーク・マネジメント・プロトコル（ＳＮＭＰ）、あるいはバーチャル・インターフェースコネクション（ＶＩ）など、所望の通信プロトコルを用いてネットワーククラウドを介して通信する適当な従来のネットワーク構成を有する。
【００１４】
Ｂ．ファイルサーバ
図２は、例示的ファイルサーバ２００の詳細を示す略ブロック図である。背景として、ファイルサーバまたはファイラーは、ディスク等の記憶装置に対する情報の編成に関するファイルサービスを提供するコンピュータである。しかしながら、当業者であれば、本明細書で説明する概念は、いかなる種類のファイルサーバにも適用することが可能であり、スタンドアロンのコンピュータを含めて専用コンピュータとしても汎用コンピュータとしても実施できることが分かるであろう。
【００１５】
ファイルサーバ２００は、システムバス２１２で相互接続されたプロセッサ２０２、メモリ２０４、ネットワークアダプタ２０６、不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）２０８、及び、ストレージアダプタ２１０を含む。メモリ２０４の中には、情報をディスク上でディレクトリ及びファイルの階層構造として論理的に編成するためのファイルシステムを実現するストレージオペレーティングシステム３００が含まれる。例示的実施形態として、メモリ２０４は、プロセッサ及びアダプタがアドレス指定してソフトウェアプログラムコードを記憶することが可能な記憶場所を含む。ストレージオペレーティングシステムの一部は通常、メモリ内に存在し、処理要素によって実行され、典型的には、ファイルサーバによって実施されるファイルサービスをサポートする記憶処理を呼び出すことにより、ファイラーの機能を構成する。
【００１６】
ネットワークアダプタ２０６は、ファイルサーバ２００をネットワーククラウド１０２を介してクライアント１０４に接続するのに必要な機械回路、電気回路および信号回路を含む。クライアント１０４は、データベースアプリケーション等のアプリケーションを実行するように構成された汎用コンピュータである。また、クライアント１０４は、クライアント／サーバ形態の情報配送に従ってファイルサーバ２００と対話することができる。このように、適当なネットワークプロトコルで定義されたパケットを交換することにより、クライアントはファイルサーバのサービスを要求することができ、ファイルサーバはクライアントから要求されたそのサービスの結果を返送することができる。
【００１７】
ストレージアダプタ２１０は、ファイルサーバ上で実行されているストレージオペレーティングシステム３００に含まれ、クライアントから要求のあった情報にアクセスする。情報は、ストレージアダプタ２１０を介して、ファイルサーバに取り付けられたディスク１０８（図１）のディスク１０６上に記憶される。ストレージアダプタ２１０は、従来の高性能ファイバーチャネル・シリアルリンク技術等のＩ／Ｏ相互接続技術を介してディスクに接続するための入出力（Ｉ／Ｏ）インタフェース回路を含む。情報は、ストレージアダプタによって取得され、システムバス２１２を介してネットワークアダプタ２０６に転送される前に、必要であればプロセッサ２０２（あるいはアダプタ２１０自体）によって処理され、ネットワークアダプタ２０６で適当なパケットに成形されてクライアント１０４に返送される。
【００１８】
ファイルサーバの一例示的実施形態として、ファイルサーバは、データのフォールトトレランスなバックアップを可能にする不揮発性ランダムアクセスメモリ（ＮＶＲＡＭ）２０８を含む場合があり、ファイルサーバトランザクションの完全性を確保して電源故障その他の故障によるサービス停止を切り抜けることができる場合がある。
【００１９】
Ｃ．ストレージオペレーティングシステム
アレイ１０８上のディスク１０６に対して普通にアクセスできるようにするため、ストレージオペレーティングシステム３００は、Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルシステムを実施して、情報をディスク上にディレクトリ及びファイルの階層構造として編成する。「ディスク上」の各ファイルはデータ等の情報を記憶するように構成されたディスクブロックの集まりとして実現され、ディレクトリは他のファイルまたはディレクトリが記憶された特別な形態のファイルとして実現される。上記のように、本明細書に記載する例示的実施形態の場合、ストレージオペレーティングシステムは、ネットワークアプライアンス社から入手できるＮｅｔＡｐｐ　Ｄａｔａ　ＯＮＴＡＰ（Ｒ）オペレーティングシステムであり、Ｗｒｉｔｅ−ａｎｙｗｈｅｒｅファイルレイアウト（ＷＡＦＬ（Ｒ））ファイルシステムを実現する。任意の適当なファイルシステムを利用することが可能だと考えられるので、ＷＡＦＬファイルシステムという用語を用いた場合でも、この用語は本発明の教示に適合する任意のファイルシステムを指すように広く解釈すべきである。
【００２０】
ストレージオペレーティングシステムは、ネットワークドライバ（例えばイーサネット（Ｒ）ドライバ）のメディアアクセス層３０２を含む一連のソフトウェア層から構成される。ストレージオペレーティングシステム３００は、インターネットプロトコル（ＩＰ）層３０４、並びに、ＩＰ層がサポートする搬送手段であるトランスポート・コントロール・プロトコル（ＴＣＰ）層３０６及びユーザ・データグラム・プロトコル（ＵＤＰ）層３０８を更に含む。
【００２１】
ファイルシステムプロトコル層は、複数プロトコルのデータアクセスを可能にするため、ネットワークファイルシステム（ＮＦＳ）プロトコル３１２、共用インターネットファイルシステム（ＣＩＦＳ）プロトコル３１４、及び、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）３１６をサポートする。さらに、ストレージオペレーティングシステム３００は、ＲＡＩＤプロトコル等のディスクストレージプロトコルを実施するディスクストレージ層３２２、及び、スモールコンピュータシステムインタフェース（ＳＣＳＩ）プロトコル等のディスクアクセスプロトコルを実施するディスクドライバ層３２４を含む。
【００２２】
これらのディスクソフトウェア層とネットワークプロトコル層及びファイルシステムプロトコル層とを橋渡しするのが、ストレージオペレーティング３００のファイルシステム層３２６である。一般にファイルシステム層３２６は、例えば４キロバイト（ＫＢ）のデータブロックを用いたブロックベースのディスク上のフォーマット表現を有するファイルシステムを実施し、ｉｎｏｄｅを用いてファイルを表現する。このファイルシステムは、トランザクション要求に応じて、要求されたデータが「コア」すなわちファイラーのメモリ２０４に存在しない場合、そのデータをディスク１０６からロード（取得）するための処理を行なう。情報がメモリに存在しない場合、ファイルシステム層３２６は、ｉｎｏｄｅ番号を用いてｉｎｏｄｅファイル内に索引を付け、適当なエントリにアクセスして論理ボリュームブロック番号を取得する。次いでファイルシステム層３２６は、その論理ボリュームブロック番号をディスクストレージ（ＲＡＩＤ）層３２２に渡し、ＲＡＩＤ層３２２がその論理番号をディスクブロック番号にマッピングし、そのディスクブロック番号をディスクドライバ層３２４の適当なドライバ（例えば、ファイバチャネルディスク相互接続上で実施されるＳＣＳＩのカプセル化）に送信する。次いでディスクドライバは、ディスク１０６のそのディスクブロック番号にアクセスして要求されたデータをメモリ２０４にロードし、ファイラー２００で処理する。要求が完了すると、ファイラー（及びストレージオペレーティングシステム）は、ネットワーククラウド１０２を介してクライアント１０４に返答を、例えばＣＩＦＳ規格に規定されている従来の受領応答パケットを返す。
【００２３】
ファイルサーバによって受信されたクライアント要求についてデータストレージアクセスを実施しなければならない上記ストレージオペレーティングシステム層を通るストレージアクセス要求データパス３３０は、ハードウェアでもソフトウェアでも実施することができ、あるいはハードウェアとソフトウェアの組み合わせで実施することもできることに注意して欲しい。従って、本発明の代替実施形態では、ストレージアクセス要求データパス３３０は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）や特定用途向け集積回路（ＡＳＩＣ）の中に実現された論理回路として実施される場合がある。この種のハードウェア実施形態は、クライアントから発行されたファイルシステム要求に対してファイルサーバ２００が提供するファイルサービスの性能を向上させることができる。
【００２４】
ファイルシステム層の内部には、ファイルシステム本来のスナップショット機能を実施する一連のスナップショットプロセス３２８が存在する。ＷＡＦＬファイルシステムに固有のＳｎａｐｓｈｏｔ（登録商標）機能については、ネットワークアプライアンス社が発行する「Ｆｉｌｅ　Ｓｙｓｔｅｍ　Ｄｅｓｉｇｎ　ｆｏｒ　ａｎ　ＮＦＳ　Ｆｉｌｅ　Ｓｅｒｖｅｒ　Ａｐｐｌｉａｎｃｅ」と題したＤａｖｉｄ　Ｈｉｔｚ他によるＴＲ３００２、及び「ＭＥＴＨＯＤ　ＦＯＲ　ＭＡＩＮＴＡＩＮＩＮＧ　ＣＯＮＳＩＳＴＥＮＴ　ＳＴＡＴＥＳ　ＯＦ　Ａ　ＦＩＬＥ　ＳＹＳＴＥＭ　ＡＮＤ　ＦＯＲ　ＣＲＥＡＴＩＮＧ　ＵＳＥＲ−ＡＣＣＥＳＳＩＢＬＥ　ＲＥＡＤ−ＯＮＬＹ　ＣＯＰＩＥＳ　ＯＦ　Ａ　ＦＩＬＥ　ＳＹＳＴＥＭ」と題したＤａｖｉｄ　Ｈｉｔｚ他による米国特許第５８１９２９２号明細書に詳しい説明があり、これらはここで参照することにより本明細書に取り込まれる。「Ｓｎａｐｓｈｏｔ」はネットワークアプライアンス社の商標である。この用語は、この特許でＰｅｒｓｉｓｔｅｎｔ　Ｃｏｎｓｉｓｔｅｎｃｙ　Ｐｏｉｎｔ（ＣＰ）イメージを指すために用いられている。Ｐｅｒｓｉｓｔｅｎｔ　Ｃｏｎｓｉｓｔｅｎｃｙ　Ｐｏｉｎｔ　Ｉｍａｇｅ（ＰＣＰＩ）とは、ストレージシステムをある時点で表現したものであって、特に記憶装置（例えばディスク）や持続性メモリに記憶されたアクティブファイルシステムをある時点で表現したものであり、そのＰＣＰＩを他の時点で取得した他のＰＣＰＩから区別するための一意の識別子または名称を有する。またＰＣＰＩは、イメージを取得したある時点でのアクティブファイルシステムに関する他の情報（メタデータ）をさらに含む場合もある。「ＰＣＰＩ」及び「ｓｎａｐｓｈｏｔ」という用語は、ネットワークアプライアンス社の商標権から逸脱することなく、交換可能に使用することができる。
【００２５】
背景として、スナップショットは、所定の時点で作成されたファイルシステムを復元することができる。スナップショットは通常、何らかの規則的なスケジュールで作成される。スナップショットは、アクティブファイルシステムと共にディスクに記憶され、ストレージオペレーティングシステムから要求があったときに、ファイラーメモリのバッファキャッシュに呼び出される。例示的ファイルシステムのｉｎｏｄｅ構造４００を図４に示す。ルートｉｎｏｄｅ４０５は、所与のファイルシステムに関するｉｎｏｄｅファイルを表す情報を保持している。この例示的ファイルシステムの場合、ｉｎｏｄｅ構造４０５は、ｉｎｏｄｅファイル間接ブロック４１０へのポインタを保持している。ｉｎｏｄｅファイル間接ブロック４１０は、ｉｎｏｄｅファイル及びデータブロック４１５への一連のポインタを保持している。ｉｎｏｄｅファイルデータブロック４１５は、ファイルデータブロック４２０Ａ、４２０Ｂ及び４２０Ｃへのポインタを有する。この例示的実施形態の場合、ファイルデータブロック４２０（Ａ〜Ｃ）は、４キロバイト（ＫＢ）のデータを記憶する能力がある。
【００２６】
ファイルシステムが所与のファイルシステムのスナップショットを作成する場合、図５に示すようなスナップショットｉｎｏｄｅが作成される。スナップショットｉｎｏｄｅ５０５は、実質的にファイルシステム４００のルートｉｎｏｄｅ４０５の複製である。従って、例示のファイルシステム構造５００は、図４と同じｉｎｏｄｅ間接ブロック４１０、ｉｎｏｄｅファイルデータブロック４１５およびファイルデータブロック４２０Ａ〜Ｃを有する。ユーザがファイルデータブロックを変更した場合、ファイルシステム層は、この新たなデータブロックをディスクに書き込み、この新たに作成したブロックを指すようにアクティブファイルシステムを変更する。
【００２７】
図６は、ファイルデータブロックが変更された後の例示的ｉｎｏｄｅファイルシステム構造６００を示す図である。この例の場合、ファイルデータブロック４２０Ｃがファイルデータブロック４２０Ｃ’に変更された。ファイルデータブロック４２０Ｃがファイルデータブロック４２０Ｃ’に変更された場合、変更されたファイルデータブロックの内容は、例示のＷＡＦＬファイルシステムの機能によって、ディスク上の新たな位置に書き込まれる。新たな位置に書き込まれるので、変更されたファイルデータブロック４２０Ｃを指すｉｎｏｄｅファイルデータブロック６１５は、ファイルデータブロック４２０Ｃの新たな位置を反映するように変更しければならない。同様にｉｎｏｄｅファイル間接ブロック６１０も新たに変更されたｉｎｏｄｅファイル及びデータブロックを指すように書き替えなければならない。従って、ファイルデータブロックが変更された後、スナップショットｉｎｏｄｅ５０５は、元のｉｎｏｄｅファイルシステム間接ブロック４１０を指すポインタを含み、従ってｉｎｏｄｅファイルデータブロック４１５へのリンクを含む。このｉｎｏｄｅファイルデータブロック４１５は、元のファイルデータブロック４２０Ａ、４２０Ｂ及び４２０Ｃへのポインタを保持している。しかしながら、新たに書き込まれたこのｉｎｏｄｅファイルデータブロック６１５は、変更の施されていないファイルデータブロック４２０Ａ及び４２０Ｂへのポインタを有する。また、このｉｎｏｄｅファイルデータブロック６１５は、アクティブファイルシステムの新たな構成を表す変更後のファイルデータブロック４２０Ｃ’へのポインタも保持する。新たなファイルシステムルートｉｎｏｄｅ６０５は、新たな構造６００を表すように確立される。スナップショットを作成した何らかのブロックに記憶されたメタデータ（図示せず）によって、それらのブロックは、すべてのスナップショットから開放されるまで、再利用や上書きが防止されるということに注意して欲しい。従って、アクティブファイルシステムのルートｉｎｏｄｅ６０５が新たなブロック６１０、６１５及び４２０Ｃ’を指していても、古いブロック５０５、４１０、４１５及び４２０Ｃは、そのスナップショットが完全に開放されるまで維持される。
【００２８】
スナップショットの作成が完了してファイルデータブロックが変更された後、ファイルシステム層は、スナップショットｉｎｏｄｅにアクセスすることにより、ファイルシステムｉｎｏｄｅ構造をスナップショットの時点で存在していたように再現すなわち「復元」することができる。ファイルシステム層は、スナップショットｉｎｏｄｅ５０５に保持されるポインタをたどり、ｉｎｏｄｅファイル間接ブロック４１０及びｉｎｏｄｅファイルデータブロック４１５を通して未変更のファイルデータブロック４２０Ａ〜Ｃまでポインタをたどることによって、ファイルシステムをスナップショット作成時点の状態に復元することができる。
【００２９】
ストレージオペレーティングシステムの代替実施形態では、スナップショット管理層３３２によって、ユーザは、複数のスナップショットについて、実施すべき処理のスケジュールを定義することができる。ユーザは、コマンドラインインタフェース（ＣＬＩ）またはグラフィカルユーザインタフェース（ＧＵＩ）を介して、スナップショットプロセス３２８が作成するスナップショットについて実施すべき特定の処理及びパラメタを入力することにより、スケジュールを定義することができる。通常、以下で説明するバックアップサーバは、スナップショット管理層を含むストレージオペレーティングシステムを実行している。しかしながら、ファイルサーバ即ちコンピュータの代替実施形態では、スナップショット管理層の機能を含むストレージオペレーティングシステムを実行する場合もあると明らかに考えられる。
【００３０】
Ｄ．スナップショットの内容
ファイルシステムのスナップショットはいかなる時点でも作成することができるので、ファイルシステムが更新されているときにそのファイルシステムのスナップショットが作成されると、問題が生じる可能性がある。ファイルシステムが経験する状態の例示的時刻表７００を図７に示す。時間７０５にある間、ファイルシステムは先ず安定状態にある。この「安定」とは、ファイルシステムを構成するディスクやｉｎｏｄｅ構造に対して、物理的に何も更新が書き込まれないことを意味している。次いでファイルシステムは、安定ファイルシステムの別のインスタンス７１０に達する前に、移動フェイズ７１５に入る。ファイルシステムは、移動フェイズ７１５にある間、データが書き込まれたり、変更されたりし、例えばファイルが消去される。このように、ファイルシステムが移動されている間は、特定のｉｎｏｄｅ及びデータブロックが変更される。上記のように、ファイルシステムのスナップショットはいかなる時点でも作成することができる。従って例えば、スナップショットは、時刻７２０（安定期間）で作成される場合もあれば、時刻７２５（移動期間）で作成される場合もある。時刻７２０で作成されたスナップショットは、更新を必要としない安定したファイルシステムを取り込む。
【００３１】
任意の時刻で多数のスナップショットが作成されるので、安定したファイルシステムを取り込むものもあれば、移動中のファイルシステムを取り込むものもある。復元のためには、特定のスナップショット内に保持されたそのファイルシステムの状態を知ることが望ましい。データベースを作成して、ファイルシステムの各スナップショットとそのスナップショットに関する状態（安定しているか移動中であるか）を追跡するように維持することもできる。しかしながら、こうしたデータベースは、計算オーバヘッドをさらに必要とする場合がある。
【００３２】
あるスナップショットが安定したファイルシステムのスナップショットであるか移動中のファイルシステムのスナップショットであるかをユーザや管理者が判定できるようにするため、ファイルシステムの状態がアクティブファイルシステムに記憶される。「アクティブファイルシステム」とは、現在の入出力処理が向けられた対象となる特定コンピュータに関連するファイルシステムを意味するのが通常である。メタデータ、すなわちファイルシステムの状態に関するデータは、アクティブファイルシステムの様々な場所に記憶することができる。一実施形態として、メタデータを記憶するためのファイルは、アクティブファイルシステムに作成することができる。アクティブファイルシステムに記憶されるメタデータの内容を図８に示す。アクティブファイルシステム８００の中には、一連のメタデータ８０５が記憶される。メタデータ８０５には、状態に関するエントリ８１０、ソースファイラー８１５、タイムスタンプ８１０等、様々なエントリが含まれ、代替実施形態ではさらなるエントリ８２５が含まれる場合もある。状態エントリ８１０は、２値フラグとして実施することができる。例えば、状態フラグが「１」の場合はファイルシステムが安定であるものとする。あるいは、状態フラグが「０」の場合はファイルシステムが移動状態にあるものとする。このように、ファイルシステムは、状態エントリを変更することで、ファイルシステム内のデータの変更を開始する前にそのファイルシステムが移動中であることを示すことができる。従って、データ更新中に作成されたスナップショットは、いずれもそのファイルシステムが移動状態であることを示すメタデータを含むことになる。データの更新が完了すると、ファイルシステムは、そのファイルシステムが安定であることを示すように状態エントリ８１０を変更する。一実施形態において、このメタデータは、Ｑｔｒｅｅメタファイルに記憶される場合がある。Ｑｔｒｅｅメタファイルについては、「ＳＹＳＴＥＭ　ＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＲＥＤＩＲＥＣＴＩＮＧ　ＡＣＣＥＳＳＴＯ　Ａ　ＲＥＭＯＴＥ　ＭＩＲＲＯＲＥＤ　ＳＮＡＰＳＨＯＴ　ＡＮＤ　ＳＴＯＲＡＧＥ　ＯＦ　ＳＮＡＰＳＨＯＴ　ＭＥＴＡＤＡＴＡ　ＩＮ　ＲＥＭＯＴＥ　ＦＩＬＥ」と題したＳｔｅｐｈａｎ　Ｌ．Ｍａｎｌｅｙ他による米国特許出願（代理人文書番号１１２０５６−００５３）号明細書に詳しい説明がある。
【００３３】
ソースファイラエントリ８１５は、特定ファイルシステムを生成するファイルサーバを識別するために用いられる。このようなフラグは、例えば異なるファイルサーバから作成された複数のスナップショットが１つのボリュームに記憶される場合に有用である。このようなスナップショットの混在については、「ＳＹＳＴＥＭＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＣＯＡＬＥＳＩＮＧ　Ａ　ＰＬＵＲＡＬＩＴＹ　ＯＦ　ＳＮＡＰＳＨＯＴＳ」と題したＨｕｇｏ　Ｐａｔｔｅｒｓｏｎによる米国特許出願（代理人文書番号１１２０５６−００６８）号明細書に説明があり、この出願はここで参照することにより本明細書に取り込まれる。
【００３４】
ファイルサーバは、メタデータ８０５のタイムスタンプエントリ８２０を用いて、あるスナップショットが所望のバージョンのファイルシステムを含んでいるか否かを判定することができる。例えば、ユーザが特定の時間枠の中からファイルを復元することを望む場合、ユーザ又は管理者は、スナップショットが作成された時刻を知る必要がある。図９は、あるスナップショットが所望の処理（例えば、特定時点からのファイルの復元など）に関する適当なスナップショットであるか否かを判定する際に、ユーザが実施する詳細な手順を示すフロー図である。ステップ９０５で、ユーザは利用可能なスナップショットのリストの中から最初のスナップショットを選択する。このスナップショットのリストはファイルシステムに保持されている。次にステップ９１０で、その選択したスナップショットのメタデータファイルを調べる。メタデータに保持されているデータを分類または分析することにより、そのスナップショットが適当なスナップショットであるか否かを判定することができる（ステップ９１５）。そのスナップショットが適当なスナップショットではなかった場合、利用可能なスナップショットのリストの中から次のスナップショットを選択する（ステップ９２５）。リストの中から次のスナップショットを選択した後、処理はステップ９１０に進み、選択したスナップショットに保持されているメタデータを調べる。
【００３５】
このように、スナップショットに関するメタデータをアクティブファイルシステムに記憶することによって、そのファイルシステムのスナップショットにはメタデータが必然的に常に含まれることになる。その結果、スナップショットは、その中に含まれるメタデータによって自分自身を表現することができるようになる。これによって、複数のスナップショットの管理が容易になる。さらに、他のプロセスやプログラムが、スナップショットに記憶されたメタデータを用いて、特定スナップショットに関する管理判断を行なうことも可能になる。
【００３６】
Ｅ．スナップショット管理
本発明の一実施形態では、一連のバックアップ、すなわち、一連のバックアップクライアントのスナップショットを管理するため、個別のバックアップサーバが用いられる。こうしたバックアップサーバは、例えば、スナップショット管理層３２２（図３）を有するストレージオペレーティングシステムを実行するファイルサーバとして実施することができる。同様に、バックアップクライアントのいくらかまたは全部も、上記説明に従って実施することができる。
【００３７】
バックアップサーバのバックアップクライアントがそのバックアップクライアントのファイルシステムの様々なバックアップを作成する際、それらのバックアップは、そのバックアップサーバに関連するファイルシステムに復元される。そのため、バックアップサーバは、何らかの所与の時刻において、そのバックアップサーバに関連するバックアップクライアントのファイルシステム全体を格納する。「バックアップクライアント」とは、バックアップサーバの機能を利用してスナップショットを記憶及び管理する任意の装置またはコンピュータを意味している。バックアップクライアントのバックアップデータは、一連の差分バックアップと共にベースラインバックアップとして記憶されるのではない。そうではなく、ファイルシステム全体がバックアップサーバ上に複製される。
【００３８】
スナップショット管理ソフトウェア３３２は、作成された一連のバックアップを管理するために用いられる。こうした管理の一例は、特定のスナップショットを時間の経過とともに消去することである。通常は、特定時間の経過後にバックアップサーバがスナップショットを消去することが望ましい。作成したすべてのスナップショットを記憶しておくことは不可能であり、そのようにすれば記憶空間が際限なく増大してしまう。そのため、バックアップクライアントは、所定の時間間隔で、バックアップすなわちスナップショットを作成することができる。次いでこれらのスナップショットが所定の時間間隔でバックアップサーバに転送される。その後バックアップクライアントは、バックアップクライアント上のディスク空間を空けるために、それらの様々なスナップショットを実質的に自由に消去することができる。しかしながら、バックアップサーバは、一連のスナップショットをユーザ定義のスケジュールに従って管理する。
【００３９】
バックアップサーバを利用することの特徴は、システム管理者がテープインフラストラクチャによって制限されないことである。バックアップサーバは、スモールコンピュータシステムインタフェース（ＳＣＳＩ）バスを用いてテープドライブを取り付けることが通常可能な距離よりもはるか遠く（例えば、ネットワークによってサービスが提供される距離）に設置することができる。バックアップサーバを利用することのもう１つの利点は、バックアップクライアントが既知のダンプ・リストアソフトウェア及び／又は手順を利用できることである。バックアップサーバと共にこうしたダンプ・リストアバックアップ手順を用いることによって、スナップショット作成機能を本来もたないファイルシステムを使用するコンピュータによって管理されるファイルシステムのスナップショットを、有効に作成することが可能になる。
【００４０】
このようなバックアップネットワーク構成の一例を図１０に示す。ネットワーク環境１０００は、バックアップクライアントＡ１００５、バックアップクライアントＢ１０１０、及びバックアップサーバ１０１５を含む。バックアップサーバ１０１５にはスイッチングネットワーク１０２０が接続される。複数のディスクすなわち一連のディスク１０３０がこのスイッチングネットワークに接続される。バックアップサーバはこれらのディスクを用いて自分のファイルシステムを記憶する。バックアップクライアントＡ１００５には、一連のディスク１０２５がローカル接続される。バックアップクライアントＡ１００５では、サーバＢへのデータパス１０３５を介した従来のバックアップ処理と同様に、ダンプストリームを生成することが可能な従来のバックアップソフトウェア（Ｄｕｍｐ　Ａｐｐ）１００７が動作している。データパス１０３５には、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、又は他の適当なネットワークアーキテクチャなど、任意の形態のデータパスを用いることができる。バックアップクライアントＢ１０１０は、バックアップクライアントＡ１００５から生成されたダンプストリームを受信し、従来のリストアソフトウェア（Ｒｅｓｔｏｒｅ　Ａｐｐ）１０１２を用いて、データパス１０４０を介した復元ストリームによりバックアップサーバに対する復元処理を実施する。復元ストリームには、バックアップサーバのファイルシステムに対する一連の書き込み処理が含まれる。復元ストリームは、ＴＣＰ／ＩＰを含む様々なネットワークプロトコルにカプセル化することができる。
【００４１】
データパス１０４０は、データパス１０３５と同様に、任意の可能なネットワークアーキテクチャでよい。バックアップクライアントＢ１０１０は復元ストリームを生成し、この復元ストリームがバックアップサーバに関連するボリューム上にファイルシステムを再現する。次いでバックアップサーバ１０１５は、そのボリューム上に記憶されたデータの一連のスナップショットを生成する。バックアップサーバのディスク１０３０上に保持されるファイルシステムはバックアップクライアントＡのディスク１０２５上に記憶されているファイルシステムを復元したものであるから、バックアップサーバは、スナップショットを生成することにより、ディスク１０２５上に保持されたファイルシステムのスナップショットを有効に生成している。
【００４２】
このようなネットワーク環境において実施される例示的手順を図１１に示す。ステップ１１０５で、ファイルシステムのバックアップを取るべきファイルサーバは、ベースラインダンプを実施する（ステップ１１０５）。このベースラインダンプは、任意の可能なバックアップ及び復元又は複製ソフトウェア及び／又はハードウェアを用いて生成することができる。次にステップ１１１０で、パイプされたベースライン復元をバックアップサーバ上に生成する。このパイプされたベースライン復元は、前のステップで生成されたダンプデータストリームを用いて生成される。パイプされたベースライン復元の生成が完了した後、バックアップサーバは、生成されたファイルシステムのスナップショットを作成する（ステップ１１１５）。次に、バックアップサーバは所定の時間だけ待機する（ステップ１１２０）。次いでステップ１１２５で、ファイルシステムのバックアップが取られてるファイルサーバまたはコンピュータは、バックアップサーバ上の差分復元にパイプされた差分ダンプを実施する。バックアップサーバ上にこの差分復元が生成された後、ステップ１１３０で、バックアップサーバは新たなスナップショットを作成する。次いで１１３５で、バックアップサーバは、エンドユーザスケジュールに従って一連のスナップショットを管理する。このエンドユーザスケジュールには、様々なユーザ定義オプションを含めることができる。例えば、ユーザは、過去２４時間以内に作成されたスナップショットはすべて記憶するが、前の週については一日当たり１つしかスナップショットをとらないことを望む場合がある。
【００４３】
スナップショット管理ソフトウェア３３２（図３）は、生成された一連のスナップショットに対して、ユーザ定義の管理スケジュールに従って様々な処理を実施する。例示的な処理としては、上記のような指定日より古く生成されたスナップショットの消去、移動中状態のファイルシステムのスナップショットの削除、または、何らかのユーザ定義の方法によるスナップショットの削除などが含まれる。例えば、スナップショット管理ソフトウェアは、毎日最後に生成されたスナップショットだけを保持するように構成される場合がある。従って、この例の場合、スナップショットマネージャは、複数のスナップショットについて、それらが同日に生成されたものであることを証明するタイムスタンプを共有しているか否かを判定する場合がある。スナップショット管理ソフトウェアは、複数のスナップショットが同日に生成された場合、その日に作成された最後のスナップショット以外のスナップショットをすべて消去する場合がある。
【００４４】
Ｆ．オンデマンド復元
バックアップサーバに記憶されるバックアップファイルシステムは完全なファイルシステムであり、バックアップファイルシステムがテープ装置のようなシリアルデバイスではなくディスク上に記憶されるので、ランダムアクセスが可能になっている。復元能力を向上させるため、個々のファイル及びディレクトリは、ファイルシステム全体が復元されるまで待つことなく、オンデマンドで復元することができる。
【００４５】
図１２は、例示的ディレクトリ構造１２００を示すブロック図である。ディレクトリ構造１２００は、２つのサブディレクトリｆｏｏ１２１０及びｂａｒ１２１５を有するルートディレクトリ１２０５を含む。サブディレクトリ１２２０は、ファイルＡ及びＢ１２２５及び１２３０を含む。同様に、ｂａｒディレクトリ１２１５は、ファイルＣ１２３５を含む。
【００４６】
バックアップサーバのバックアップクライアントが、ファイルシステム、例えば図１２の例示的ファイルシステムの復元を必要とする場合、復元能力を向上させるため、様々なファイル及びディレクトリをオンデマンドで復元することができる。例えば、図１２のファイルシステムがバックアップクライアント上で壊れたと仮定する。バックアップサーバがそのファイルシステムのスナップショットを保有していれば、そのスナップショットから復元を行なうことができる。必要なファイルまたはディレクトリだけをオンデマンドで復元することにより、時間及び処理のオーバヘッドが節減できる。例えば、バックアップクライアントがファイル１２３５を必要とする場合を仮定する。
【００４７】
従来のスナップショット復元技術の場合、ファイルシステム全体１２００が復元される。例えば、ファイルシステム１２００が２テラバイト（ＴＢ）のデータを有している場合、２ＴＢのデータ全体をバックアップサーバのスナップショットからバックアップクライアントのアクティブファイルシステムにコピーする必要がある。このようなデータ転送には、相当な時間がかかる。大量のデータを転送することの必要性を低減するため、特定のファイルを復元するのに必要なファイルシステム構造の一部だけを復元する。従って、バックアップクライアントがファイル１２３５を必要とする場合、ｂａｒディレクトリ１２１５及びファイル１２３５を復元するだけで済む。このような復元を図１３に示す。復元されたファイルシステム構造１３００には、ルートディレクトリ１２０５、ｂａｒディレクトリ１２１５、及び、必要なファイル１２３５が含まれる。従って、ｆｏｏディレクトリ１２１０及びそれに関連するサブディレクトリ及びファイルは、バックアップクライアントがそれらを必要としない限り、復元されない。代替実施形態として、オンデマンドの復元を行ないつつ、バックグラウンドプロセスを利用して完全な復元を実施することも可能である。
【００４８】
復元されたファイルシステムの各ｉｎｏｄｅは、そのｉｎｏｄｅが部分的に復元されたｉｎｏｄｅであることをストレージオペレーティングシステムのファイルシステム層に警告するフラグを有する。従って、ファイルシステム層は、ファイルアクセス要求をこれらのフラグに応じてバックアップサーバに導き、必要なファイルをオンデマンドで復元し続けることができる。
【００４９】
例示的ｉｎｏｄｅ１４００を図３に示す。例示的ｉｎｏｄｅ１４００は、メタデータ部１４０５及びデータ部１４３５を含む。各ｉｎｏｄｅ１４００のメタデータ部に記憶される情報は、ファイルを表すものであり、そのファイルのタイプ（通常またはディレクトリ）１４０１０、ファイルのサイズ１４１５、そのファイルのタイムスタンプ（例えばアクセス及び／又は変更）１４２０、及び、そのファイルの所有者すなわちユーザＩＤ（ＵＩＤ１４２５）を含む。メタデータ部１４０５も、そのｉｎｏｄｅがスナップショットから部分的に復元されたものであるか否かを識別するフラグを含む。部分復元フラグ１４３０は、そのｉｎｏｄｅの中身がスナップショットから完全には復元されていない場合もあることをファイルシステムに示すとともに、適切なデータを取得するためにはファイルシステムがバックアップサーバのスナップショットにアクセスする必要があることを示すものである。しかしながら、ｉｎｏｄｅのデータ部１４３５の中身は、タイプフィールド１４１０内に定義されたファイル（ｉｎｏｄｅ）のタイプに応じて異なる解釈をする場合もある。例えば、ディレクトリｉｎｏｄｅのデータ部１４３５がファイルシステムによって制御されるメタデータを保持する一方、通常ｉｎｏｄｅのデータ部はユーザ定義のデータを保持する場合がある。後者の場合、データ部１４３５には、そのファイルに関するデータを表すものが含まれる。
【００５０】
このように、それらのファイル及びディレクトリはストレージオペレーティングシステムで必要になった際に復元するだけでよいので、実質的な処理時間が節約される。この時間節約は、ファイルシステムが相当量のデータを保持していても、わずか少量のファイルしか決まって必要とならない場合に、特に顕著になる。このような場合、決まってアクセスされるファイルは必要なときに復元する一方、あまり使用されない大きなファイルはバックグラウンドプロセスを用いて復元することができる。
【００５１】
従って、アクティブファイルシステム内にメタデータを保持することにより、そのファイルシステムに関するデータを記憶することができる。ファイルシステムの本来のスナップショット機能を利用することにより、メタデータファイルがファイルシステムの何らかのスナップショットに組み込まれる。つまり、その結果ファイルシステムは、事実上自己表現可能なスナップショットになる。また、このメタデータファイルは、バックアップサーバ上で動作するスナップショット管理プログラムで利用することもできる。バックアップサーバは、スナップショット機能を有しないファイルシステムを使用するコンピュータから従来の復元データストリームを受け取ることができる。バックアップサーバのバックアップクライアントがバックアップクライアントファイルシステムをバックアップサーバ上に復元し終わると、バックアップサーバは、その復元されたファイルシステムのスナップショットを作成することができる。これによって、本来スナップショットを作成する能力をもたないファイルシステムのスナップショットの作成が可能になる。さらに、本システム及び方法によると、遠隔の宛先バックアップファイルサーバを用いて、信頼性の高い、高速で低オーバヘッドなテープレスでのバックアップが可能になる。
【００５２】
以上が本発明の例示的実施形態の詳細な説明である。本発明の思想及び範囲から外れることなく、様々な変更及び追加を行なうことが可能である。本明細書で説明した機能、手順、又はプロセスは、コンピュータ上で実行されるプログラム命令を含むコンピュータ読取可能な媒体からなる、ハードウェア、ファームウェア、またはソフトウェアで実施することができ、あるいは、ハードウェア、ファームウェア及び／又はソフトウェアの組み合わせで実施することもできる。従って、この説明は、例示だけを意図したものであり、本発明の範囲を制限する意図はない。
【図面の簡単な説明】
【図１】ファイルサーバ及びテープドライブを有する例示的ネットワーク環境を示す略ブロック図である。
【図２】本発明の一実施形態による例示的ファイルサーバを示す略ブロック図である。
【図３】本発明の一実施形態に従って使用する例示的ストレージファイルシステムを示す略ブロック図である。
【図４】例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図５】スナップショットｉｎｏｄｅを含む図４の例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図６】データブロックが再書き込みされた後の図４の例示的ファイルシステムｉｎｏｄｅ構造を示す略ブロック図である。
【図７】安定したファイルシステム及び移動中のファイルシステムの時刻表を示す図である。
【図８】本発明の一実施形態によるスナップショットメタデータを示す略ブロック図である。
【図９】記憶されたメタデータを用いて適切なスナップショットを選択する際に実施される手順の詳細を示すフロー図である。
【図１０】本発明の一実施形態によるファイルサーバを含む例示的ネットワーク環境を示す略ブロック図である。
【図１１】本発明の一実施形態による図１０の例示的環境におけるファイルサーバが利用する手順の詳細を示すフロー図である。
【図１２】例示的ディレクトリ構造を示す略ブロック図である。
【図１３】本発明の一実施形態により部分的に復元されたディレクトリ構造を示す略ブロック図である。
【図１４】例示的ｉｎｏｄｅを示す略ブロック図である。
【図１】
2004038929.tif 000003
【図２】
2004038929.tif 000004
【図３】
2004038929.tif 000005
【図４】
2004038929.tif 000006
【図５】
2004038929.tif 000007
【図６】
2004038929.tif 000008
【図７】
2004038929.tif 000009
【図８】
2004038929.tif 000010
【図９】
2004038929.tif 000011
【図１０】
2004038929.tif 000012
【図１１】
2004038929.tif 000013
【図１２】
2004038929.tif 000014
【図１３】
2004038929.tif 000015
【図１４】
2004038929.tif 000016
【外国語明細書】
2004038929.tif 000017
2004038929.tif 000018
2004038929.tif 000019
2004038929.tif 000020
2004038929.tif 000021
2004038929.tif 000022
2004038929.tif 000023
2004038929.tif 000024
2004038929.tif 000025
2004038929.tif 000026
2004038929.tif 000027
2004038929.tif 000028
2004038929.tif 000029
2004038929.tif 000030
2004038929.tif 000031
2004038929.tif 000032
2004038929.tif 000033
2004038929.tif 000034
2004038929.tif 000035
2004038929.tif 000036
2004038929.tif 000037
2004038929.tif 000038
2004038929.tif 000039
2004038929.tif 000040
2004038929.tif 000041
2004038929.tif 000042
2004038929.tif 000043
2004038929.tif 000044
2004038929.tif 000045
2004038929.tif 000046
2004038929.tif 000047
2004038929.tif 000048
2004038929.tif 000049
2004038929.tif 000050
2004038929.tif 000051
2004038929.tif 000052
2004038929.tif 000053
2004038929.tif 000054