JP2005004778A - ネットワーク化環境においてシャドウコピーを開示する機構 - Google Patents

Abstract

【課題】 共有ボリュームのボリュームシャドウコピーをネットワ−ク上でリモートクライアントに開示するための機構を提供すること。
【解決手段】 共有ボリュームは、ルートを有するクライアントコンピューティングシステムにおいてアクセスされる。このボリュームのボリュームシャドウコピー（または「スナップショット」）は、共有ボリュームの子リソースとして識別される。スナップショットを表す子リソースは、デフォルトで通常のビューから隠されることもある。スナップショットにアクセスするために、ユーザは、まるでそれが共有ボリューム上の通常のファイルまたはディレクトリであるかのように子リソースにアクセスすることができる。有利な点は、ユーザは、スナップショットボリュームを表す新しいボリュームをマウントする必要はなく、むしろユーザはそのスナップショットに直接にアクセスすることができる。
【選択図】 図３

Description

本発明は、分散ファイルシステムに関する。より詳細には、本発明は、分散ファイルシステム、およびこの分散ファイルシステム上で共有ボリュームのシャドウコピーを開示する（expose）ことに関する。

クライアント／サーバネットワーク環境は、広く普及してきている。クライアントコンピュータシステムが、ネットワークを介してサーバ上に常駐するファイル記憶装置に接続することは、今日では普通になっている。また、今日のコンピューティング環境において使用されている多くの異なるコンピューティング・アーキテクチャおよびプラットフォームがある。

ネットワークのハードウェアとソフトウェアのプロバイダ間における競争によって、プロバイダの提供する製品に関連して、ますます洗練されたサービスを提供するように、プロバイダに拍車がかけられる。例えば、単なるバックアップおよびファイル復元機能は、普通に提供されるようになりつつある。今日では、多くのネットワ−クサーバは、ネットワーク記憶装置のユーザが記憶装置の状態をある以前の時間まで逆戻りする機能を提供する。これにより、ハードウェア故障にまでは至らないいくつかの予見できない障害の場合に、失われたデータを回復する動作が簡単になる。例えば、ネットワークシステムのユーザは、ある日、自分のサーバ上のファイルが壊れてしまうか、それとも他の何らかの理由で、ある以前の時点における自分のファイル状態に再度戻りたいと思う場合がある。ボリュームシャドウコピー（volume shadow copy）（「スナップショット（snapshot）」とも呼ばれる）は、今日、特にこの目的で使用される。ボリュームシャドウコピーは、本質的には、以前のある時間におけるボリュームの状態のビューである。ボリュームシャドウコピーは、ボリュームの状態を逆戻りする一般的な機構になっている。このドキュメントを通じて、ボリュームシャドウコピーとスナップショットという用語は、区別なく使用されることもある。

既存のサーバ技術の１つの欠点は、クライアント／サーバ環境において、ボリュームシャドウコピーにアクセスするためには、スナップショットをクライアントマシンにマウントする必要があることである。この手続きは、典型的には、ユーザがボリュームをマウントするのに十分な特権をもってクライアントマシンにログインする必要があり、典型的には、管理用の特権を必要とすることもある。スナップショットにアクセスしたいと思うたびに、ユーザが管理者または十分な特権をもつ他のユーザを捜し出す必要がある場合には、ボリュームシャドウコピーの利便性が失われてしまう。

これらの技術の別の欠点は、異なるボリュームをマウントして共有する各シャドウコピーを開示することにより、名前空間が汚染される傾向にあることである。換言すれば、共有ボリュームの複数のシャドウコピーがマウントされると、ユーザは、同じボリュームとして現れるいくつかの異なるバージョンを有することにより混乱する可能性がある。

ネットワーク化環境において共有ボリュームのシャドウコピーをクライアントに開示するための適切な機構は、当業者には理解できないものであった。

本発明は、共有ボリュームのボリュームシャドウコピーを、ネットワークを介してリモートクライアントに開示するためのシステムおよび方法を対象としている。簡潔に述べると、共有ボリュームは、ルートを有するクライアントコンピューティングシステムにおいてアクセスされる。このボリュームのボリュームシャドウコピー（または「スナップショット」）は、共有ボリュームの子リソースとして識別される。スナップショットを表す子リソースを、デフォルトにより通常のビューから隠すこともできる。スナップショットにアクセスするために、ユーザは、子リソースが共有ボリューム上の通常のファイルまたはディレクトリであるかのように、子リソースにアクセスすることができる。ユーザは、スナップショットボリュームを表す新しいボリュームをマウントする必要はないが、むしろユーザは、スナップショットに直接にアクセスできることが有利である。

最初に、本発明を、本発明の実施形態を実装することができる例示的なコンピューティング環境の一例に関して説明する。次に、本発明の特定の一実装形態についての詳細な例を説明する。この特定の実装形態のある種の詳細に関しては、代替実装形態も含まれ得る。本発明の実施形態は、ここで説明する実施形態に限定されないことが理解されよう。

（本発明の例示的なコンピューティング環境）
図１に、本発明の例示的な実装形態で使用することができるコンピューティング装置を示す。図１を参照すると、本発明を実装するためのシステムの一例は、コンピューティング装置１００などのコンピューティング装置を含む。非常に基本的な構成では、コンピューティング装置１００は、典型的には、少なくとも１つの処理装置１０２とシステムメモリ１０４とを含む。コンピューティング装置の厳密な構成および種類に応じて、システムメモリ１０４は、（ＲＡＭなどの）揮発性のメモリでも、（ＲＯＭ、フラッシュメモリなどの）不揮発性メモリでも、あるいはこれら２つの何らかの組合せでもよい。システムメモリ１０４は、典型的には、オペレーティングシステム１０５、１または複数のプログラムモジュール１０６を含み、プログラムデータ１０７を含むこともできる。コンピューティング装置１００の基本構成は、破線１０８の内部の構成要素により図１に示される。

コンピューティング装置１００は、追加の特徴または機能を有することもできる。例えば、コンピューティング装置１００は、例えば、磁気ディスク、光ディスク、テープなど追加のデータ記憶装置（取り外し可能および／または取り外し不能）を含むこともできる。追加の記憶装置は、図１に、取り外し可能記憶装置１０９および取り外し不能記憶装置１１０によって示されている。コンピュータ記憶媒体は、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、他のデータなど、情報記憶の任意の方法および技術で実装される、揮発性および不揮発性、取り外し可能および取り外し不能の記憶媒体を含むことができる。システムメモリ１０４、取り外し可能記憶装置１０９、および取り外し不能記憶装置１１０は、コンピュータ記憶媒体のすべての例である。コンピュータ記憶媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（「ＤＶＤ」）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または所望の情報を記憶するために使用することができ、コンピューティング装置１００がアクセスすることができるその他任意の媒体を含む。コンピュータ記憶媒体のいずれも、装置１００の一部とすることができる。コンピューティング装置１００は、キーボード１２２、マウス１２３、ペン、音声入力装置、タッチ入力装置、スキャナなどの入力装置１１２を有することもできる。ディスプレイ、スピーカ、プリンタなどの出力装置１１４を含めることもできる。これらの装置は、当技術分野においてよく知られており、ここで長々と論ずる必要はない。

コンピューティング装置１００は、ネットワークを介してなど、装置が他のコンピューティング装置１１８と情報のやりとりをすることができるようにする通信接続１１６を含むこともできる。通信接続１１６は、通信媒体の一例である。通信媒体は、典型的には、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、または搬送波または他のトランスポート機構などの変調済みのデータ信号の形の他のデータによって実施することができ、任意の情報配信媒体を含む。用語「変調データ信号」は、信号中の情報を符号化するようにして、１または複数の信号の特徴を設定または変更した信号を意味する。例として、これに限定されないが、通信媒体は、有線ネットワークや直接配線接続などの有線媒体、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体を含む。本明細書中で使用される用語、コンピュータ読取り可能媒体は、記憶媒体も通信媒体も含んでいる。

（特定の実装形態の説明）
図２は、本発明の実施形態を実装することができるネットワーク環境を一般的に示す機能ブロック図である。図２に示すように、ネットワーク環境２００は、ネットワーク２１０上で接続されるクライアント２０３とサーバ２０１とを含む。サーバ２０１は、共有ボリューム２２０の一部分をクライアント２０３に使用可能にしている。当技術分野で知られているように、クライアント２０３のユーザは、ネットワーク２１０を介してサーバ２０１へと接続することができ、そのユーザが十分な特権をもつ場合には、共有ボリューム２２０上のファイルにアクセスすることができる。接続がなされると、共有ボリューム２２０は、クライアント２０３上に、共有ボリューム２２０上に記憶されるフォルダおよびファイルを表すディレクトリ構造２４０として現れる。図２は全体の共有ボリューム２２０をクライアント２０３から使用可能なものとして示していることを理解されたい。しかし、典型的には、共有ボリュームのほんのわずかの部分（例えば、サブディレクトリツリー）だけが、実際には「共有部」として使用可能にされ、１つの共有ボリュームは、典型的には、複数の共有部を有することが理解されよう。異なるクライアントおよびユーザは、同じ共有ボリューム上の異なる共有部にアクセスすることができる。しかし、説明を簡単にするためだけに、このドキュメントでは、１つの共有ボリューム２２０の文脈においてこのシステムを説明することにする。

クライアント２０３とサーバ２０１は、多数の異なる通信プロトコルのうちの１つを使用して情報をやりとりすることができる。分散ファイルシステム用に通常使用される１つの通信プロトコルは、ＮＦＳ（Network File System）プロトコルである。ＮＦＳプロトコルは、ネットワークにわたって共有ファイルおよびディレクトリへの透過的なリモートアクセスを提供する。ＮＦＳプロトコルは、異なるマシン、オペレーティングシステム、ネットワークアーキテクチャ、およびトランスポートプロトコルの間で移植可能なように設計されている。ＮＦＳプロトコルについてのより多くの情報は、公開されて入手可能なＲＦＣ３５３０に見出すことができる。

サーバ２０１は、ユーザが共有ボリューム２２０の以前の状態に戻れるようにするボリュームシャドウサービスを提供する。換言すれば、サーバ２０１は、定期的に、共有ボリューム２２０のイメージまたは「スナップショット」を取り込む。図２に示したように、第１のスナップショット２２１は、共有ボリューム２２０の現在の状態に先立つある時点における共有ボリューム２２０上のデータの状態を表す。同様に、第２のスナップショット２２２は、第１のスナップショット２２１が取り込まれた時に先立つある時点における共有ボリューム２２０上のデータの状態を表す。サーバ２０１は、かなり長い時間にわたって、共有ボリューム２２０の非常に多くのスナップショットを使用可能にすることができる。

クライアント２０３において、現在のディレクトリ構造２４０は、共有ボリューム２２０上に記憶されるデータの現在の状態を表す。さらに、クライアント２０３のユーザは、共有ボリューム２２０のスナップショットのうちのどれかにアクセスできる可能性がある。共有ボリューム２２０の各スナップショットを、サーバ２０１により、スナップショットに対応するデータを表す別々のディレクトリ構造としてクライアント２０３に開示する。従って、現在のディレクトリ構造２４０は、現在の共有ボリューム２２０に関連付けられ、ディレクトリ構造２４１は、第１のスナップショット２２１に関連付けられ、ディレクトリ構造２４２は、第２のスナップショット２２２に関連付けられ、ディレクトリ構造２４３は、第Ｎ番目のスナップショット２２３に関連付けられる。

上述したように、従来技術を使用して、共有ボリューム２２０の各スナップショット（例えば、第１のスナップショット２２１、第２のスナップショット２２２、Ｎ番目のスナップショット２２３）は、別々のボリュームとしてクライアント２０３でアクセスされる。換言すれば、第１のスナップショット２２１を見るためには、ユーザは、第１のスナップショット２２１に対応する新しいボリュームをクライアント上にマウントすることになる。ユーザが複数のスナップショットを見たいと思う場合には、複数の新しいボリュームをクライアント２０３上にマウントする必要がある。以上で説明したように、この技術は、一般に、名前空間の汚染をもたらし、ユーザにはこのスナップショットをマウントする高い特権が必要になる。

対照的に、本発明は、クライアント２０３において各スナップショットを別々のボリュームではなく共有ボリューム２２０の一部として表すことを可能にする。以下でさらに詳細に説明するように、サーバ２０１は、共有ボリューム２２０の各スナップショットに直接アクセスすることを可能とする現在のディレクトリ構造２４０に関連して、情報をクライアント２０３に提供する。このようにして、本発明は、追加のボリュームをマウントする高いユーザ特権が必要という既存の問題を克服している。さらに、本質的に異なる時点における同じデータの状態をそれぞれ表す、クライアント２０３の名前空間にマウントされる複数のボリュームを有することにより、ユーザが混乱させられることはなくなる。

図３は、共有ボリュームの１または複数のスナップショットに対する直接アクセスを提供するサーバによって、クライアント２０３から使用可能になる共有ボリュームに対応したディレクトリ構造２４０の図である。ディレクトリ構造２４０は、クライアント２０３から使用可能な共有ボリューム上に存在するファイルとフォルダのビューを表す。ディレクトリ構造２４０は、共有部のルートを表すルート３０１を有するツリー構造である。共有ボリューム２２０が、クライアント２０３にマウントされ、何らかのイベント（例えば、新しいスナップショットの追加または古いスナップショットの除去）に応答して、または何らかの定期的な間隔に基づいて動的に更新され得るときに、ディレクトリ構造２４０を、クライアント２０３に提供する。ファイル（例えば、ファイルＣおよびＦ）とフォルダ（例えば、フォルダＡおよびＤ）を含むルート３０１の下のディレクトリ構造２４０中に、いくつかの他のリソースが含まれる。このドキュメント中で使用しているように、リソース、ファイル、およびディレクトリへのアクセスの間では、何の区別も行うべきではないことに留意されたい。実際、これらのアクセスの種類の各々は、この説明の目的に限れば基本的には同じであると考えることができる。

本発明によれば、別のディレクトリ構造、例えばディレクトリ構造２４１は、現在のディレクトリ構造２４０のルート３０１の子ディレクトリ構造として存在する。子ディレクトリ構造２４１は、現在のディレクトリ構造２４０によって表わされる共有ボリュームのスナップショットに関連付けられたディレクトリ構造を表す。換言すれば、現在のディレクトリ構造２４０は、対応する共有ボリュームの現在の状態を表し、子ディレクトリ構造２４１は、対応する共有ボリュームの以前の状態を表す。

この特定の実施形態では、子ディレクトリ構造２４１は、ルート３０１の下にある隠れ状態（hidden state）で存在する。このようにして、クライアント２０３の名前空間を閲覧するユーザは、現在のディレクトリ構造２４０の要素を見ることになるが、デフォルトでは子ディレクトリ構造２４１を見ることができない。ユーザが共有ボリューム２２０のスナップショットを閲覧したいと思うならば、ユーザは、ルート３０１の下の隠れファイルを閲覧するオプションを選択することができ、それによって、スナップショットのディレクトリ構造２４１へのアクセス権を得ることができる。

この手続きは、新しいボリュームをマウントすることに関連付けられた特権など高い特権は必要ではなく、従って、一般のユーザ（例えば、ボリュームをマウントする特権をもたないユーザ）がスナップショットにアクセスすることを可能にする。さらに、ユーザが、共有ボリュームについての１または複数のスナップショットをマウントする場合には、ユーザは、クライアント２０３の名前空間に存在する基本的には同じ共有ボリュームの複数のバージョンがあることによって混乱させられることがなくなる。図３には子ディレクトリ構造２４１を１つしか示していないが、実際には、現在のディレクトリ構造２４０において、複数の子ディレクトリ構造は、共有ボリューム２２０の複数のスナップショットのそれぞれに対して１つずつの存在し得ることを理解されたい。

子ディレクトリ構造２４１へのアクセスには、ファイルシステムの一部として記憶される許可に基づいた通常のアクセス制御機構を使用する。特に、ユーザは、少なくとも読取りアクセス権を有するスナップショットの存在だけが見えるにすぎない。クライアント２０３が、スナップショットに関連付けられたリソースのうちのどれかを変更するのを防止するために、問題のファイルのユーザの所有権、アクセス権、または許可にかかわらず、読取り専用アクセスがサーバによって強要される。換言すれば、ユーザがスナップショット中のリソースを閲覧している場合、ユーザは、スナップショットが捕捉されたとき、リソースに割り当てられた特定のアクセス特権を検査することができることになるが、サーバは、それとは関係なしに、読取り専用特権を強要することになる。しかし、他の実装形態では、スナップショットへの何らかの追加のアクセスを可能にすることができる。例えば、他の実施形態では、通常のユーザには読取り専用アクセス権しかないが、特殊なグループのユーザには、スナップショットを変更する特定の特権が付与される。

この実施形態では、クライアントに開示する子ディレクトリ構造２４１の名前は、一般のツールがスナップショットボリュームを列挙するのを防止するように選択される。より詳細には、子ディレクトリ構造２４１の名前は、その対応するスナップショットの作成時間に基づくものとすることができる。一例では、図４に示すような名前を使用することができる。図４を簡単に参照すると、子ディレクトリ構造２４１のルート３０５の名前４１０についての一般的な命名規則が示されている。図に示すように、期間４２０を使用して、名前を開始して、エントリが親ディレクトリ構造２４０内に隠されるようにする。名前４１０の本体４３０は、対応するスナップショットの作成に関連付けられたＧＭＴ（Greenwich Mean Time）に基づくようにすることができる。命名規則に作成時間を組み込むことによって、各スナップショットを一意的に区別できるようにする。この命名規則は、使用することができる複数の異なる命名規則のうちの任意の一例として提供されている。この例は限定するものではなく、本発明の趣旨を逸脱することなく、多数の代替命名規則が、当業者には明らかなものとなろう。

また、スナップショットについてクライアントに提供される名前は、必ずしもサーバ上に長く残るものではなく、共有ボリューム上の実際のリソースを命名するためには使用されないことに留意されたい。むしろ、スナップショットに関連付けられた子ディレクトリ構造について使用される名前は、仮想ディレクトリだけに関連しており、実際の残されたリソースには関連していない。従って、共有ボリュームが、クライアントにおける共有部として以外の何らかの機構によって（例えば、ローカルファイルシステムアクセスを介して）検査される場合、クライアントにエクスポートされる名前は、必ずしも現れないはずである。

（子ディレクトリ構造をスナップショットとして識別すること）
図５および図６は、リソースをスナップショットとして識別するために、どのようにして本発明の一実施形態がリソースハンドル中のフラグを使用するかを示すものである。当技術分野において知られているように、一意的なファイルハンドルを使用して共有ボリューム上の各リソースをクライアント２０３により識別することができる。ファイルハンドルは、クライアント２０３がサーバ２０１上でファイルまたはディレクトリを参照するときに用いるトークンである。パスネーム変換要求（ルックアップ）がクライアント２０３からサーバ２０１に送られると、ファイルハンドルは、サーバ２０１によって作成される。サーバ２０１は、要求されたファイルまたはディレクトリを見出し、要求中のユーザがアクセス許可を得られるようにする。許可が与えられる場合には、サーバ２０１は、この要求されたファイルについてのファイルハンドルを作成し、このファイルハンドルをクライアント２０３に戻す。ファイルハンドルは、クライアント２０３による将来のアクセス要求中において、このファイルを識別する。クライアント２０３は、クライアント２０３がアクセスしている各ファイルごとにファイルハンドルを記憶するボリュームハンドルテーブルを保持する。

異なるネットワークシステムで使用されるファイルハンドルの構造は、異なるものにすることができる。図５は、本発明の一実装形態中で使用される１つのファイルハンドル５１０の一例を示している。ファイルハンドル５１０の例は、ボリュームＩＤおよびマウントＩＤを含み、これらが一緒に要求されたファイルが存在するボリュームの特定の化身（incarnation）を識別する。ファイルハンドル５１０は、共有ボリュームのルートリソースを識別する共有ＩＤと、どの特定のファイルがファイルハンドル５１０によって参照されるかを識別するファイルＩＤ５１１を含む。

さらに、この説明中で使用される例、ファイルハンドル５１０は、参照ファイルが現在のボリューム上ではなくてスナップショット上に存在することを示すフラグフィールド５１４を含む。換言すれば、スナップショットに関連付けられたディレクトリ構造は、現在の共有部上のリソースとして存在するので、参照中のファイルが現在のファイルであるか、それともスナップショット上に存在するファイルのバージョンであるかを識別する際に、あいまいになる可能性がある。従って、フラグフィールド５１４は、要求されたファイルがスナップショット上に存在し、ファイルハンドル５１０中の共有ＩＤ５１２がスナップショット共有部を指すことを示すファイルハンドル５１０中に含まれる。さらに、スナップショットフラグは、サーバ２０１に、そのファイルに対してどのような変更特権を示すことでもできるのにもかかわらず、ファイルハンドル５１０が参照するリソースを変更することができないことを通知する。

図６は、本発明に従って、どのようにスナップショット上のリソースをアクセスすることができるかを一般的に示した機能フロー図である。フロー図は、事象の生起、ならびにサーバ２０１とクライアント２０３の間を移動するメッセージの方向を示している。この矢印は、メッセージが移動する方向、すなわちクライアント２０３からサーバ２０１への方向、またはその逆の方向を示す。

最初にメッセージ６０５において、クライアント２０３は、特定の共有ボリュームをマウントする要求をサーバ２０１に発行する。メッセージ６０７において、サーバ２０１は、ファイルハンドルを要求された共有部のルートへと戻すことによって応答する。このポイントにおいて、クライアント２０３は、共有ボリューム内のファイルへのアクセスを要求することができる。ユーザが共有ボリュームのスナップショットへのアクセスをしたいと思う場合には、メッセージ６０９において、クライアント２０３は、共有ボリュームのルートの下に記憶されるファイルに対するファイルハンドルを求める要求を発行する。そのために、クライアント２０３は、要求されたリソース（この例におけるスナップショット）についてのルートハンドルに加えて識別子をサーバ２０１に渡す。これに応答して、メッセージ６１１において、サーバ２０１は、ハンドルをこのスナップショットに戻す。上述したように、スナップショットへのハンドルは、ハンドルがスナップショットに関連付けられることを示すフラグビットを含むことができる。最終的に、クライアントは、メッセージ６１３において、そのファイル（「任意のファイル」）へのファイルハンドルを求める要求を発行することにより、スナップショット上の任意のファイルにアクセスすることができる。サーバ２０１は、メッセージ６１５において、適切に設定されたスナップショットフラグビットを有する要求されたファイルにファイルハンドルを戻すことによって応答する。

このようにして、共有ボリュームへのアクセス権を持つクライアントコンピュータは、クライアントコンピュータ上に新しいボリュームをマウントする必要なしに、共有ボリュームの任意のスナップショットに直接にアクセスすることができる。この利点により、しばしばスナップショットへのアクセスを不便なものにしていた、以前は必要だった高いアクセス特権の必要性がなくなる。さらに、本発明の機構を用いたスナップショットへのアクセスには、既存のネットワークファイルアクセスプロトコルに対する変更の必要がなく、スナップショットへのアクセスの実装が非常に簡単になる。

以上の明細書、例、およびデータは、本発明の概念および実装形態の例の十分な説明を提供している。本発明の趣旨および範囲を逸脱することなく本発明の多数の実施形態を作成することができるので、本発明は、添付の特許請求の範囲に帰するものである。

本発明の実装形態において使用することができるコンピューティング装置を示す機能ブロック図である。 本発明の実施形態を実装することができるネットワーク環境を一般的に示す機能ブロック図である。 共有ボリュームの１または複数のスナップショットへの直接アクセスを提供するサーバによりクライアントを使用可能にする共有ボリュームに対応するディレクトリ構造を示す図である。 図３に示した子ディレクトリ構造のルートの名前の一般的な命名規則を示す図である。 スナップショットがアクセス中であることを示すスナップショットフラグフィールドを含む分散ファイルシステム上でファイルにアクセスするために使用されるファイルハンドルの図である。 本発明にかかるスナップショット上のリソースにどのようにアクセスするかを一般的に示す機能フロー図である。

符号の説明

１０４ システムメモリ
１０５ オペレーティングシステム
１０６ プログラムモジュール
１０７ プログラムデータ
１０９ 取り外し可能記憶装置
１１０ 取り外し不能記憶装置
１１２ 入力装置
１１４ 出力装置
１１６ 通信接続
１１８ 他の計算機装置
１２２ キーボード
１２３ マウス

Claims (22)

1. コンピュータ実行可能なコンポーネントを有するコンピュータ読取り可能媒体であって、
   サーバコンピュータ上に常駐する共有ボリュームを開示するように構成された分散ファイルシステムサーバコンポーネントを備え、前記共有ボリュームは、ルートおよびボリュームシャドウコピーを有し、前記分散ファイルシステムサーバコンポーネントは、前記ボリュームシャドウコピーを識別するボリュームシャドウコピーリソースを含む前記共有ボリュームの前記ルートの下にあるリソースのリスト化を要求中のクライアントに戻すようにさらに構成され、前記ボリュームシャドウコピーリソースは、前記ボリュームシャドウコピーへのアクセス権を前記要求中のクライアントに提供するように動作することを特徴とするコンピュータ読取り可能媒体。
2. 前記リソースのリスト化は、ディレクトリツリー構造を含むことを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
3. 前記サーバコンピュータと前記クライアントは、前記ネットワークファイルシステムプロトコルを使用して通信するように構成されていることを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
4. 前記ボリュームシャドウコピーリソースは、前記共有ボリュームの前記ルートの下にあるエントリを含むことを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
5. 前記エントリは、デフォルトで隠されていることを特徴とする請求項４に記載のコンピュータ読取り可能媒体。
6. 前記エントリは、前記ボリュームシャドウコピーを前記共有ボリュームの他のボリュームシャドウコピーと一意的に区別する名前を含むことを特徴とする請求項４に記載のコンピュータ読取り可能媒体。
7. 前記名前は、前記ボリュームシャドウコピーの作成時間に基づいていることを特徴とする請求項６に記載のコンピュータ読取り可能媒体。
8. 前記名前は、仮想の名前であることを特徴とする請求項６に記載のコンピュータ読取り可能媒体。
9. 前記要求中のクライアントは、高いアクセス特権を使用せずに前記ボリュームシャドウコピーへのアクセス権が提供されることを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
10. 前記要求中のクライアントは、前記要求中のクライアントに追加のボリュームをマウントせずに前記ボリュームシャドウコピーへのアクセス権が提供されることを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
11. 前記ボリュームシャドウコピーリソースへのアクセスは、前記共有ボリュームに関連付けられ記憶される許可に基づくアクセス制御機構を使用することを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
12. 前記ボリュームシャドウコピーへのアクセスは、読取り専用ベースで提供されることを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
13. 前記ボリュームシャドウコピーへのアクセスは、読取り／書込みベースで提供されることを特徴とする請求項１に記載のコンピュータ読取り可能媒体。
14. データ構造で符号化されるコンピュータ読取り可能媒体であって、
    ルートエントリを有し、共有ボリュームを表す第１のディレクトリ構造と、
    前記第１のディレクトリ構造に関連付けられた第２のディレクトリ構造であって、前記第２のディレクトリ構造は、前記共有ボリュームのボリュームシャドウコピーを表し、前記第１のディレクトリ構造の前記ルートエントリの下にある子エントリを介してアクセス可能である第２のディレクトリ構造と
    を備えたことを特徴とするコンピュータ読取り可能媒体。
15. 前記第１のディレクトリ構造および前記第２のディレクトリ構造は、サーバコンピュータ上で維持され、ネットワーク上で要求中のクライアントコンピュータに提供されることを特徴とする請求項１４に記載のコンピュータ読取り可能媒体。
16. 前記サーバコンピュータと前記要求中のクライアントコンピュータは、前記ネットワークファイルシステムプロトコルを使用して通信することを特徴とする請求項１５に記載のコンピュータ読取り可能媒体。
17. 前記子エントリは、前記ボリュームシャドウコピーの作成時間に基づく名前を含むことを特徴とする請求項１４に記載のコンピュータ読取り可能媒体。
18. 前記名前は、デフォルトで前記第１のディレクトリ構造中の隠れエントリであることを特徴とする請求項１７に記載のコンピュータ読取り可能媒体。
19. データ構造で符号化されるコンピュータ読取り可能媒体であって、
    分散ファイルシステム上でファイルにアクセスするためのファイルハンドルであって、前記ファイルハンドルは、前記ファイルハンドルに関連付けられたファイルが共有ボリュームのボリュームシャドウコピー中に存在することを示すボリュームシャドウコピーフラグビットを含むファイルハンドルを
    備えたことを特徴とするコンピュータ読取り可能媒体。
20. 分散ファイルシステム上でファイルにアクセスするためのコンピュータ実装方法であって、
    要求中のクライアントから共有ボリュームをマウントする要求を受け取ること、
    前記共有ボリュームのルートに関連付けられた第１のファイルハンドルを前記要求中のクライアントに戻すこと、
    前記共有ボリュームのボリュームシャドウコピーを表す、前記ルートの子エントリに関連付けられた別のファイルハンドルを求める要求を受け取ること、および、
    前記ボリュームシャドウコピーの前記ルートに関連付けられた第２のファイルハンドルを前記要求中のクライアントに戻すこと
    を備えたことを特徴とするコンピュータ実装方法。
21. 前記ボリュームシャドウコピーの前記ルートに関連付けられた前記ファイルハンドルを戻すことは、前記第２のファイルハンドルが前記ボリュームシャドウコピーに関連付けられたことを示すように設定されるボリュームシャドウコピーフラグビットを有するボリュームシャドウコピーファイルハンドルを生成することをさらに含むことを特徴とする請求項２０に記載のコンピュータ実装方法。
22. 前記要求中のクライアントに関連付けられたアクセス許可を評価して、前記要求中のクライアントが前記ボリュームシャドウコピーにアクセスする許可を有するかどうかを判定することをさらに含むことを特徴とする請求項２０に記載のコンピュータ実装方法。
    

Images