(57)【要約】本発明は、包括的なデータ保護を提供するコンピュータ第一次データ格納システムおよび方法に関連する。装置は、２つ以上のデータセンター（１）間で動作するように設計されている。これらのデータセンターわたり配置される２つ以上のレポジトリ（３）は、格納容量と、第１次格納システムを提供するそれらの関連したファイルサーバ（４）に対する完全なデータ保護を供給するデータ管理処理能力を提供する。本発明により、ファイルサーバを有するデータ保護システムもまた提供される。
2005538469.tif 000002
【特許請求の範囲】
【請求項１】
ファイルのセットを転送する方法であって、
目的ファイルサーバでファイルの該セットに関連したメタデータと、スタブファイルとを受け取ることと、
該目的ファイルサーバにおけるロケーションコンポーネントをアップデータすることによって、ファイルの該セットにおける各ファイルに関連したレポジトリノードのリストを維持することと、
各スタブファイルを該スタブファイルに関連した該ファイルの満杯の内容と置換することと、
各スタブファイルを置換する一方で、ファイルの該セットにおける特定されたファイルに対するクライアント要求を受け取ると、該特定されたファイルの該満杯の内容が依然転送されていないとき、該特定されたファイルに対する該スタブファイルを該特定されたファイルの満杯の内容と置換することと
を包含し、
該特定されたファイルに対する該スタブファイルを置換することは、要求されていないファイルに対する該スタブファイルを置換することより優先度が高いタスクである、方法。
【請求項２】
前記メタデータは、レポジトリノードから目的ファイルサーバで受け取られる、請求項１に記載の方法。
【請求項３】
前記方法は、メタデータを受け取る前に、目的ファイルサーバ選択データを受け取ることをさらに包含する、請求項１に記載の方法。
【請求項４】
前記方法は、メタデータを受け取る前に、ソースシェア選択データを受け取ることをさらに包含する、請求項１に記載の方法。
【請求項５】
ファイルの前記セットは、特定された期間中にアクセスされたファイルの該セットであり、各スタブファイルを置換することは、ファイルの該セットにおけるすべての該スタブファイルが置換されるまで、最近最も多くアクセスされた該ファイルに関連した該スタブファイルを再帰的に置換することを包含する、請求項１に記載の方法。
【請求項６】
前記特定された期間は、最も最近の期間である、請求項５に記載の方法。
【請求項７】
前記ロケーションコンポーネントは、ロケーションキャッシュである、請求項１に記載の方法。
【請求項８】
ファイルサーバを有するデータ保護システムであって、
該ファイルサーバは、
クライアントファイルを格納するように動作可能なファイルシステムと、
レポジトリと通信するように動作可能なファイルサーバＡＰＩと、
該ファイルシステムと通信しているファイルサーバファイル転送モジュールであって、少なくとも１つのレポジトリから該ファイルシステムに対するファイルを受け取るように動作可能なファイルサーバファイル転送モジュールと、
該ファイルサーバＡＰＩおよび該ファイルシステムと通信している回復サービスであって、ファイルのセットを転送するように動作可能な回復サービスと
を備え、
該回復サービスは、
該ファイルサーバでファイルの該セットに関連したメタデータと、スタブファイルとを受け取るように動作可能な受け取りコンポーネントと、
該受け取りコンポーネントと通信しているロケーションアップデートコンポーネントであって、ファイルの該セットにおける各ファイルに関連したレポジトリノードのリストを維持するように動作可能なロケーションアップデートコンポーネントと、
該受け取りコンポーネントと通信しているスタブファイル置換コンポーネントであって、各スタブファイルを該スタブファイルに関連した該ファイルの満杯の内容と置換するように動作可能なスタブファイル置換コンポーネントと
を備えた、データ保護システム。
【請求項９】
前記システムは、
クライアントファイル要求によって開始された入力／出力アクティビティをインターセプトし、かつ、先のバックアップから修正されたファイルおよび作成されたファイルのリストを維持するように動作可能なフィルタドライバと、
シェアに関連した保護ポリシーを格納する動作可能なポリシーキャッシュと
該ファイルドライバおよび該ポリシーキャッシュと通信しているミラーサービスと
をさらに備え、
該ミラーサービスは、シェアに関連した該保護ポリシーに特定されるように、レポジトリに書き込まれるべき該シェアにおいて修正されたファイルおよび作成されたファイルを準備するように動作可能である、請求項８に記載のシステム。
【請求項１０】
前記システムは、
前記ミラーサービスと通信しているロケーションキャッシュであって、どのレポジトリが現存のファイルのアップデートされたバージョンを受け取るべきかを示すように動作可能なロケーションキャッシュと、
該ロケーションキャッシュに結合されたロケーションマネージャであって、該システムが、新しいファイルを特定のレポジトリノードに書き込むとき、該ロケーションキャッシュをアップデートするように動作可能なロケーションマネージャと
をさらに備えた、請求項９に記載のシステム。
【請求項１１】
前記システムは、ローカルレポジトリをさらに有し、
該レポジトリは、
前記ファイルサーバＡＰＩと通信するように適合されたローカルレポジトリノードＡＰＩと、
前記ファイルサーバファイル転送モジュールと通信しているローカルレポジトリファイル転送モジュールであって、ファイルを前記ファイルサーバファイル転送モジュールに転送するように適合されたローカルレポジトリファイル転送モジュールと、
該ローカルレポジトリＡＰＩと通信しているデータムーバであって、該ローカルレポジトリから該ファイルサーバへのファイルの複製を統括するように動作可能なデータムーバと
を有する、請求項８に記載のシステム。
【請求項１２】
前記ファイルサーバＡＰＩは、ネットワークと通信するように動作可能であり、前記システムは、
該ネットワークと通信するように適合されたリモートレポジトリノードＡＰＩと、
前記ローカルファイル転送モジュールと通信しているリモートレポジトリファイル転送モジュールであって、ファイルを前記ファイルサーバファイル転送モジュールに転送するように適合されたリモートレポジトリファイル転送モジュールと、
該リモートレポジトリＡＰＩと通信しているデータムーバであって、該リモートリポジトリから該ファイルサーバへのファイルの複製を統括するように動作可能なるデータムーバと
を有するリモートレポジトリをさらに備えた、請求項１１に記載のシステム。
【請求項１３】
データを格納する方法であって、
クライアントファイルを格納するように動作可能なファイルシステムと、
ファイルのセットに関連した保護ポリシーを格納するように動作可能なポリシーコンポーネントと、
前記ポリシーキャッシュと通信しているミラーサービスであって、ファイルのセットに関連した該保護ポリシーに特定されるようにレポジトリに書き込まれるべきファイルの該セットにおいて修正されたファイルおよび作成されたファイルを準備するように動作可能なミラーサービスと、
該ミラーサービスに結合されたファイルサーバＡＰＩであって、レポジトリと通信するように動作可能なファイルサーバＡＰＩと、
該ファイルシステムと通信しているファイルサーバファイル転送モジュールと
を提供するファイルサーバを包含し、
該ファイルサーバファイル転送モジュールは、該ファイルシステムから少なくとも１つのレポジトリにファイルを転送するように動作可能であり、
該ポリシーコンポーネントに格納されているようにキャッシュレベルを決定し、
該ファイルサーバ上の利用率を再帰的に決定し、
該利用率に対して該キャッシュレベルを比較し、
該利用率が該キャッシュレベルを超えるとき、
ファイル移送候補リストを作成し、
１つの候補ファイルをステージアウトし、
該候補ファイルをスタブファイルと置換し、
該ファイルサーバの該利用率が該キャッシュレベルを依然超えるかどうかを決定する、方法。
【請求項１４】
前記ファイルサーバの前記利用率が前記キャッシュレベルを依然超えるかどうかを決定することは、該利用率が該キャッシュレベルを超えることを示し、前記候補リスト上の他の候補リストをステージアウトし、該ファイルサーバの該利用率が該キャッシュレベルを超えるかどうかをもう一度決定する、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的なデータ保護を提供するコンピュータ一次データ格納システムおよび方法に関する。
【背景技術】
【０００２】
本発明の背景として、階層型格納管理（ＨＳＭ；ｈｅｒａｒｃｈｉｃａｌ  ｓｔｏｒａｇｅ  ｍａｎａｇｅｍｅｎｔ）は、磁気ディスクドライブ、磁気テープドライブ、光ディスクドライブといった複数タイプのデータ格納技術とともに配備されるデータ管理技術である。ＨＳＭは、クライアントアプリケーションによって最近最も少なくアクセスされたファイルの内容を、より高速な、よりコストのかかる磁気ディスク技術から、磁気テープおよび光ディスクといったよりコストのかからない、より低速な媒体にユーザが気付くことなく移動させるために用いられてきた。これらのさまざまな格納技術は、最高速から最低速および／または最高コストから最低コストの複数レベルの階層で配置され得る。以下の例に対して、ＨＳＭ階層内において、磁気ディスクは、高速で、より高価な一次格納デバイスとして利用され、磁気テープは、より廉価で、より低速なアクセス格納技術として利用されると仮定する。ＨＳＭが動作中であり、クアイアントアプリケーションによって最近最も多くアクセスされたファイルは、完全な形で、磁気ディスク上に維持され、最近最も少なくアクセスされたファイルは、磁気テープに移送される。ＨＳＭソフトウェアは、クライアントアプリケーションが、磁気テープに移送されたファイルにユーザが気付くことなくアクセスすることを可能にする。最近最も少なく使用されたファイルが、磁気テープに移送されたとき、よりはるかに小さいスタブファイルが、一般的に１ＫＢから４ＫＢの容量である磁気ディスク上にとどまる。このスタブファイルは、すべての基本的なオペレーティングシステムのファイル情報、およびこのファイルが磁気ディクから他の媒体へ移送されたことを示すインディケーションを含む。情報がクライアントアプリケーションによって要求されたとき、このスタブファイルはまた、ＨＳＭが、磁気ディスクからファイルのすべての内容を獲得し、ファイル完全なる内容をユーザが気付くことなく磁気ディスクに再格納するため用いる情報を含む。
【０００３】
このようにして、ＨＳＭは、費用効率の良い態様で、多くの量のまれにアクセスされるデータの管理する効果的な方法であり得る。ＨＳＭはまた、アドミニストレイティブアラートおよびその後に続く追加的なクライアントデータに対する利用可能な容量がなくなったファイルシステムに関連する操作上の動作を排除することにおいて効果的である。ＨＳＭを用いないとき、ファイルシステムは、利用可能な容量がなくなったとき、格納アドミニストレータは、以下のマニュアルデータ管理技術のうちの１つを瞬時に利用して、クライアントアプリケーションが動作可能であり続けることを可能にする。
【０００４】
・サードパーティのアーカイビングプログラムを用いて、所望されないファイルを識別し、これらを磁気テープもしくは光テープに収容する。アーカイビングは、ファイルサーバのファイルシステムからすべての情報を削除し、アプリケーションは、アーカイブテープもしくはアーカイブ光ディスクからこれらのファイルが回復されることなく、これらのファイルにアクセスできない。
【０００５】
・ファイルサーバが、追加的な磁気ディスクドライブを収容し続けるとき、これらは、サーバに加えられ、関連したボリュームとファイルシステムが拡張される。これは、時間のかかる処理であり、クライアントアプリケーションのダウン時間を招き得る。
【０００６】
・ファイルサーバが、そのファイルサーバのディクス格納容量の限界まで拡張されるとき、アドミニストレータは、いくつかのデータのシェア（格納容量のディレクトリまたはフォルダであるシェア）を利用可能な容量を有する他のサーバに移送させなければならない。
【０００７】
これをＨＳＭベースのファイルサーバと対照させると、ファイルシステムが満杯になるとき、最近最も少なく使用されたデータは、テープのような他の格納媒体に自動的に移送される。アーカイビングとは異なり、たとえクライアントアプリケーションのファイルが磁気テープに移送されても、ＨＳＭは、クライアントアプリケーションにそれらのファイルへのユーザが気付くことのない連続的なアクセスを提供する。追加的な磁気ディスク格納を、ＨＳＭをサポートするファイルサーバに加える必要はない。なぜなら、格納は、より多くの磁気テープを格納階層においてより低いレベルに加えることによって拡張されるからである。最後に、１つのサーバから他のサーバにシェアを移送することは、複数のファイルサーバにわたり容量の平衡させる理由のために特に実行される必要はない。
【０００８】
米国特許第５，５３７，５８５号（特許文献１）において、Ｂｌｉｃｋｅｎｓｔａｆｆ氏らは、最近最も少なく使用されたデータをファイルサーバから、より低コストのバックエンドリムーバブル格納システムに移送するＨＳＭを記載する。ＨＳＭサーバは、ファイルシステム容量利用率に対してモニタされ、ファイルが満杯になるとき、最近最も少なく使用されたファイルは識別され、バックエンド格納に移送される。
【０００９】
米国特許第５，２７６，８６０号（特許文献２）は、光ディスクおよび磁気ディスクのようなリムーバブル格納媒体を用いて、ＨＳＭおよびバックアップ技術をともに利用するシステムを記載する。光ディスクにステージアウトされるデータは、バックアップされていると考えられるので、ＨＳＭは、バックアップに収容されなければならないデータの量を減少させる手段として用いられる。しかし、適宜な、かつ、コスト効率の良い障害回復および／またはデータ移送を提供するデーア保護システムに対するニーズが残ったままである。
【特許文献１】米国特許第５，５３７，５８５号明細書
【特許文献２】米国特許第５，２７６，８６０号明細書
【発明の開示】
【課題を解決するための手段】
【００１０】
（発明の要旨）
本発明は、包括的なデータ保護を提供するコンピュータ一次データ格納システムおよび方法に関連する。本発明に従ったデータ保護システムの実施例は、システムは定期的にデータをバックアップし、システムがデータを移送しなければならないとき、システムは、移送候補として既にバックアップされたファイルを選択する点において特許文献２に対して逆に働く。ファイルシステムが満杯になるとき、移送候補は、より小さいスタブファイルによって瞬時に、かつ、効率的に置換される。
【００１１】
本発明は、階層格納管理が完了するのに数時間または数日、従来的にかかり得た障害回復オペレーションを完了する時間を速めるデータ管理システムおよび方法を提供する。一方でこれらのオペレーションが起こっており、クライアントアプリケーションは、それらのファイルにアクセスし得ないので、回復時間的要因が関連する。
【００１２】
本発明の実施形態は、階層格納管理が完了するのに数時間または数日、従来的にかかり得た障害回復オペレーションを完了する時間を速めるデータ管理シナリオを提供する。一方でこれらのオペレーションが起こっており、クライアントアプリケーションは、それらのファイルにアクセスし得ないので、回復時間的要因が関連する。
【００１３】
１.  データの１つ以上のシェアを１つのファイルサーバから他のファイルサーバに移動させる。ＨＳＭベースのファイルサーバが、それらのファイルシステムが満杯でないので、これは実行されるべきと要求しなくても、格納アドミニストレータは、このアクティビティを実行して、より多くのファイルサーバにわたりクライアントアプリケーションの負荷を拡散させる。
【００１４】
２.  ＮＡＳファイルサーバのすべての内容を他のファイルサーバに移動させる。アドミニストレータは、以下の状況においてこのサービスを実行する。
・パフォーマンス負荷平衡。
・ファイルサーバの消失。
・ファイルサーバハードウェアおよびオペレーティングシステムアップグレード。
・サイト障害回復  ―  ファイルサーバに値するすべてのサイトの消失。
【発明を実施するための最良の形態】
【００１５】
図１は、本発明に従った一体化一次データ格納およびデータ保護システムの実施形態を示す図である。ファイルサーバ４は、ネットワークファイルシステム（ＮＦＳ）、共通インターネットファイルシステム（ＣＩＦＳ）、ファイル転送プロトコル（ＦＴＰ）のような標準のネットワーク接続ストレージ（ＮＡＳ）プロトコルを介して一次データ格納容量をクライアントシステム５に提供する。その装置は、２つ以上のデータセンター１の間で動作するように設計されている。こられのデータセンターにわたり配置される２つ以上のレポジトリ３は、格納容量およびデータ管理処理能力を提供して、それらの関連したファイルサーバ一次格納システムに対して完全なデータ保護を実現する。その装置は、メトロポリタンまたはワイドエリアインターネットプロトコル（ＩＰ）ネットワーキング２を利用して、レポジトリが、複製のためのデータを送受信することを可能にする。データが、最初のファイルサーバからローカルおよび少なくとも１つリモートレポジトリに複製されることにより、これらのレポジトリは、従来のオンサイトとオフサイトのテープ格納システムおよびテープボールトサービスの代わりとして働く。１つの実施形態に従って、サイト障害の場合、失われたすべてのファイルサーバは、生き残ったサイトで新しいファイルサーバを用い、生き残ったレポジトリにおける内容から故障したファイルサーバの内容を再生させることによって回復される。
【００１６】
図２は、データセンターにわたり配置されるファイルサーバ６と２つのレポジトリ８との関連を示す図である。すべての一次データ格納アクティビティは、ＮＡＳシェア７を介して、１つ以上のクライアントと１つ以上のファイルサーバとの間で起こる。ファイルサーバは、多くのシェアを有するように一般的に構成されている。これらのシェアは、ファイルサーバの一次格納容量がシェアされ、複数のクライアントシステムの間で安全にパーティションされることを可能にする。
【００１７】
シェアは、格納容量のディレクトリまたはフォルダとしてファイルサーバ上に作成される。このシェアされるディレクトリまたはフォルダの内容は、ローカルエリアネットにわたる複数のクライアントによってアクセス可能である。例えば、マイクロソフトウインドウズの環境において、ＣＩＦＳシェアは、ウインドズエクスプローラユーザインターフェースの「Ｍｙ  Ｎｅｔｗｏｒｋ  Ｐｌａｃｅｓ」下にＬＡＮ接続されたサーバ内に格納フォルダとして現れる。ＵＮＩＸ（登録商標）の環境に対して、シェアは、データが格納されている実際のサーバとフォルダ、およびローカルクライアントシステムのファイルシステムの一部として現れる仮想フォルダを定義するマウントポイントを介してアクセスされる。
【００１８】
本発明に従ったシステムの１つの実施形態は、一次データ格納システムおよびデータ保護システムの両方であるので、格納アドミニストレータは、そのシェアに対する一意の保護ポリシー９の作成を介してどのようにシステムが、２つ以上のレポジトリにわたるファイルサーバの各シェアを保護するかを定義する。１つの実施形態において、この保護ポリシーは、システムが、各シェアのデータを保護するために用いるレポジトリを定義する。１つの実施形態において、それはまた、どのくらいの頻度でデータ保護が起こるか、どれくらいの複製が、シェアのデータの重要度に基づいて各レポジトリ内で維持されるか、およびデータをシェアするためにどのようにアップデートおよび変更が維持されるべきかを定義する。定期的に、各ファイルサーバは、そのシェアに対する保護ポリシーを検査し、また適切なとき、ファイルサーバは、シェアのファイルの最近のすべての変更をキャプチャし、２つ以上のレポジトリ内でこられのファイルを格納／保護する。
【００１９】
図３は、クライアントデータに関連したメタデータと同様にクライアントデータは、複数のレポジトリ間で保護されることを示す。複製されたレポジトリにおいてこのメタデータを維持することによって、ファイルサーバおよび／またはそのシェアは、他のファイルサーバに容易に移送され得る。１つの実施形態において、ファイルに対するメタデータは、以下の情報を含む。
・ファイルが作成される場所のファイルサーバネーム。
・ファイルのサイズ。
・このファイルの複製を維持するすべてのリポジトリノードのリスト。
・ファイルが最初に作成されるとき、または最後に修正されたとき、そのファイルの計算されたＭＤ５内容のチェックサム。
【００２０】
メタデータファイルは、レポジトリノード内で維持され、ファイルサーバ上にキャッシュされ、複数のレポジトリノードにわたるこれらファイルの保護を維持することを補助する。
【００２１】
ＨＳＭスタブファイルは、対照的に、ファイルの物理的なロケーションに関わらず、一般的にファイルサーバ上にだけ含まれ、クライアントアプリケーションへのファイルアクセスをユーザが気付くことなく提供するのにファイルサーバのＨＳＭソフトウェアを補助するために用いられる。
【００２２】
図４は、サーバ回復を表す。ファイルサーバＹ１４は、２つのレポジトリ内で定期的に保護される、そのクライアントデータおよびメタデータを有する。ハードウェア故障またはサイトの消失のため、ファイルサーバＹは利用不可能になるとき、最後のバックアップ期間から重複して複製されたファイルサーバの構成およびファイルメタデータは、Ｚ１５として示される、生き残ったファイルサーバもしくは新しいファイルサーバのいずれかに供給される。
【００２３】
本発明の実施形態を用いて、サーバ回復に対する格納アドミニストレータによって実行される動作は、データのシェアが、１つのオペレーショナルファイルサーバから他のオペレーショナルファイルサーバに移送されるときに実行される動作と同様である。シェア移送は、クライアントによって作成される負荷を現存の十分に利用されていない、またはより強力なサーバに、もしくは新しいファイルサーバにシフトさせることによって、非常にアクセスされるファイルサーバ上の１つ以上のシェアに対するクライアントアプリケーションの性能を向上させるために一般的に実行される。例えば、クライアントアプリケーションが異なるオフィスまたはデータセンターに物理的に再配置され、メトロポリタンまたはワイドエリアネットワークにわたる同じファイルサーバにアクセスする代わりにデータのそれらのシェアへの引き続き高性能ＬＡＮアクセスを予想するとき、シェア移送はまた、実行され得る。この場合、以前の施設からのすべてのシェアデータが、新しいロケーションの１つ以上のサーバに瞬時に移送され得る。
【００２４】
図５、６は、１つ以上のファイルサーバシェアが、１つのファイルサーバから他のファイルサーバに移送されるとき起こるアクティビティを示す図のタイムシーケンスのペアを表す。このシナリオにおいて、ファイルサーバＹの故障はないが、格納アドミニストレータが、ＹａおよびＹｂをファイルサーバＺと呼ばれる新しいサーバに移送することを所望する。
【００２５】
図５において、ファイルサーバＹ１６は、Ｙａ、ＹｂおよびＹｃと呼ばれる３つのシェアを有する。１つの実施形態において、これら３つのシェアに関連したすべてのメタデータは、図中において、Ｙ  メタデータ１７、１８として２つのレポジトリに複製される。
【００２６】
図６において、格納アドミニストレータは、ファイルサーバＹからファイルサーバＺ１９にシェアＹａおよびＹｂを移送することを決定する。以下の処理手順はシステムアドミニストレータによって実行される。
【００２７】
・移送中、クライアントのファイルがアクセスされ得ない時間があることをクライアントに通知する。
【００２８】
・本発明の管理アプリケーションインターフェースを用いてシェア移送を開始して、ファイルサーバＹからファイルサーバＺ１９にシェアＹａおよびＹｂの移送を開始する。
【００２９】
・これら２つのシェアに関連したすべてのメタデータは、図中において、Ｚ  メタデータ２０、２１として２つのレポジトリに複製される。
【００３０】
・管理インターフェース移送が完了した報告するとき、クライアントアプリケーションは、現在ファイルサーバＺ上に位置するそれらのファイルに再び関連付けられる。このシェア移送は、従来の移送に関連して瞬時に起こる。なぜなら、よりはるかに小さい４ＫＢスタブファイルは、クライアントがクライアントのファイルに再びアクセスすること可能にするためにファイルサーバ上に存在する必要があるからである。
【００３１】
・クライアント要求が、ファイルサーバ上にスタブファイルとして表されるだけであるデータに対してされるので、スタブファイルは、「ステージイン」処理を介して、ユーザが気付くことなくファイルすべての内容と置換される。言い換えれば、ファイルをステージインすることは、スタブファイルをファイルのすべての内容と置換することを伴う。ステージインされるべきデータは、従来の磁気テープまたは光ディスクの代わりに、ネットワーク化されたレポジトリノードの磁気ディスクドライブから送信されるので、ステージインするための時間は、適度な大きさのファイル（１０〜５０ＭＢ）に対して一般的に何十秒または何分から１秒未満に減少する。
【００３２】
・バックグランドタスクとして、図９に示される回復サービス４５はまた、シェア移送が要求される前に、ファイルサーバＹ上に完全な形で存在していたすべてのファイルを有するファイルサーバＺを再居住させる。
【００３３】
・最後に、ファイルサーバＹからクライアントアプリケーションによってもはや参照されないので、ファイルサーバＹからファイルサーバＺに移送されたそのシェアもしくは複数のシェアは、ファイルサーバＹから削除される。
【００３４】
図７は、１つのファイルサーバから他のファイルサーバにシェアのファイル移送を開始するために用いられるユーザインターフェースの１つの実施形態を示す。示されるスクリーンショットは、単一のファイルサーバＧＰＮＥＯＮ２３上に存在する２つのシェア２２、テスト１および２を示す。この例において、格納アドミニストレータは、ＧＰＮＥＯＮファイルサーバからＧＰＸＥＯＮ２４ファイルサーバにＴＥＳＴ１と呼ばれるシェアを移送するために最近選択した。ユーザインターフェースのステータスカラムは、ＴＥＳＴ１シェアは、現在移送状態２５であることを示す。ユーザインターフェースのステータスカラムはまた、ＧＰＮＥＯＮファイルサーバ上のシェアＴＥＳＴ２はオンラインであり、所望されるとき、他のファイルサーバに移送するために利用可能であることを示す。
【００３５】
図８は、本発明保護ポリシーの１つの実施形態のスクリーンショットである。各ファイルサーバの各シェアに対して格納アドミニストレータによって定義される一意の保護ポリシーがある。保護ポリシースクリーンに到達する前に、格納アドミニストレータは、シェアを作成し、それがＣＩＦＳおよび／またはＦＴＰによってアクセスされることを可能にする。新しいシェアが作成されると、保護ポリシースクリーンが表示される。このスクリーン内で、格納アドミニストレータは、以下のデータ保護パラメータを特定し得る。
【００３６】
・Ｐｒｏｔｅｃｔ  ｔｈｉｓ  ｓｈａｒｅ７８―このチェックボックスは、このシェアにおけるデータが、レポジトリによって保護されるべきことを示すとき、通常、チェックされる。一次格納に対してファイルサーバを用いるために選び得るが、サードパーティのバックアップまたはアーカイビングプロダクトを用いてデータの保護を継続するいくつかクライアントアプリケーションがある。
【００３７】
・Ｐｒｏｔｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ―Ｂａｃｋｕｐ  Ｆｒｅｑｕｅｎｃｙ７９―このオプションは、どのくらいの頻度でファイルサーバシェアのデータが、ローカルおよびリモートレポジトリにおいて保護されるかを決定する。１つの実施形態において、バックアップ頻度の間隔は、時間間隔のリストから選択され得る。そのリストは、１５分、３０分、１時間、２時間、３時間、４時間、６時間、８時間、１２時間および２４時間を含む。すべてのバックアップの頻度間隔は、各ファイルサーバの現地のタイムゾーンの夜中の１２時に固定されている。バックアップの頻度を２４時間に設定することは、従来の毎日の増分バックアップを実行することと同様である。この間隔を１５分に設定することは、日中頻繁に変更されるファイルのバージョンを１５分間隔で保護されることを可能にする。最後のバックアップが起こってから変更されたファイルだけがレポジトリに保存される。
【００３８】
・Ｐｒｏｔｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ―１つのレポジトリにつき複製の数。この特徴は、シェアが保護されるとき、格納アドミニストレータがどれくらいのデータの複製８０が、各レポジトリ内で作成されるかを決定することを可能にする。１つの実施形態において、シェアのファイルサーバのローカルであるレポジトリにおいて格納されている少なくとも１つの複製がなければならない。単一のレポジトリ内で複数の複製を維持することは可能である。この場合、複製はレポジトリの異なるレポジトリノード上で維持されて、単一レポジトリノードの故障もしくはネットワークの故障の場合、複製への継続するアクセスを確実にする。複製のロケーションおよび数は、時間の経過と共に変更され得る。重要度において増加しているデータに対するデータの利用可能性を増加するために、１つレポジトリにつきより多くの複製および追加的な複製が特定され得る。重要度において増加しているデータに対して、より少ない複製が、レポジトリに維持され得る、このことは、それらのレポジトリをまた使用している他のシェアに対してより多くの格納容量を利用可能にする。
【００３９】
・Ｖｅｒｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ―Ｋｅｅｐ  Ｖｅｒｓｉｏｎ  Ｈｉｓｔｏｒｙ８２―このチェックボックスは、ファイル内容が定期的にアップデータされているシェアに対してチェックされるべきである。チェックされるとき、特定されたレポジトリは、各バックアップ頻度の間隔で識別されるすべての変更のバージョンチェーンを維持する。変更されていないファイル内容を有するデータのシェアに対して、このチェックボックスは、チェックされ得ない。
【００４０】
・Ｖｅｒｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ―Ｖｅｒｓｉｏｎ  Ｃｏｍｐｒｅｓｓｉｏｎ８３―３つの圧縮オプシンは、圧縮しない、デルタ圧縮を逆から行う、または単純なファイル圧縮をシェアのファイルに適用する。デルタ圧縮は、一般的にファイルが定期的に修正されるシェアに対して一番高い圧縮比を提供する。
【００４１】
・Ｖｅｒｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ―Ｖｅｒｓｉｏｎ  Ｃｏｍｐａｃｔｉｏｎ８４―コンパクションは、各バージョンの年に基づいてファイルのバージョンを除去する手段を提供する。例えば、ファイルシェアに対するバージョンコンパクションオプションは、１年より古いファイルのマンスリーバージョン、６ヶ月より古いファイルのウィークリーバージョン、１ヶ月より古いファイルのデイリーバーションだけを維持するように構成され得る。すべての「エクストラ」バージョンは、レポジトリから自動的にパージされ、それが、新しいファイルと同様にファイルの新しいバージョンに対してより多くの格納容量を利用可能にする。
【００４２】
・Ａｄｖａｎｃｅｄ  Ｏｐｔｉｏｎｓ―Ｐｕｒｇｅ  ｏｎ  Ｄｅｌｅｔｅ８５―このオプションが、チェックされるとき、ファイルサーバのシェアから削除されるファイルがまた、レポジトリからもパージさせる。この特徴は、サードパーティのバックアップのようなアプリケーションで有効である。そこでは、レポジトリによって維持されている複製およびバージョンのいくつかが、そのアプリケーションの回復ウインドウ満たすために、もはや必要されなく、すべてのレポジトリからパージされ得る。
【００４３】
・Ａｄｖａｎｃｅｄ  Ｏｐｔｉｏｎｓ―Ｃａｃｈｉｎｇ  Ｌｅｖｅｌ８６―これは、格納が、ミラーサービス３３（図９）が、にレポジトリノードにステージアウトされるべき候補ファイルを探すレベルを制御することを可能にする。それは、上にファイルサーバ上にキャッシュされるクライアントデータのおおよその割合を表す。通常、このオプションは、「Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｒｅａｄ」に設定されて、最高の性能レベルで最近最も多くアクセスされたファイルの最大数をクライアントアプリケーションに利用可能にし得る。すべての最近最も少なくアクセスされたデータは、２つ以上のレポジトリに維持される。逆に言えば、キャッシュレベルは、「Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｗｒｉｔｅ」にセットされ得、これは、クライアントに利用可能なキャッシュされたデータの量を減少させるが、ファイルサーバ上の書き込み動作（例えば、受信データ）に対して高いレベルの利用可能な格納容量を一貫して提供する。人は、サードパーティバックアップアプリケーションといったアプリケーションに対してこのモード／設定を使用する。このモードにおいて、ファイルサーバのデータをレポジトリに積極的に移動させることによって、アプリケーションは、ファイルサーバを仮想的に無限の容量を有する格納デバイスとして見なす。
【００４４】
図９、１０は、ローカルレポジトリおよびリモートリポジトリを用いてクライアントによって作成されるデータファイルを保護するために用いられるモジュールを示す。
【００４５】
図９は、ローカルレポジトリのクライアントファイルを保護することに関連した本発明の装置およびソフトウェアの１つの実施形態を表す。この装置は、ファイルサーバ２７と、単一のローカルレポジトリノード２８とを備える。クライアントは、クライアント用ＩＰベースの（インターネットプロトコル）ネットワークを介してファイルサーバにアクセスし、ＮＦＳ、ＣＩＦＳまたはＦＴＰプロトコルを用いてファイルサーバと通信する。すべてのファイルサーバおよびすべてのレポジトリノードは、内部のＩＰを基にした（インターネットプロトコル）ネットワーク３０によって相互接続されている。現在のクライアントファイルは、ファイルサーバのファイルシステム３２上に常駐する。
【００４６】
本発明の実施形態に従って、クライアントファイル要求によって開始されるすべての入力／出力アクティビティは、フィルタドライブ３１によってインターセプトされる。ファイルサーバソフトウェアは、この最後のスナップショットが起こってから、すべての修正されたもしくは作成されたファイルのリストを維持する。１つの実施形態において、スナップショットの間隔は、保護ポリシーのバックアップ頻度１９に基づいて、１５分から２４時間の範囲に及び得る。バックアップ頻度の予定に基づいて、ミラーサービス３３は、そのシェアの保護ポリシーにおいて特定される（図２に示されるように）レポジトリ８に置かれるようにシェアにおいてすべての修正されたファイルを準備する。保護ポリシーは、複数のレポジトリにわたり格納され、かつ、複製され、また保護ポリシーキャッシュ３４における各ファイルサーバ内にキャッシュされ、かつ、定期的アップデータされる。例えば、シェアの保護ポリシーが、１時間に設定されているそのバックアップ頻度を有するとき、次の時間に移行する際、ミラーサービス３３は、ここ１時間で、すべての変更されたファイルのバックアップをローカルレポジトリ２８に開始する。すべての新しいファイルに対して、ローカルレポジトリの任意のレポジトリノードは、ファイルの複製を維持するように用いられ得る。修正されたファイルに対して、ミラーサービスは、現存のファイルの新しいバージョンをそのファイルの先のバージョンと同じレポジトリノードに向ける。ミラーサービスは、ロケーションキャッシュ３６をクエリーして、どのレポジトリノードが、現存のファイルのアップデートされたバージョンを受け取るかを決定する。このロケーションキャッシュは、ファイルサーバがファイルを特定のレポジトリノードに書き込むとき、ロケーションマネージャ３５によって定期的にアップデートされる。アップデートされたファイル、または作成されたファイルの最新のコレクションに対してシェアの各ファイルに対するすべての目的レポジトリノードを識別するとき、ロケーションマネージャは、ファイルサーバＡＰＩ３７およびレポジトリノードＡＰＩ３８を介して各ローカルレポジトリに通信する。各レポジトリノードのデータムーバ３９は、ファイルサーバからそのレポジトリノードへのファイルの複製を統括する。ファイルサーバファイルの転送モジュール４０は、ファイルサーバファイルシステムから各レポジトリノードのファイル転送モジュール４１にファイルを転送する。ファイルが、レポジトリノード内の特定のディスクドライブに複製されると、そのロケーションマネージャ４２は、そのロケーションマネージャ４２は、レポジトリノードのロケーション情報を有するそのロケーションキャッシュ４３をアップデートする。現存のファイルの修正されたバージョンであるすべてのファイルであって、レポジトリノードに到達するすべてのファイルに対して、シェアの保護ポリシー４４のバージョン管理設定は、新しいバージョンが圧縮されるべきか、またより古いバージョンが維持されるべきかどうかを決定するために見直される。
【００４７】
図９において、ファイルサーバ上の修復サービス４５は、現存するファイルサーバからのデータの１つ以上のシェアの動き（移送）か、または、現存するファイルが故障もしくはサイト障害で消失したときの新しいファイルへの動きのいずれかを管理することを担う。
【００４８】
記載におけるこの時点で、クライアントデータは、ローカルレポジトリに複製されるだけである。図１０は、１つ以上のリモートレポジトリへのデータを保護して、サイト障害からクライアントデータを完全に保護する処理をインプリメントするモジュールの１つの実施形態を示す。図１０は、図９に記載される動作からデータの第１の複製を有するローカルレポジトリノード４６を表す。図１０はまた、リモートレポジトリノード４７を示す。これらは、メトロポリタンまたはワイドエリアネットワーク４８にわたりお互いに接続されている。１つの実施形態において、ローカルおよびリモートレポジトリとの間で転送されるすべてのデータは、仮想プライベートネットワーク（ＶＰＮ）暗号化によって保護され得る。ローカルレポジトリノードの複製サービス５０は、最近のファイルサーババックアップの一部として今しがた作成されたすべてのファイルに対して保護ポリシー５０を見直すことを担う。各レポジトリノードは、他のレポジトリノードのピアの役目を果たす。保護ポリシーに基づいて、各レポジトリノードは、レポジトリノードＡＰＩ（５２、５３）と、データムーバ５４と、ファイル転送モジュール（５５、５６）とを用いて、すべてのレポジトリノードの間のファイルの動きを管理する。データが、各レポジトリノードのリモートレポジトリに複製されると、各レポジトリノードのロケーションマネージャは、そのレポジトリノード内でファイルが維持されている場所を追跡するためにロケーションキャッシュ５８をアップデートする。リモートレポジトリノードのバージョンサービス５９は、保護ポリシーに従ってファイルバージョンの圧縮およびコンパクションを管理する。
【００４９】
図１１は、シェア移送またはファイルサーバ回復操作が実行されることによる方法を表す。格納アドミニストレータは、図７に表される安全なウェブを基にしたユーザインターフェースを介して移送／回復アクティビティを開始する（６０）。このインターフェースから、格納アドミニストレータは、シェアの移送またはファイルサーバの回復に含まれるべき１つのシェアもしくは複数のシェア選択し、またシェアを受信する目的ファイルサーバを指定する（６１）。この動作は、シェアの移送、または目的ファイルサーバ上の回復サービスジョブを開始する。
【００５０】
目的ファイルサーバの回復サービスは、メタデータの複製されたコピーを有し得る２つ以上のレポジトリうちの１つからシェアのそのメタデータを収集する（６２）。シェアのメタデータに加えて、スタブファイルもまた、目的ファイルサーバを居住させる（６３）。スタブファイルは、通常のファイルとしてユーザには見えるが、代わりに当該のファイルの実際のロケーションのポインタを含むファイルである。
【００５１】
関連のスタブファイルのロード中、回復／移送サービスは、ファイルサーバのロケーションキャッシュをアップデートして、各回復されたファイルに関連したレポジトリノードのリストを維持する（６４）。こられのスタブファイルが配置されると、クライアントは、新しいファイルサーバに接続されて、それらがそれらのすべてのファイルを瞬時に見ることを可能にし得る。クライアントには、この回復オペレーションは、完了したように見えるが、各ファイルへのアクセスは、クライアントによって要求されるファイルは、レポジトリノードからファイルサーバに戻す転送を開始するので、わずかにより遅くなる。
【００５２】
図１１はまた、２段階の移送／回復の第２段階示す。第２段階において、クライアントは、それらのファイルにアクセスする（６５）。回復サービスは、優先度が高いタスクのファイルに対するクライアント要求に応答し、スタブファイル（例えば、４ＫＢのスタブファイル）を要求される各ファイルのすべての内容と置換する。より低い優先度において、回復サービスは、先のファイルサーバ上の最近最も多くアクセスされたファイルを目的ファイルサーバに戻すロードを開始／継続する。この処理は、移送／回復処理が進む一方で、データに対するクライアント要求を促進する。
【００５３】
より詳細には、処理は、先のファイル上で最近最も多くアクセスされたすべてのファイルが、目的ファイルサーバに完全に転送されたかどうかを決定する（６６）。そうであるならば、処理は、移送／回復処理が完了したと決定する。そうでなれれば、処理は、依然転送されていないファイルに対するクライアントファイル要求が受け取られたかどうかを決定する（６７）。そうであるならば、処理は、要求されたファイルに関連したスタブファイルをファイルのすべての内容と置換する（７０）。そうでなれれば、処理は、依然転送されていないファイルを転送し、（例えば、すべての特定のファイルが転送されたかどうかを決定する）ステップ６６に戻る（６８）。
【００５４】
図１３は、図９の回復サービス４５の１つの実施形態を示す。図１３を参照して、受け取りコンポーネント９４は、目的ファイルサーバで、メタデータおよびファイルのセットに関連したスタブファイルを受け取る。受け取りコンポーネントと通信してロケーションアップデートコンポーネント９５は、ファイルのセットにおいて各ファイルに関連したレポジトリノードのリストを維持する。加えて、受け取りコンポーネントと通信してスタブファイル置換コンポーネント９６は、スタブファイルを上述されるようなスタブファイルに関連したファイルのすべての内容と置換する。
【００５５】
図１２は、どのようにファイルサーバが、レポジトリに移送されるかを記載するフローチャートを示す。ミラーサービス３３（図９）は、ファイルサーバのファイルシステムにおける空間の消費を常にモニタする。ミラーサービス３３は、現在のファイルシステムの消費を保護ポリシーにおけるキャッシュレベル８６に対する格納アドミニストレータの選択（図８）に対して比較する。保護ポリシーにおいて格納アドミニストレータに利用可能である３つのキャッシュレベルは、「Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｒｅａｄ」、「Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｗｒｉｔｅ」および「Ｂａｌａｎｃｅｄ」である。これら３つの設定からファイルシステム利用率の実際の割合への変換は、構造化可能なＨＳＭ  ＸＭＬテーブルに維持されが、１つの実施形態において、デフォルトによって、Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｒｅａｄは、クライアントアプリケーションファイルをキャッシュする完全なるファイルシステムのおよそ７０％を維持しようとし、Ｂａｌａｎｃｅｄは、およそ５０％を維持しようとし、Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｗｒｉｔｅは、ファイルシステムにおけるデータのおよそ３０％を維持しようとする。Ｏｐｔｉｍｉｚｅ  ｆｏｒ  Ｗｒｉｔｅは、さらに重要なことには、データを主に書き込み、定期的にこのデータにアクセスしないクライアントアプリケーションに対して入ってくるデータに対して利用可能であるファイルサーバのスペースの７０％を保とうとする。
【００５６】
ファイルシステム利用率および保護ポリシーのキャッシュレベルの比較９０に基づいて、ミラーサービスは、ファイルシステム利用率を引き続きモニタするか、または「ステージアウト」を開始する。ステージアウトを準備する第１のステップは、ステージングに対して優良な候補になるファイルを識別することである（９１）。１つの実施形態において、実際のファイルを置換するスタブファイルは、４ＫＢを消費するので、４ＫＢ以下のすべてのファイルは、ステージアウトに対する候補とみなされない。最近クライアントアプリケーションによってアクセスされていないファイルといったより大きなファイルが、ステージアウトに対して好まれる。最後に、好適な候補ファイルは、本発明において起こる定期的なバックアップによってレポジトリに既にバックアップされているファイルである。候補ファイルのリストが作成されると、候補ファイルは、リストに従ってステージアウトされる（９２）。候補リストがステージアウトされると、システムは、ＨＳＭキャッシュのしきい値が依然超えられているかどうかを決定する（９３）。そうでなければ、より多くのファイルのステージアウトが起こる。
【００５７】
スタブファイルは、大変大きなファイルを置換し得るので、ファイルシステムスペースは、瞬時に使えるようになり、ファイルシステムの利用率をしきい値より下に下げる。従来のＨＳＭシステムは、ＨＳＭファイルシステムが満杯であるとき、すべてのファイルを磁気ディスクまたは光ディスクに瞬時にステージアウトしなければならない。しかし、本発明の実施形態は、継続中のバックアップの一部として２つレポジトリにおいて既に保護されている候補を選択する。それが、ファイルをステージアウトすることを必要とするとき、それは、バックアップ中にファイルサーバ上の完全なるファイルを格納されているファイルの完全なバージョンを指し示すスタブファイルと置換することだけを必要とする。このアプローチは、ファイルサーバからレポジトリに何百もしくは何千ものファイルを移動させる時間のかかる処理を排除する。このアプローチは、ファイルシステム利用率における急激な変化により早く反応するシステムを作成する。ファイルシステムの消費がＨＳＭキャッシュレベルより下に落ちると、ミラーサービスは、ファイルシステムの利用率をモニタすることに戻る。このようにして、ミラーサービスは、構造化可能なＨＳＭ  ＸＭＬテーブルに定義されるように、しきい値より下の値へ引き続きステージアウトを行う。
【００５８】
本発明は、従来のデータ格納および保護システムより何倍も速い移送／回復オペレーションの後、データをクライアントに利用可能にする。本発明の階層型格納管理の使用は、ファイルメタデータおよび４ＫＢのＨＳＭスタブファイルが、目的ファイルサーバ上にロードされ次第、それがデータをクライアントに提示することを可能にする。異なるファイルサーバに最近移送されたもしくは回復されたいずれかのスタブファイルは、１つ以上のレポジトリにおいて維持される完全なるファイルに対して代理の役目を果たすので、移送／回収アクティビティは、クライアントアプリケーションの観点から完了したように見える。また、１つの実施形態において、最近最も多く使用されたファイルだけが、ファイルシステムの最大しきい値によって定義されるように、バックグランドタスクとして新しいファイルサーバに再ロードされなければならない。従来のシェア移送もしくはサーバ回復を用いると、すべてのファイルは、著しく回収もしくは移送時間を延長するサーバ上に再ロードされなければならない。
【００５９】
このようにして、本発明の１つの実施形態は、１つファイルサーバから他のファイルサーバにファイルの移送を促進するために階層型格納管理（ＨＳＭ）を適用し、かつ、ファイルサーバの完全な消失のあと、クライアントがそれらのデータに再アクセスするために必要な時間を減少させる。
【００６０】
本発明の１つの実施形態は、２つ以上のデータセンターにわたり物理的に配置される一体化データ格納およびデータ保護システムである。本発明に従った各データセンター内での装置の１つの配置は、１つ以上のファイルサーバと、１つ以上のレポジトリとを含む。ファイルサーバは、ＮＦＳ、ＣＩＦＳ、ＦＴＰプロトコルを介して一次ディスク格納容量をＩＰネットワークのクライアントに提供する。各レポジトリは、以下のように動作するディスク格納容量の仮想のプールである。
【００６１】
・階層型格納管理の一部として、ファイルサーバの一次レベルデータ格納に対してニ次レベルのデータ格納の役目を果たす。
【００６２】
・新しいファイルおよび修正されたファイルを定期的に格納し、バージョンを維持することによって磁気テープバックアップシステムに対する代わりの役目を果たす。
【００６３】
・１つ以上のオフサイトレポジトリに対してファイルサーバのローカルであるレポジトリに格納されているすべてのデータを複製することによってオフサイトの媒体格納およびオフサイト障害回復システムに対する代わりの役目を果たす。
【００６４】
・すべてのファイルサーバの構成およびファイルメタデータ情報を複製する、複製された安定した格納環境の役目を果たす。
【００６５】
保護ポリシーは、どのようにファイルサーバの一次ディスク格納システム内のクライアントデータが、複数のデータセンターに位置するレポジトリの収集間で保護されるかを定義する。各シェアの保護ポリシーは、他の物事の間で、複数のレポジトリ間で維持する複製の数を定義する。１つの実施形態において、複製は、少なくとも２つのレポジトリに常駐する。これらのレポジトリは、お互いに障害から安全な距離に位置すべきである。
【００６６】
バックアップ頻度は、ファイルサーバが新しいクライアントデータおよびアップデートされたクライアントのデータを特定されたレポジトリに保護する定期的な時間間隔を定義する。定期的なバックアップの一部として、各ファイルサーバの構造およびファイルメタデータ情報もまた、複数のレポジトリに保護される。構造、およびレポジトリに格納されているメタ情報は、１つ以上のファイルサーバの消失から回復するため、かつ、ファイルサーバのコレクション間でデータのシェアを移送するために用いられる。
【図面の簡単な説明】
【００６７】
【図１】図１は、３つのデータセンターにわたる本発明の１つの実施形態の配置の図である。
【図２】図２は、保護ポリシーの１つの実施形態が、どのように、図１に示されるファイルサーバシェアと関連したレポジトリとの間の関係を作成するかを示す。
【図３】図３は、ファイルサーバまたは全体のサイトの損失から回復する第１のステップの１つの実施形態を示す。
【図４】図４は、ファイルサーバまたは全体のサイトの損失から回復する第２のステップの１つの実施形態を示す。
【図５】図５は、１つのファイルサーバから別のファイルサーバにデータのシェアを移送する第１のステップの１つの実施形態を示す。
【図６】図６は、１つのファイルサーバから別のファイルサーバにデータのシェアを移送する第２のステップの１つの実施形態を示す。
【図７】図７は、格納アドミニストレータが、選択されたファイルサーバファイルから別のファイルサーバファイルに１つ以上のシェアの移送を開始するために用いるユーザインターフェースの１つの実施形態を示す。
【図８】図８は、図２の保護ポリシーに対するユーザインターフェースの１つの実施形態のスクリーンショットを示す。
【図９】図９は、ローカルレポジトリノードの新しいクライアントデータを保護するために用いられる装置およびソフトウェアコンポーネントの１つの実施形態を示す。
【図１０】図１０は、レポジトリ間でデータを複製する装置の１つの実施形態を示す。
【図１１】図１１は、２段階のシェア移送またはサーバ回復オペレーションの１つの実施形態を示すフローチャートである。
【図１２】図１２は、ＨＳＭステージアウトの１つの実施形態を示すフローチャートである。
【図１３】図１３は、図９の回復サービスの１つの実施形態のブロック図である。
【図１】
2005538469.tif 000003
【図２】
2005538469.tif 000004
【図３】
2005538469.tif 000005
【図４】
2005538469.tif 000006
【図５】
2005538469.tif 000007
【図６】
2005538469.tif 000008
【図７】
2005538469.tif 000009
【図８】
2005538469.tif 000010
【図９】
2005538469.tif 000011
【図１０】
2005538469.tif 000012
【図１１】
2005538469.tif 000013
【図１２】
2005538469.tif 000014
【図１３】
2005538469.tif 000015
【国際調査報告】
2005538469.tif 000016