(57)【要約】【課題】ファイル・システム復元操作中に、制限付きファイル・アクセスおよび完全なファイル・アクセスの両方を可能にすることである。【解決手段】ファイル・システム復元が、当該復元処理全体を通じての個々のファイル復元ステータスのインジケータの使用を介して、より柔軟になされる。そのようなインジケータは、たとえば、ファイルの数がほぼ数億個の範囲におよぶかもしれないような大規模ファイル・システムの復元に特に有用である。大規模システムのファイル・システム復元は比較的長時間を要するので、復元処理が実行されつつある時であっても、本発明はさまざまな程度の個々のファイル・アクセスを提供する。ファイル・システム復元時間の間は、ファイル・アクセスは、完全なものとすることができるし、またはファイルの属性への限定的なものとすることができる。最も有利なことに、本発明は、ファイル・システム復元操作中であっても、動的に駆動される（オン・デマンドの）完全なファイル・アクセスを提供することができる。【選択図】図１
2005018757.tif 000002
【特許請求の範囲】
【請求項１】
ファイル・システムにアクセスする方法であって、
限定された属性を持ち、データを持たないファイルであって、前記ファイルのために前記ファイルが未復元状態であるとの表示が提供される、ファイルのためのエントリーを作成するステップと、
前記ファイルについてファイル・システム操作を許可するステップであって、前記操作が、（１）いかなる上記のようなファイルについてもファイル名をリスト化するステップと、（２）いかなる上記のようなファイルをも除去するステップとからなるグループの中から選択される、ステップと
を有する方法。
【請求項２】
前記アクセスが、前記ファイル・システムについての復元操作中に行われる、請求項１に記載の方法。
【請求項３】
未復元状態表示を有する前記ファイルを復元するステップと、復元済みステータスを反映するために前記表示を変更するステップと、を更に含む、請求項１に記載の方法。
【請求項４】
前記復元中に、復元されるファイルごとに、前記ファイル復元に引き続いてファイル・ステータス・インジケータを未復元表示から復元済み表示に変更するステップ、を更に有する、ファイル・システムを復元する方法。
【請求項５】
ファイルへのアクセスを許可するステップであって、前記ファイルのために前記ファイルが復元済み状態であることを前記ステータス・インジケータが示す、ステップを更に含む、請求項４に記載の方法。
【請求項６】
ファイルへのアクセスを、前記ファイルが復元されるまで一時的に中断するステップであって、前記ファイルのために前記ファイルが未復元状態であることを前記状況インジケータが示す、ステップを更に含む、請求項４に記載の方法。
【請求項７】
ファイル・システムにアクセスする方法であって、
属性もデータも持たないファイルのためのエントリーを作成するステップであって、前記ファイルのために前記ファイルが未復元状態であることの表示が提供される、ステップと、
前記ファイルについてのファイル名をリスト化するステップと
を有する方法。
【請求項８】
ファイル・システムにアクセスする方法であって、
属性もデータも持たないファイルのためのエントリーを作成するステップであって、前記ファイルのために前記ファイルが未復元状態であることの表示が提供されるステップと、
前記ファイルに割り当てられたファイル名を除去するステップと
を有する方法。
【請求項９】
ファイル・システムにアクセスする方法であって、
前記ファイル・システムの復元中に、まだ復元されていないとの表示を有する前記システム、の中のファイルに向けられたアクセスに際して、前記ファイルを復元し、復元済みステータスを反映するように前記表示を変更する、ステップ
を有する方法。
【請求項１０】
前記ファイル・システムの前記復元中に前記ファイルにアクセスするステップ、を更に含む、請求項９に記載の方法。
【請求項１１】
ファイル・システムにアクセスする方法であって、前記ファイル・システムの復元中に、まだ復元されていないとの表示を有する前記システム、の中のファイルに向けられたアクセスに際して、前記ファイルを前記ファイル・システムから除去し、前記ファイルの復元を省略するステップ、を含む方法。
【請求項１２】
ファイル・システムにアクセスする方法であって、前記ファイル・システムの復元中に、まだ復元されていないとの表示を有する前記システム、の中のファイルに向けられたアクセスに際して、スケジュールされるファイル・システム復元の優先順位を調整して、その結果、前記アクセスされるファイルが、前記スケジュールされる順序内でより早期に復元されるようになる、ステップを有する方法。
【請求項１３】
ファイル・システムを復元する方法であって、
空のファイル・システムであって、その中で、ファイル属性とファイル・データのいずれも復元済みとして示されていないということを示すようにファイル・システムｉノードがマークされている、ファイル・システムを作成するステップと、
前記ファイル・システムについての名前空間を初期化するステップと、
前記ファイル・システムについてのルート・ディレクトリを復元するステップと、
前記ファイル・システム内の少なくとも１つのファイルを復元し、前記ファイルの属性およびデータが復元済みであるとの表示を提供するステップと
を有する方法。
【請求項１４】
前記ファイル復元の間に前記ファイルにアクセスするステップを更に有する、請求項１３に記載の方法。
【請求項１５】
前記ファイルのデータが復元されるまで、前記ファイル・システム内の前記ファイルへのアクセスを延期するステップを更に含む、請求項１４に記載の方法。
【請求項１６】
ファイル・システムを復元する方法であって、
空のファイル・システムであって、その中で、ファイル属性とファイル・データのいずれも復元済みとして示されていないということを示すようにファイル・システムｉノードがマークされている、ファイル・システムを作成するステップと、
前記ファイル・システムについての名前空間を初期化するステップと、
すべての前記ファイル・システムについてファイル・システム・ディレクトリ情報を復元するステップと、
前記ファイル・システム内の少なくとも１つのファイルを復元し、前記ファイルの属性およびデータが復元済みであることの表示を提供するステップと、
前記ファイル復元の間に前記ファイルにアクセスするステップと
を有する方法。
【請求項１７】
前記ファイル・システム・ディレクトリ情報の前記復元が再帰的に実行される、請求項１６に記載の方法。
【請求項１８】
ファイル・システムを復元する方法であって、
空のファイル・システムであって、その中で、ファイル属性とファイル・データのいずれも復元済みとして示されていないということを示すようにファイル・システムｉノードがマークされている、ファイル・システムを作成するステップと、
以前に作成され、関連するファイル名およびｉノード番号を含んだテーブル、を使用して前記ファイル・システムを復元するステップと
を有する方法。
【請求項１９】
前記テーブルが、異なるデータ処理ノードによってばらばらの部分で処理され、これによって前記復元が並列に実行される、請求項１８に記載の方法。
【請求項２０】
前記ファイル・システム復元を実行するために少なくとも１つの他のプロセスを作成するステップを更に含む、請求項１８に記載の方法。
【請求項２１】
ファイル・システムを復元する方法であって、
空のファイル・システムであって、その中で、ファイル属性とファイル・データのいずれも復元済みとして示されていないということを示すようにファイル・システムｉノードがマークされている、ファイル・システムを作成するステップと、
前記ファイル・システム内の少なくとも１つのファイルを、前記ファイルについての属性は復元されるが前記ファイルについてのデータは即座には復元されないという形で復元するステップと
を有する方法。
【請求項２２】
アプリケーション・プログラムが、前記ファイルのデータ内容ではなく前記ファイルの属性を確認するために前記ファイルにアクセスするステップ、を更に含む、請求項２１に記載の方法。
【請求項２３】
前記ファイルのデータが、前記ファイルの属性の復元の後に引き続いて復元される、請求項２１に記載の方法。
【請求項２４】
ファイル・システムを復元する方法であって、
空のファイル・システムであって、その中で、ファイル属性とファイル・データのいずれも復元済みとして示されないということを示すようにファイル・システムｉノードがマークされている、ファイル・システムを作成するステップと、
以前に作成され、関連するファイル名およびｉノード番号を含んだテーブルを使用して前記ファイル・システム内の少なくとも１つのファイルを復元するステップと
を含む方法。
【請求項２５】
ファイル復元が、前記ファイル・システム内の前記ファイルのすべてについて実行される、請求項２４に記載の方法。
【請求項２６】
ファイル復元が、前記ファイル・システム内の複数のファイルについて実行される、請求項２４に記載の方法。
【請求項２７】
前記ファイル復元が、前記以前に作成されたテーブルで指定される順序にて行われる、請求項２５に記載の方法。
【請求項２８】
前記ファイル復元が、別の媒体に所与の順序で保管されたファイルから行われ、前記復元が、前記別の媒体に存在する前記順序に基づいた順にて行われる、請求項２７に記載の方法。
【請求項２９】
前記媒体がテープである、請求項２８に記載の方法。
【請求項３０】
前記テーブルが、以前に実行されたファイル・システム・バックアップ操作にて生成されたものである、請求項２４に記載の方法。
【請求項３１】
ファイル・システム復元のための、プログラム手段を持った計算機可読媒体上に保管されたコンピュータ・プログラムであって、前記プログラム手段が、（１）属性もデータも持たないファイルであって、前記ファイルのために前記ファイルが未復元状態であるとの表示が提供される、ファイルのエントリーを作成するためのものであり、また、（２）前記ファイルに対するファイル・システム操作を許可するためのものであって、前記操作が、（ａ）前記ファイルについてのファイル名をリスト化するステップと、（ｂ）前記ファイルを除去するステップとからなるグループから選択されるものである、コンピュータ・プログラム。
【請求項３２】
ファイル・システム復元のための、プログラム手段を持った計算機可読媒体上に保管されたコンピュータ・プログラムであって、前記プログラム手段が、前記復元中に、復元されるファイルごとに、前記ファイルの復元に引き続き、ファイル状況インジケータを未復元表示から復元済み表示に変更するステップを実行するためのものである、コンピュータ・プログラム。
【請求項３３】
データ処理システムであって、
中央処理装置と、
前記中央処理装置による実行のためにデータおよびプログラムを保管するランダム・アクセス・メモリと、
不揮発性ストレージ・デバイスと、
ファイル・システム復元のためのプログラム手段であって、前記プログラム手段が計算機可読媒体上に保管され、前記プログラム手段が、（１）属性もデータも持たないファイルであって、前記ファイルのために前記ファイルが未復元状態であるとの表示が提供される、ファイルのエントリーを作成するための手段と、（２）前記ファイルに対するファイル・システム操作を許可する手段とを含み、前記操作が、（ａ）前記ファイルのファイル名をリスト化するステップと、（ｂ）前記ファイルを除去するステップとからなるグループから選択されるものである、プログラム手段と
を有するデータ処理システム。
【請求項３４】
データ処理システムであって、
中央処理装置と、
前記中央処理装置による実行のためにデータおよびプログラムを保管するランダム・アクセス・メモリと、
不揮発性ストレージ・デバイスと、
ファイル・システム復元のためのプログラム手段であって、計算機可読媒体上に保管され、前記復元中に、復元されるファイルごとに、前記ファイル復元に引き続き、ファイル・ステータス・インジケータを未復元表示から復元済み表示に変更するステップを実行する、プログラム手段と
を有するデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には、超大規模ファイル・システムの管理を対象とする。そのようなファイル・システムは、通常は、大規模データ処理システムと共に使用される。具体的には、本発明は、ストレージ・エリア・ネットワーク（ＳＡＮ）環境に存在する可能性があるデータ・ファイル・システムをすばやく復元する方法およびシステムを対象とする。そのような環境は、しばしば、分散データ処理システムと共に使用される。しかし、本発明はこれらの環境に限定はされない。
【背景技術】
【０００２】
ＳＡＮファイル・システムおよび低コスト・ストレージの出現によって、非常に多数のファイルを有する超大規模ファイル・システムの可能性が生み出された。実際に、数テラ・バイト（１テラ・バイト＝１０１２バイト＝１０００ギガ・バイト）の容量を有するファイル・システムが、現在存在し、より大きいファイル・システムが可能である。残念ながら、バックアップ・コピーからファイル・システムを完全に復元する時間はファイル・システムのサイズに比例する。２０メガ・バイト／秒のテープ速度を仮定し、テープ処理時間およびソフトウェア・オーバーヘッドを無視すると、１テラ・バイトのデータのテープからの復元は１０時間以上を必要とする。顧客は、特定の関心のあるファイルをまず手作業で復元し、ファイル・システムへのアクセスを可能にするか、またはすべてのデータが復元されるまでアクセスを遅らせるかを選択できる。第１のオプションは、システム管理者が、望まれるデータを正確に識別できることをまず必要とする。というのは、そうでなければ、未復元のデータにアクセスするアプリケーションに障害が発生するからである。第２のオプションは、すべてのファイルがテープから復元されるまでの仕事の復元の遅れを伴う。これらの代替案のどちらともまったく満足できるものでない。
【０００３】
本発明では、本願と同時に出願された関連特許出願（ＰＯＵ９２００３０００６ＵＳ１）明細書、表題「Parallel High Speed Backup for a Storage Area Network (SAN) FileSystem」にも見られるデータ構造が使用される。本発明では、本発明の譲受人であるInternational Business MachinesCorporationが販売する製品であり、そのｐＳｅｒｉｅｓ製品ラインをサポートするＧＰＦＳ（汎用並列ファイル・システム）に含まれる階層記憶管理機能の並列サポート態様に見られる技法も使用される。しかし、本発明では、ファイル・システムの通常の復元を依然として継続する一方で、オン・デマンドを基礎としてバックアップされたデータにアクセスする能力を提供する新しい特徴も追加される。本発明を用いると、アプリケーション（即ち、アプリケーション・プログラム）は、ファイル・システム復元処理が開始された直後であってもファイル・システムの使用を開始することができ、これによって、ファイル・システムおよび顧客データが使用不能になる時間が大幅に削減される。
【０００４】
本発明が使用される環境をより良く理解するために、下記の用語が、当技術分野で一般に明確に理解された概念を指すのに使用される。下に示す定義は、便宜のために、ならびにかかわる問題および提案される解決策のよりよい理解のために供給されるものであり、ファイル・システム技術の技量を有する者であれば理解するように、一般的に理解される意味からの変形を暗示することを意図したものではない。本発明は、ファイルおよびファイル・システムを取り巻く概念に密接にかかわるので、それ故、より関連する用語の少なくとも一部の短い記述を読者に与えることが有用である。より完全なリストは、本発明と同一の譲受人に譲渡された米国特許第６０３２２１６号明細書にある。この特許明細書は、参照文献として本明細書に記載されている。この特許から選択された用語の下記の用語集が提供されるが、それは、これらの用語が本発明のより良い諒解および理解を提供するという観点で最も関連するためである。
【０００５】
データ／ファイル・システム・データ：  これは、特定のアプリケーションとの関連でのみ意味がある任意のビット列である。
【０００６】
ファイル：  コンピュータ・アプリケーションによってアクセスできる名前付きビット列。ファイルは、長さ、修正時刻、および最終アクセス時刻などの標準属性を有する。
【０００７】
メタデータ：  これは、ファイルの構造とファイル・システムを含むディスクの使用とを記述するために、ファイル・システム・ソフトウェアによって作成される制御構造である。このタイプのファイル・システムに適用される特定のタイプのメタデータの特徴を下で特に示すが、これには、ディレクトリ、ｉノード、割振りマップ、およびログが含まれる。
【０００８】
ディレクトリ：  これは、ｉノードによって表される一組のデータに名前を関連付ける制御構造である。
【０００９】
ｉノード：  ファイルの属性と、ファイルを構成するデータを含むディスク（または他の記憶媒体）の区域への一連のポインタとを含むデータ構造。間接ブロックによってｉノードを補完することができ、即ちこれら間接ブロックは、たとえばファイルが大きい場合には、追加ポインタによって当該ｉノードを補完する。
【００１０】
割振りマップ：  これは、ディスクの特定の区域（またはｉノードなどの他の制御構造）が、使用中かまたは使用可能であるかどうかを示す制御構造である。これによって、ソフトウェアが、使用可能なブロックおよびｉノードを新しいファイルに効率的に割り当てられるようになる。この用語は、ファイル・システム操作の全般的な理解に有用であるが、本発明の動作に関しては周辺でのみ使用される。
【００１１】
ログ：  障害状況での消失に対する保護のために、他のタイプのメタデータを同期状態に（即ち、矛盾がない状態に）保つために使用されるレコードの組である。ログには、複数の構造に対する関連する更新を記述する単一のレコードが含まれる。この用語は、周辺でのみ有用であるが、上で説明した代替解決策との関連で提供される。
【００１２】
ファイル・システム：  ディスク（または他の媒体）の定義された組を管理し、また、データおよびデータ・ファイルの、一貫性のある追加、修正、および削除を実現する形で、データへのアクセスを提供する、ソフトウェア・コンポーネント。この用語は、ディスク（または他の媒体）の特定の組に含まれるデータおよびメタデータの組を記述するのにも使用される。本発明は、通常は、最も頻繁に、回転式磁気ディスク記憶システムと共に使用されるが、また、隣接するブロックに配置されたデータと共に名前によってアクセスできるいかなるデータ記憶媒体と共にでも使用可能であり、したがって、用語「ディスク」または「ディスク・ストレージ」等が本明細書で使用される場合に、記憶媒体のこのより一般的な特性が意図されている。
【００１３】
スナップショット：  ある所定の時点でのファイル・システムの状態を取り込んだファイルまたはファイルの組。
【００１４】
メタデータ・コントローラ：  あるファイルへのすべてのアクセス要求がそれを介して処理される、ネットワーク化されたコンピュータ・システム内のノードまたはプロセッサ（本発明の譲受人が提供するスケーラブル並列システムのｐＳｅｒｉｅｓなど）。この用語は、完全を期して提供されるが、本発明の動作の理解には関連しない。
【特許文献１】米国特許出願（弁理士整理番号ＰＯＵ９２００３０００６ＵＳ１）
【特許文献２】米国特許第６０３２２１６号
【特許文献３】米国特許出願第ＵＳ２００２／０１２４０１３号
【特許文献４】米国特許出願第ＵＳ２００２／０１４３７３４号
【特許文献５】米国仮特許出願第６０／２１４１２７号
【特許文献６】米国特許出願第ＵＳ２００２／０１２３９９７号
【発明の開示】
【発明が解決しようとする課題】
【００１５】
したがって、本発明の目的は、ファイル・システム復元操作中に、制限付きファイル・アクセスおよび完全なファイル・アクセスの両方を可能にすることである。
【００１６】
本発明の目的はまた、できる限りファイル・システム復元中の継続的なアプリケーション・プログラム操作を可能にすることである。
【００１７】
本発明のもう１つの目的は、ファイル・システム・バックアップ機能およびファイル・システム復元機能の両方の柔軟性を高めることである。
【００１８】
本発明の更にもう１つの目的は、分散データ処理システムおよび／または並列データ処理システムでの操作の効率を高めることである。
【００１９】
本発明の更なる目的は、未復元状態でのみ存在するファイルの除去を可能にすることである。
【００２０】
本発明のまた更なる目的は、未復元状態でのみ存在するファイルのリスト（一覧表）化を可能にすることである。
【００２１】
本発明の目的はまた、バックアップ能力および復元能力を強化するためにファイル・システムの機能強化されたデータ構造を提供することである。
【００２２】
本発明のまたもう１つの目的は、本明細書で開示されるファイル・システム復元方法を実行するシステムおよびプログラムを提供することである。
【００２３】
本発明の更なる目的は、ファイル・バックアップ操作中、特に大ファイル・システムのバックアップ操作中に作成されるデータ構造を活用することである。
【００２４】
最後に、しかしこれに限定はされないのであるが、本発明の目的は、ファイル・システム復元を実行するデータ処理操作全体を通じたファイル・システムのアクセスおよび可用性を改善することである。
【００２５】
本発明のさまざまな実施形態によって満足される望ましい目的のリストの本明細書での詳述は、これらの目的のいずれかまたはすべてが、個々にせよまたは集合的にせよ、本発明の最も一般的な実施形態またはそのより詳細な実施形態のいずれかにおいて本質的特徴として存在していることを暗示または提案するよう意図されたものではない。
【課題を解決するための手段】
【００２６】
本発明の好ましい実施形態によれば、ファイル・システムにアクセスする方法が提供される。この方法は、制限された属性を有しデータを有しないファイルであって、前記ファイルが未復元状態であることの表示が設けられたファイルについて、エントリーを作成するステップと、前記ファイルについてのファイル・システム操作を可能にするステップであって、前記操作が（１）前記ファイルのファイル名をリスト化するステップと、（２）前記ファイルを除去するステップとからなるグループから選択されたステップと、を有する。この方法の重要な態様は、ファイル・システム内において実質的にプレース・キーパー（場所維持）・エントリーとなるものを作成することである。このエントリーは、未復元状態を有することをそれが表示するのと共に、この状況が「未復元」から「復元済み」に変更されたファイルに関して引き続き行う操作についての機構を提供する。
【００２７】
本発明のもう１つの態様によれば、ファイル・システムを復元する方法が提供される。この方法は、ファイル・システム復元処理中に、復元されるファイルごとに、ファイルの復元に続いてファイル状況インジケータ（指標）を未復元表示から復元済み表示に変更するステップを有する。この方法はまた、ファイル・システム復元処理が他のファイルに関して継続される時であっても、ファイルが復元済み状態であることを前記状況インジケータが示しているファイル、に対しての即時アクセスを可能にする更なるステップを含むことが好ましい。アプリケーション・プログラムが、未復元状態のファイルにアクセスする場合に、ファイル復元ソフトウェアにイベントが提示され、ファイル復元ソフトウェアは、即座にそして同期的にファイルを復元し、復元された状態を反映するようにインジケータを変更し、イベント「完了」を返す。このイベントが処理されつつある間、ファイル・アクセスに関するアプリケーション要求は未定状態に保持される。イベントが完了した時にファイルが成功裡に復元された場合には、アプリケーション要求が引き受けられ、なんらかの理由（たとえば、テープ不良）で復元に失敗した場合には、アプリケーション要求が拒否される。わずかな遅延を除いて、アプリケーション・プログラムは、この目的のためにファイルを復元する必要があったのだということを知らない。２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２４０１３号（２００１年６月２５日出願の第０９／８８７５３３号、弁理士整理番号ＩＬ９２０００００６７ＵＳ２）および２００２年１０月３日公開の米国特許出願第ＵＳ２００２／０１４３７３４号（２００１年６月２５日出願の米国特許出願第０９／８８７５２０号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ３であり、０９／８８７５３３の分割出願である；この両方が、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ１、２０００年６月２６日出願に基づいて出願された）、および２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２３９９７号（出願番号第０９／８８７５５０号、弁理士整理番号ＩＬ９２０００００６８ＵＳ２、２００１年６月２５日出願であり、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６８ＵＳ１、２０００年６月２６日出願に基づく）に記載の方法によって、これらのイベントを提示し、同一のファイル・システムを搭載する複数のコンピュータにまたがってのイベント処理が完了するまでアプリケーション実行を遅延させる機構が提供される。本発明では、これらの機能を活用して、要求されたファイル・システムを復元する能力を提供する。ファイル・システム復元操作中にアクセスされ、復元済み状態であることを反映するように状況インジケータがセットされたファイルについて、ファイル・システム操作のすべてが可能である。このようにして、できる限り多くのファイル・アクセスが可能にされ、復元処理の持続時間全体を通じて実行される。このような方法で、ファイル・システム内のあらゆるファイルを使用する連続的なアプリケーション・プログラムの実行が、ファイル・システム・メタデータが復元されるや否や可能になる。アプリケーション実行は、要求された特定のデータがまだ復元されていない場合に、アプリケーション要求に同期してデータの「オン・デマンド」復元を要求することができる。すべてのアプリケーション・プログラムが、完全なファイル・システム復元が達成されるまで待つ必要は、もはやない。
【発明を実施するための最良の形態】
【００２８】
本発明の環境および操作のよりよい理解を提供するために、上述の汎用並列ファイル・システム（ＧＰＦＳ）の関連部分および構造を簡単に再検討する。ＧＰＦＳが、Ｘｏｐｅｎファイル・システム標準規格に準拠するファイル・システムに類似し、したがって、そのようなファイル・システムのすべてが本発明と共に使用可能であることにも留意されたい。しかし、本発明は、そのようなファイル・システムに限定はされない。一般に、ファイルが３つの基本的な部分、即ち属性、データ、および名前からなることに留意されたい。一般にこの３つの部分はさまざまなファイル・システムで異なる場所に保管される。ファイル・サイズ、作成時刻、およびアクセス許可などのファイルの属性は、ファイル・システム技術で一般にｉノードと称するファイル構造に保管される。ファイル・システムごとに１つのｉノード・ファイルがある。ｉノードには、ファイルのデータ・ブロックへのポインタ即ち、ストレージ・システム内または特定の記憶装置内の物理的位置を示すポインタも保管される。単一のファイルに、任意の量のデータ、即ち皆無から２６４バイト（ほとんどすべての現在使用可能なデータ処理システムでの現在の限度）までを含めることができる。ファイルの名前は、ファイル・システム・ディレクトリと称する別々の構造に保管される。ディレクトリ・エントリーによって、ユーザがファイル、ディレクトリまたはサブディレクトリに割り当てた名前が、そのファイルを保管するｉノードにマッピングされる。ＧＰＦＳでは、ファイルをディレクトリからすばやく区別するために、ディレクトリ・エントリーに対象タイプ・フィールドも含まれる。ディレクトリ構造によって階層名前空間が形成され、ファイルを識別するパスが定義される。ファイルは複数の名前を有することができる。ディレクトリ構造（ファイル名を含む）は、通常のファイル・システム・ファイルに保管されるが、そのデータを「通常の」データ・ブロックと区別する属性を有することに留意されたい。
【００２９】
図１に、ファイル・システムの原理的要素を更に具体的に示す。図示されたような通常のファイル・システムには、ディレクトリ・ツリー１００、ｉノード・ファイル２００、およびデータ３００が含まれる。この３つの要素は、通常は、ファイル・システム内でファイル自体として存在する。たとえば、図１からわかるように、ｉノード・ファイル２００には個々のレコードまたはエントリー２２０の集合が含まれる。ファイル・システムごとに１つだけｉノード・ファイルがある。具体的に言うと、ｉノード・ファイルは図１の最下部に示されたものであり、参照符号２００によって示される。ディレクトリ・ツリー１００内のエントリーにはフィールド１１２などのポインタが含まれ、このフィールドにはｉノード・ファイル２００への単純なインデックスとして動作する整数の量が含まれることが望ましい。たとえば、フィールド１１２にたとえば「１０８７６」を表す２進整数が含まれる場合に、これによってｉノード・ファイル２００の１０８７６番目のエントリーが参照される。特殊なエントリーを使用して（下で説明する参照符号２１６を参照されたい）、ファイルをディレクトリであるとして示すことができる。このように、ディレクトリとは、通常は、保管されたファイルの名前が任意の深さのディレクトリ・ツリー内に維持されているファイルである。ディレクトリ１００に関して、本発明のよりよい理解のために意味が理解されなければならない３つの用語がある。「ディレクトリ・ツリー」とは、ファイル・システムのすべてのディレクトリを含むディレクトリの集合である。「ディレクトリ」とは、ディレクトリ・ツリーの要素である特定のタイプのファイルである。ディレクトリは、ディレクトリ・ツリー内の下位の位置を占めるファイルまたはディレクトリのいずれか、であるｉノードへのポインタの集合である。「ディレクトリ・エントリー」とは、ファイルまたはディレクトリを指すディレクトリ内の単一のレコードである。図１では、模範的なディレクトリ・ツリーが機能ブロック１００内に示されている。模範的なディレクトリ・エントリーには、図示のように、書式１２０の要素が含まれるが、本発明の目的のためのディレクトリ・エントリー内容の例示については図３も参照されたい。図１には（便宜的目的のため）２レベルだけの階層が示されているが、ディレクトリの階層ツリー構造の深さは２レベルに制限されないことを理解されたい。実際、どのディレクトリ・ツリーにも数十個のレベルが存在する可能性がある。にもかかわらず、このディレクトリ・ツリーの深さは、１つのファイルだけが識別されるかアクセスされる必要がある場合における複数ディレクトリ参照の必要性に寄与している。しかし、どの場合でも、ディレクトリ・ツリーの「葉」が、ファイル名（参照符号１１１）をｉノード・ファイル２００内のエントリー２２０に関連付けるのに使用される。参照は、ｉノード・ファイル２００へのポインタを提供する「ｉノード番号」（参照符号１１２）による。本明細書で考慮されるタイプのファイル・システムには、１つのｉノード配列がある。本発明の好ましい実施形態では、このｉノード配列はｉノード・ファイル２００であり、インデックスによって、配列要素がポイントされる。したがって、ｉノード＃１０８７６は、ｉノード・ファイル２００の１０８７６番目の配列要素である。通常、このポインタは、ｉノード・ファイル２００への単純なインデックスであり、したがって、本質的に線形の形でアクセスされ、そうであることが好ましい。したがって、インデックスが１０８７６である場合に、これは、ｉノード・ファイル２００の１０８７６番目のレコードまたは配列要素をポイントする。名前エントリー１１１を用いると、ツリーの１つ深いレベルに移動することができる。通常のファイル・システムでは、名前エントリー１１１によって、たとえばディレクトリまたはデータ・ファイルであるｉノード＃１０８７６がポイントされる。これがディレクトリである場合には、名前の次のレベルに関して、そのディレクトリ・ファイル内を再帰的に検索する。たとえば、エントリー１１１が、図１に示されているように「ａ」であると仮定する。この場合に、「ａ２」のｉノードに関する名前エントリーが、ｉノード＃１０８７６のデータから検索される。名前エントリー１１１によってデータがポイントされる場合には、名前検索の終りに達している。本発明では、名前エントリー１１１に追加フィールド１１３（図３参照）が含まれ、これによって、ディレクトリであるか否かが示される。ディレクトリ・ツリー構造は、別々に含まれる。というのは、ＰＯＳＩＸによって、本発明の理解または動作のいずれにも関連しない形で同一のファイルの複数の名前が可能になるからである。
【００３０】
ｉノード番号による参照ではなく、ファイル名による個々のファイル・エントリーへの参照が可能になるという点で、ディレクトリ・ツリー１００は、当該ファイル・システムのために階層的名前空間を提供する。ディレクトリの各エントリーはｉノードを指す。そのｉノードは、ディレクトリの場合もあり、ファイルの場合もある。ｉノード２２０は、ｉノード・ファイル２００（上で説明した）内の位置のインジケータ（指標）であることが望ましいフィールド１１２内のエントリーによって決定される。ｉノード・ファイル２００内のｉノード・ファイル・エントリー２２０は、通常は線形リストとして実施され、そうであることが望ましい。このリストの各エントリーに複数のフィールド、即ちｉノード番号２１２、世代番号２１３、個々のファイル属性２１４、データ・ポインタ２１５、最終修正日付２１６、およびファイルがディレクトリであるか否かを示すインジケータ・フィールド２１７が含まれる。本発明と関係または関連性のない他のフィールドも、通常はｉノード・エントリー２２０内に存在する。しかし、関連出願（弁理士整理番号ＰＯＵ９２００３０００６ＵＳ１）と共に使用するのに最も関連するフィールドは、最終修正日付を示すフィールド２１６である。ｉノード番号は、ファイル・システム内で固有である。ファイル・システムには、もはや存在しないが存在した時に同一のｉノード番号を有していたあるファイルから、あるファイルを区別するのに普通使用される、世代番号２１３が含まれることもまた望ましい。ｉノード・フィールド２１４によって、あるファイルに関連するある種の属性が識別される。これらの属性には、最終修正日付、作成日付、ファイル・サイズ、ファイル・タイプ、読取アクセスまたは書込アクセスを示すパラメータ、さまざまなアクセス許可およびアクセス・レベル、圧縮状況、暗号化状況、隠し状況、およびネットワーク内での状況が含まれるが、これらに限定はされない。ｉノード・エントリー２２０には、それがポイントするファイルが実際にディレクトリであるかどうかを示すエントリー２１７も含まれる。これによって、ファイル・システム自身のための名前空間として最もよく記述されるものをこのファイルが含んでいるという事実に従って、ファイル・システム自体がこのファイルを異なる形で扱うことが可能になる。しかし、最も重要なことは、普通のｉノード・エントリー２２０に、ファイル・システムのデータ部分３００に常駐する実際のデータ３１０の物理的な位置を識別するのに十分な情報を含むデータ・ポインタ２１５が含まれるということである。
【００３１】
具体的に本発明の構造および操作に関して、問題のファイルの復元状況を示すフィールドがｉノード・エントリーに含まれる。具体的に言うと、対象のファイルの属性が復元済み状態であるか否かの表示が図１のフィールド２１８によって与えられる。同様に、対象のファイルのデータが復元済み状態であるか否かの表示が図１のフィールド２１９によって与えられる。下で具体的に説明するように、本発明では、ファイル・システム復元操作中に、あるファイルの属性が、当該ファイル内のデータが利用可能になるのに先立って使用可能にされるという状況が企図されている。したがって、別個のフィールド２１８および２１９が、このために設けられる。この特徴が必要とされないかまたは望まれない場合には、本発明の異なる実施形態によって、そのようなフィールドを１つだけ用いることで、属性およびデータの両方に適用されるような復元状態を示すことができる。
【００３２】
しかし、一般にファイル・システムの完全な復元には、ファイル・システム内のすべてのファイルのファイル名、属性、およびデータを復元することが含まれる。名前がないファイルにはアクセスすることができない。しかし、障害の深刻さが軽い情況において、ファイルの属性またはデータが欠けている場合には、ファイル・システムまたはアプリケーション・プログラムは、通常、ファイルへのアクセスを試みる場合にエラー表示を受け取る。
【００３３】
本発明によって、ファイルの名前、属性、およびデータを独立に復元する手段が提供される。属性もデータもないファイルを作成するのに使用され、また未復元状態のファイルを反映するファイル・システム、へのインターフェースが本発明によって用いられる。未復元状態のファイルに対して許容される対策は、その名前をリスト化すること、またはファイル・システムからそのファイルを除去することだけである。ファイル・システムは未復元ファイルを識別することができるので、したがって、すべてのファイルが復元される前にアプリケーション・プログラムが実行を開始できるようにすることができる。未復元ファイルにアクセスするプログラムは、ファイルの属性またはデータを復元することができるデータ管理アプリケーションに対するイベントを呼び出すか、またはファイルに現在アクセスできないことを示す戻りコードを受け取る。失敗状況に対処して、より早期の復元のためにより高い優先順位のファイルを位置付けるように、復元プログラムがスケジューリングを再順序付けできるようにすることは可能ではあるが、実際には、テープを読み取ることができないであるとかテープが使用可能でないであるとかの、比較的単純なエラー・シナリオから失敗が生じると通常は思われている。
【００３４】
すばやいファイル・システム復元を実施する多くの方法があり、それらの方法によって、ユーザ・アプリケーションを一時停止するという潜在的コストをかけてすばやくアプリケーションを再開始することと、完全な復元が完了するのにより長い時間をかけることとの間のトレードオフが示される。
【００３５】
当初に、新しい空のファイル・システムが作成される。次に、同時に出願された関連出願の中で引用されており、また特に、後述の［関連するバックアップ処理］以下で述べられている、ファイル・システム・バックアップ操作、の最中にたとえば作成されたシャドウ・ファイル（図２の参照符号５００）、を使用してすべてのディレクトリ・エントリーが復元される。次に、ファイルの鍵になる属性が、バックアップ・システムから、バックアップされたデータを有する各ｉノードに復元される。この属性には、サイズ、所有者、およびアクセス許可が含まれる。データは、このステップの一部としては復元されず、ファイルは未復元としてマークされる。アプリケーション・アクセスは、復元のこの時点が完了した後に限って許可される。これには、リストとディレクトリ・ルックアップとが含まれる。名前空間ファイル５００の使用によって、名前空間全体が並列に復元されるのが可能となる。このようにして、ファイル・システムは、たとえ分散システムにまたがっていたとしても、ユーザ・アプリケーションから使用可能となる。未復元のファイル属性またはファイル・データにアクセスするアプリケーションは、要求されたファイルが復元されるまで一時的に停止される。しかし、アプリケーション・プログラムは未復元ファイルを除去することを許可され、それを行うために待つ必要はない。そのファイルは削除済みとしてマークされ、復元するのは避けられる。
【００３６】
すべてのファイル属性およびデータを復元するために１つまたは複数の復元処理が開始される。「クイック（迅速な）」復元処理によって、ファイルの属性だけ（データではなく）を復元することができる。複数のクイック復元処理を実行して、ファイル属性を並列に復元できるようにすることができる。ファイルの属性だけのクイック復元によって、許可検査を行うことができると同時に、待ち時間なしでファイルのｓｔａｔ（）をユーザが行えるようになる。ｓｔａｔ（）は、Ｘｏｐｅｎファイル・システム標準規格によって指定された、ファイルの属性を返すがデータは返さないオペレーティング・システム呼出しである。ファイルのデータを復元するために、１つまたは複数の「フル（完全な）」復元処理も実行しなければならない。この復元は、ｉノード順またはファイルがオフライン・テープに保管された順序で行うことができる。追加の処理を作成して、大きいファイルを並列に復元することもできる。
【００３７】
個々のファイルの復元は、ほとんど同様の形式で行われる。復元されるファイルをユーザが識別する。各ファイルが名前空間に挿入される（まだ挿入されていない場合に）。既存のデータまたは属性が削除され、ファイルが未復元状態として表示されるようにマークされる。ファイル・システムはまた、「フル」復元処理がファイルへのユーザのアクセスとは並列に実行されるようにこれをスケジュールすることが好ましい。
【００３８】
本発明には、ＧＰＦＳに存在する他の機能の使用と一緒に、完全に新しいプログラム実施される機能が含まれる。この機能は、本明細書の他の場所で参照した、２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２４０１３号（２００１年６月２５日出願の出願番号第０９／８８７５３３号、弁理士整理番号ＩＬ９２０００００６７ＵＳ２）および２００２年１０月３日公開の米国特許出願第ＵＳ２００２／０１４３７３４号（２００１年６月２５日出願の米国特許出願第０９／８８７５２０号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ２であり、０９／８８７５３３の分割出願であり、この両者が米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ１、２０００年６月２６日出願に基づいて出願された）、および２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２３９９７号（出願番号第０９／８８７５５０号、弁理士整理番号ＩＬ９２０００００６８ＵＳ２、出願２００１年６月２５日であり、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６８ＵＳ１、２０００年６月２６日出願に基づく）に記載されている。これらの公開された特許出願によって、同一のファイル・システムを搭載する複数のノードにまたがって外部データ管理アプリケーションにイベントを同期的に提示する機構が指定される。これは、アプリケーション呼出しによってトリガされ、アプリケーションは、イベントが処理されるまで一時停止される。ここでの（処理の）流れは、オン・デマンド復元アプリケーションが、これらのイベントを処理するために登録されたＧＰＦＳクラスタ内のノードで開始されることである。この特定のイベントに関して複数のアプリケーションが存在する可能性がある。この処理フローは、クラスタのノードＡで操作するアプリケーションが、まだ復元されていないファイルの読取を試みることである。ノードＡのファイル・システムはそのファイルが「未復元」であることを認識し、またオン・デマンド復元アプリケーションがノードＺで登録されていることを知る。ノードＡのファイル・システムは、ノードＺにイベントを送り、元のアプリケーションの処理を一時停止させる。ノードＺは、そのイベントをオン・デマンド復元アプリケーションに提示し、そのオン・デマンド復元アプリケーションは、バックアップ・コピーを読み取り、そのデータをファイル・システムに書き込み、そしてそのファイルを「復元済み」としてマークする。その後、オン・デマンド復元アプリケーションはノードＺでのイベントを完了させ、そのノードＺは、アプリケーションを再開するようにノードＡに通知し、したがって読取要求を満足する。
【００３９】
本明細書で提供されるインターフェースには、属性もデータも持たない、指定されたｉノード番号を有する一組の名前付きファイルを作成する能力が含まれる。これらのファイルのスケルトン（骨組み）は、そのステータスが未復元として示される状態において作成される。復元なしのこれらのファイルに対して行うことができる対策は、その名前のリスト化またはそのファイルの削除だけである。他の操作によって、そのファイルを復元できるデータ管理アプリケーションへイベントが呼び出されるか、または、そのファイルにアクセスできないことを示す戻りコードの生成が引き起こされる。
【００４０】
このインターフェースは、次のように具体的に説明することができる。即ち呼出しの第１組では、メタデータ（属性）を、ｉノード番号によって指定されるｉノードに書き込む。インターフェース・フォーマットは、次の形である。
Mmwrite_inode (atttribute_structure, inode_num)
ここで、属性構造体には、下記のものを明示的に含んだシャドウ・ファイル、と共に保存されるデータが含まれる
・サイズ
・許可
・所有者
・未復元ビット
・最終修正および最終アクセスの時刻
・タイプ（通常のファイル、ディレクトリ）
および
Mmwrite_dir (dir_name, entry_name,inode_num, type)
これは、ｄｉｒ＿ｎａｍｅによって指定されるディレクトリに、名前ｅｎｔｒｙ＿ｎａｍｅを有し、ｉｎｏｄｅ＿ｎｕｍによって指定されるｉノード番号を指し、ｔｙｐｅによって指定されるタイプ（ディレクトリ、ファイル、またはリンク）を有するエントリーを書き込むというセマンティクス（意味）を有する。
【００４１】
本発明に関連する既存の機能に、ファイル・システムの名前空間全体を含むファイル名のリストをすばやく生成する能力が含まれる。これは、本発明と同時に出願された関連特許出願（弁理士整理番号ＰＯＵ９２００３０００６ＵＳ１）に記載されている。その中で記載されている名前空間ファイルは、必要とされる訳ではないが、復元処理を高速化するように働く。本発明はまた、前に提示した特許出願（２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２４０１３号（２００１年６月２５日出願の出願番号第０９／８８７５３３号、弁理士整理番号ＩＬ９２０００００６７ＵＳ２）および２００２年１０月３日公開の米国特許出願第ＵＳ２００２／０１４３７３４号（２００１年６月２５日出願の米国特許出願第０９／８８７５２０号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ２であり、０９／８８７５３３の分割出願である；この両者は、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６７ＵＳ１、２０００年６月２６日出願に基づいて出願された）、および２００２年９月５日公開の米国特許出願第ＵＳ２００２／０１２３９９７号（出願番号第０９／８８７５５０号、弁理士整理番号ＩＬ９２０００００６８ＵＳ２、出願２００１年６月２５日であり、米国仮特許出願第６０／２１４１２７号明細書、弁理士整理番号ＩＬ９２０００００６８ＵＳ１、２０００年６月２６日出願に基づく））に記載されているように、並列システムから階層ストレージ・マネージャにイベントを提示する能力を用いることも望ましい。本発明によって、２つの前述の特許出願に記載のデータ管理アプリケーション・プログラム・インターフェース（ＤＭＡＰＩ）というインターフェースを介して提示される新しいイベント・クラスも定義される。このイベント・クラスは、アクセスのタイプ（ファイル・データ・アクセスまたはファイル属性アクセス）を反映しており、その結果、データ管理アプリケーションは、あるイベントを失敗させることを可能にするポリシーを持つように構成される。データ管理アプリケーションが、あるイベントを失敗させることを選択する場合には、そのアプリケーションは障害を受け取る。データ管理アプリケーションが、そのイベントに成功裡に応答する場合には、アプリケーション要求が再試行される。データ管理アプリケーションからの期待される応答は、データ管理アプリケーションがファイルに関連するデータを復元し、ファイル属性（所有者、許可など）を復元し、ファイルが未復元として印付けされる特殊な状態をクリアするというものである。これによって、アプリケーションによってより遅い応答がもたらされるが、リアル・タイムに敏感でないいかなるアプリケーションについてもアプリケーション障害がもたらされることはない。このアプリケーション低速化の頻度は、データ管理イベントまたは通常の復元処理のいずれかによって復元済み状態にステージ・バックされたファイルが増えるにつれて減る。ファイルは復元するのに先立って除去できることと、データ管理アプリケーションがその状態を認識し、削除されたファイルは復元しないこととに留意されたい。
【００４２】
［関連するバックアップ処理］
上で述べたように、本発明の好ましい実施形態では、関連特許出願（弁理士整理番号ＰＯＵ９２００３０００６ＵＳ１）により詳細に記載されているように、ファイル・システム・バックアップ処理の一部として作成されるテーブルが利用される。そのテーブルの構成および関連特許での使用に注意を向ける。
【００４３】
（１）関連発明では、ｉノード・ファイル２００がｉノードによるバックアップとほとんど同様の方法で読み取られ、変更されたｉノードのリスト４００（図２参照）が生成される。これによって、バックアップ判断基準を満たすｉノードのリストがもたらされる。しかし、ｉノードによるバックアップとは異なり、関連発明では、ｉノード番号を手掛かりとして使用するバックアップは行われない。
【００４４】
（２）関連発明では追加ステップが使用され、この追加ステップでは、ディレクトリ名前空間１００が読み取られて、ファイル・システム内の各ファイルの名前が、それに対応するｉノード番号と共に含まれた、ファイル名のテーブル５００（図２参照）を生成する。ディレクトリを読み取る時に、関連発明では、図３に示すように、ディレクトリ・エントリーにより新たに供給される対象タイプ・フィールド１１３が使用される。従来のファイル・システムでは、対象がディレクトリまたはファイルであるか否かを示すディレクトリ・エントリー内のインジケータが保持されない。その情報は、一般にｉノード・ファイル内だけに保持され、したがってｉノードの読取りが必要である。それ故、関連発明の動作では、すべてのアクティブｉノードを読み取る必要なしにサブディレクトリを識別できるようにするためにフィールド１１３が提供され、このようにして関連方法の主要な長所の１つがもたらされる。ディレクトリ・スキャンの結果は、ファイル・システムに現在存在するすべてのファイルについての名前とｉノード番号とを有するテーブル５００である。このスキャンは、現在のアクティブなファイル・システムかまたはファイル・システムのスナップショットかのいずれかに対して行われる。
【００４５】
（３）関連発明では、結果として得られるシャドウ名前空間テーブル５００を、ｉノード番号によってソートする。これによって名前空間テーブル５００をｉノード・リスト４００と簡単にマージできるようになり、これによるテーブルによって、バックアップされるファイルを指すファイル名のリストが作成される。
【００４６】
（４）結果として得られるマージされたテーブルの構造および内容は、ファイルの数と各ファイルのサイズとに基づいてマージされたテーブルを等しい部分に分割するための、そしてその後、ファイル・システム（たとえばＧＰＦＳ）の複数のノードにまたがって並列にバックアップを実行する複数の並列バックアップ・ジョブ「ワーカー・スレッド」を呼び出すための、付加的な能力を関連発明に提供する。テーブルの「等しい」部分への分割は、各ファイルに必要な時間を推定することによって行われる。時間推定は、下記の計算に基づくことが望ましい（しかし、この計算の正確な式によって決定されるものではないことに留意されたい）。
時間＝基礎時間＋（時間／バイト）＊（バイト数）
ここで、基礎時間とは、１バイトのファイルをバックアップするのに必要な推定時間であり、時間／バイトとは、追加のバイトをバックアップするのに必要な増分時間の推定値である。関連発明のこの態様は、そうあることが望ましいが、任意選択的なものである。
【００４７】
（５）バックアップが、複数のバックアップ・リポジトリ（集積場所）にまたがって分散される場合には、各ファイルを、毎回同一のリポジトリに送ることが望ましい。ベース・バックアップで、ファイル名前空間がリポジトリごとのほぼ等しい部分に分割され、ファイルは次のベース・バックアップまでそのリポジトリに関連付けられたままになる。このマッピングが元々の名前空間テーブルに追加されることが望ましい。関連発明のこの態様は、そうあることが望ましいが、また任意選択的なものでもある。区分化は、指定された基礎バックアップで任意に実行される。ｎ個のリポジトリがある場合に、シャドウ・ファイルは、上のエントリー（４）で指定されたものとほぼ同一の負荷のｎ個の部分に分割される。その後、ｍ個のワーカー・スレッドを使用してｎ個のリポジトリにデータが移動されるが、ここでｍはｎの倍数であるため、理想的には、各リポジトリが所望の時間のうちにバックアップを完了できるようになる。
【００４８】
（６）ファイル名からバックアップ・リポジトリへのマッピングは、バックアップ作業負荷を再平衡化できるように変更されることが望ましい。マッピングが変更される時に、ファイルの既存のバックアップ版は新しいリポジトリに移動されることが望ましいが、これは必要という訳ではない。関連発明のこの態様は、そうあることが望ましいが、任意選択的なものでもある。
【００４９】
（７）名前空間テーブルが、次のバックアップでの使用のために保存される。現在のバックアップの名前空間を前のバックアップと比較することによって、削除されたファイルと名前を変更されたファイルとが簡単に検出され、標準バックアップ・ポリシーに従って正しいバックアップ対策が行われる。関連発明のこの態様は、そうあることが望ましいが、任意選択的なものでもあり、特に関連発明をその最も広い範囲で検討する時にはそうである。
【００５０】
上記から、上で説明した方法およびシステムを介して本発明の目的が達成されることを諒解されたい。具体的に言うと、本発明によって、復元処理自体の間にファイル・アクセスが許可されるという点で、はるかに柔軟なファイル・システム復元操作がもたらされることがわかる。更に、許可されるファイル・アクセスの程度もまたより柔軟にでき、すべての必要とされることがファイルの属性へのアクセスだけである場合には特にそうである。また、ファイル・システム復元の柔軟性は、関連特許に開示したように、ファイル・システム・バックアップ操作中に作成される名前空間テーブルを使用することを介して機能強化されることに留意されたい。ファイル・システム復元の柔軟性は、ファイル復元処理中に行われるアクセス要求に応答してファイル復元の順序を修正できるという意味においても改善される。
【００５１】
ある好ましい実施形態に従って本発明を詳細に説明したが、多数の修正および変更を当業者が行うことができる。したがって、特許請求の範囲の意図するところは、本発明の真の趣旨および範囲に適合するようにそのような修正および変更のすべてをカバーすることである。
【図面の簡単な説明】
【００５２】
【図１】本発明によって活用されるファイル・システム構造を示すブロック図である。
【図２】データ構造記述の大きいブロックの検索を可能にするような、またバックアップ・タスクを複数の独立の動作に区分化することを可能にするような、形態にて現在使用可能なすばやく効率的なバックアップ操作、と共に用いることができる２つの追加構造体の構造を示すブロック図である。
【図３】ファイルとディレクトリ・エントリーまたはサブディレクトリ・エントリーとを区別するためにファイル・システム・ディレクトリ内で使用可能な構造を示すブロック図である。
【符号の説明】
【００５３】
１００  ディレクトリ・ツリー
１１１  ファイル名
１１２  ｉノード番号
２００  ｉノード・ファイル
２１２  ｉノード番号
２１３  世代番号
２１４  個々のファイル属性
２１５  データ・ポインタ
２１６  最終修正日付
２１７  インジケータ・フィールド
２２０  レコードまたはエントリー
３００  データ
３１０  データ
４００  リスト
５００  名前空間ファイル
【図１】
2005018757.tif 000003
【図２】
2005018757.tif 000004
【図３】
2005018757.tif 000005