JP2009508191A - Ｉｄ保存を介するエンタープライズサーババージョン移行 - Google Patents

Abstract

サーバＩＤを保存しながら、アプリケーションの整合性および保全性を保って、適時の、アプリケーションインテリジェントな仕方でサーバサービスの自動化されたリカバリを提供するサービス利用可能性のためのシステムおよび方法が、説明される。ＳＰＳ（Ｓｅｒｖｉｃｅ Ｐｒｅｓｅｒｖａｔｉｏｎ Ｓｙｓｔｅｍ）と本明細書で呼ばれるシステムおよび方法は、一次サーバまたは他のサーバに障害が生じたイベント後または災害後、サーバへのユーザアクセスを再確立して、サーバデータの完全なリカバリを管理し、サーバサービスの継続性を保つ。本明細書で言及される障害、災害、および損失は、多くのレベルにおいてであることが可能であり、アイテムの不慮の削除、メールボックス全体の損失、ディスクドライブ全体の損失、サーバ全体の損失、および／またはサーバサイト全体の損失が含まれるが、以上には限定されない。
【選択図】図１

Description

（関連出願）
本出願は、２００５年２月７日に出願した米国特許出願第６０／６５０，５５６号の利益を主張する、２００５年８月２３日に出願した米国特許出願第１１／２１１，０５６号の一部継続出願である。

開示される実施形態は、データ管理に関し、より詳細には、ＩＤ保存を介してエンタープライズサービス利用可能性を提供することに関する。

エンタープライズサーバのようなサーバは、サーバのストレージシステムの中にクリティカルなプロダクションデータをホストし、メディア障害からデータセンタ障害までにわたる可能性がある、様々な障害に対して、このデータが、障害許容力があることを要求する可能性がある。加えて、他のエンタープライズサーバが、この同一のクリティカルなデータに同時にアクセスする必要性が、存在する可能性がある。これらのアプリケーションには、例えば、アプリケーション互換性またはデータ互換性を検証するサーバ機能の解析、監視、および監督が、例えば、含まれることが可能である。障害許容力の必要性は、テープベースのバックアップを含むことが可能な一連のデータ保護スキームによって対処が行われることが可能であり、同時にアクセスする必要性は、そのクリティカルなプロダクションデータおよび／またはソフトウェアのレプリカを有する専用の解析サーバをセットアップすることを含むことが可能な、一連のデータ管理スキームによって対処が行われることが可能である。

通常のデータ保護スキームおよびデータ管理スキームは、アプローチが様々である可能性があり、多数の領域で不備がある。例えば、通常のアプローチの不備は、アプリケーションインテリジェンスの欠如と関係することが可能である。ブロックベースのアプローチ、およびファイルベースのアプローチは、アプリケーションインテリジェントではなく、サーバアプリケーションおよび／またはデータの保全性および整合性を保存しない。データ破損が、一次サーバデータベースを襲った場合、その破損は、そのデータの通常の災害復旧コピーにレプリケートされ、そのコピーが壊れる。さらに、従来のサーバ災害復旧ソリューションは、ファイルシステムベースであり、スクリプトおよび手動ステップが、フェイルオーバのためにサーバサービスを再構成することを要求する。手動ステップは、誤りが生じやすく、時間がかかり、スクリプトは、サイトごとにカスタマイズされ、保守するのに費用がかかる。さらに、通常の災害復旧アプローチは、サポートされていないエージェントドライバおよびフィルタシステムドライバ、ならびに合致するスタンバイサーバ名を強要し、このことは、プロダクションシステム障害、構成の誤りを生じさせ、一般に、全体的な管理の複雑さを増大させる可能性がある。また、他のサーバによるエンタープライズサーバへの直接アクセスも、不安定性、およびエンタープライズサーバにかかるパフォーマンス負荷をもたらす可能性がある一方で、他の不備は、テープストレージの順次の性質、およびオフラインの性質と関係することが可能である。したがって、サーバＩＤを保存しながら、エンタープライズサービス利用可能性を提供するシステムおよび方法の必要性が、存在する。
（参照による組み込み）
本明細書で言及される各刊行物、各特許、および／または各特許出願は、個別の各刊行物、各特許、および／または各特許出願が、明確に、個別に、参照によって組み込まれるように示されているのと同じ程度に、参照により全体が本明細書に組み込まれている。

サーバＩＤを保存しながら、アプリケーションの整合性および保全性を保って、適時の、アプリケーションインテリジェントな仕方でサーバサービスの自動化されたリカバリを提供するサービス利用可能性のためのシステムおよび方法が、説明される。ＳＰＳ（Ｓｅｒｖｉｃｅ Ｐｒｅｓｅｒｖａｔｉｏｎ Ｓｙｓｔｅｍ）と本明細書でひとまとめにして呼ばれるシステムおよび方法は、一次サーバまたは他のサーバに障害が生じたイベント後または災害後、サーバへのユーザアクセスを再確立して、サーバデータの完全なリカバリを管理し、サーバサービスの継続性を保つ。本明細書で言及される障害、災害、および損失は、多くのレベルにおいてであることが可能であり、アイテムの不慮の削除、メールボックス全体の損失、ディスクドライブ全体の損失、サーバ全体の損失、および／またはサーバサイト全体の損失が含まれるが、以上には限定されない。

例として、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ（代替として、本明細書でＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒと呼ばれる）が、サイト災害またはシステム停止に備えて、電子メールアーカイブの保護、および電子メールサービス継続性のためのオフサイトデータレプリケーションを含む最高レベルのデータ保護および利用可能性を要求する。この例では、或る実施形態のＳＰＳが、Ｅｘｃｈａｎｇｅサービスの自動化された災害復旧を、アプリケーションの整合性および保全性を保って、アプリケーションインテリジェントな仕方で提供する。ＳＰＳを使用すると、管理者は、「ワンクリック」操作で、Ｅｘｃｈａｎｇｅサービスをローカル（またはリモート）スタンバイＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒにリカバリする。或る実施形態のＳＰＳは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ ＯｐｔｉｏｎのためのＮｅａｒＰｏｉｎｔ（商標）として、カリフォルニア州サンタクララ所在のＭｉｍｏｓａ Ｓｙｓｔｅｍｓ，Ｉｎｃ．から入手可能である。

或る実施形態のＳＰＳは、ニアラインサーバ（本明細書で、ニアポイントサーバとも呼ばれ、そのようなサーバには、Ｍｉｍｏｓａ ＮｅａｒＰｏｉｎｔ（商標）サーバが含まれることが可能である）と一体化され、サーバに障害が生じ、かつ／またはデータが失われたイベントが生じた場合に、一次サーバサービスの完全な自動化されたリカバリを実行するアドオンモジュールである。ニアラインサーバは、エンタープライズニーズに応じて、エンタープライズサーバと一緒にローカルで配置されることも、遠隔に配置されることも可能である。ローカルサーバデータ保護のため、ＳＰＳは、エージェントドライバソフトウェアまたはフィルタシステムドライバソフトウェアに依拠しないアプリケーションシャドーイングを使用して、ローカルサーバを保護する。ニアラインサーバデータのリモートサイトへのレプリケーションの場合、ＳＰＳは、例えば、サードパーティのレプリケーションソフトウェアと一体化することができる。この複合アプローチを使用して、ＳＰＳは、シャドーイングを使用してローカルサーバリカバリに対処する一方で、破局的なイベントは、本明細書で詳細に説明されるとおり、シャドーイングとサービス保存の組合せを活用することにより、対処が行われる。本明細書で説明されるＳＰＳのアプリケーションインテリジェントなリカバリは、サーバデータの整合性および保全性を保存し、このため、サーバデータベースの破損のないコピーを確実にする。

サービス保存に加え、或る実施形態のＳＰＳは、サーバリソースの構成セットアップ（例えば、ハードウェア、ソフトウェア、データなど）を確認するとともに、サービス保存システムの予備試験またはドレスリハーサルを行うのに使用されることが可能である。サービス確認が使用されることが可能なイベントには、いくつかを挙げると、サーバデータを新たなソフトウェアバージョンに移行させること、およびメンテナンスのために一次サーバを機能停止させることが含まれる。データ移行とは、コンピュータシステム間、ストレージタイプ間、および／またはフォーマット間でデータを移すことを指す。或る実施形態のＳＰＳにおいてサーバまたはデータを移行させることは、ＳＰＳのコンポーネントを使用して、サービス保存に関して本明細書で説明されるのと同様の仕方でデータ移行を実行する。或る実施形態のＳＰＳは、管理者を手引きするウィザード駆動のメニューを使用して、すべての災害復旧の構成およびポリシーを管理するＡｄｍｉｎｉｓｔｒａｔｉｏｎ Ｃｏｎｓｏｌｅを含む。ドレスリハーサル、リハーサル、またはドリルとも呼ばれる予備試験は、構成セットアップを確認し、災害ステータスレポートが、完全なリカバリ構成を継続的に監視する。サーバ損失またはサーバサイト損失が生じた場合、ＳＰＳは、例えば、スタンバイサーバへのサーバサービスのリカバリを完全に自動化し、すべてのアーカイブデータを保存する。

本明細書で詳細に説明されるＳＰＳは、エンタープライズサーバ名が、一次エンタープライズサーバ名と一致しなければならないという要件を完全になくしながら、サーバデータをリカバリすること、メールボックスを再バインドすること、およびサーバサービスを再確立して、エンドユーザへのサービスの迅速で、確実な復元を確実にすることを含め、完全なサーバサービスリカバリを提供する。また、ＳＰＳは、災害復旧の簡略化された構成および管理を使用して、電子メールサービス（例えば、Ｅｘｃｈａｎｇｅ）およびニアラインサーバアーカイブサービスの自動化された災害復旧を、単一の統合されたソリューションにおいて提供する。ＳＰＳは、サーバにインストールされたエージェントドライバソフトウェアまたはカーネルドライバソフトウェアを要求することなしに動作して、その結果、不安定性の通常の原因を解消し、プロセッサリソース、メモリリソース、およびストレージリソースに関する競合を解消する、ゼロフットプリントのリカバリソリューションである。

以下の説明では、ＳＰＳの実施形態の徹底的な理解、および実施を可能にする説明を提供するように、多数の特定の詳細について述べる。しかし、ＳＰＳは、それらの特定の詳細の１つまたは複数なしに、あるいは他のコンポーネント、他のシステムなどを伴って実施されることも可能であることが、当業者には認識されよう。その他、よく知られている構造、またはよく知られている動作は、ＳＰＳの態様を不明瞭にするのを避けるために、図示されておらず、あるいは詳細に説明されていない。

図１は、或る実施形態の下におけるＳＰＳ１００のブロック図である。ＳＰＳ１００構成は、各サーバサイトの特定の構成および／または要件と合致するように構成されることが可能であるという点で、柔軟性がある。この柔軟性は、ＳＰＳ１００が、後段ですべて説明される、エンタープライズサーバリカバリ、ニアラインサーバリカバリ、およびサイトリカバリを提供することを可能にし、アイテムリカバリ、メールボックスリカバリ、およびドライブリカバリをサポートすることができる。一般に、ＳＰＳ１００は、第１のサーバＳ１および第２のサーバＳ２に結合されたニアラインサーバＮＬを含む。一次サーバと呼ばれることが可能であり、複数のサーバを含むことが可能な第１のサーバＳ１は、エンタープライズの一次サーバＳ１として機能し、そのように機能する際、多数のクライアントデバイスおよび／またはクライアントアプリケーションＣＮ（ただし、Ｎは、任意の数、１、２、３．．．である）にサーバサービスを提供するように結合または接続される。本明細書で個々に、またはひとまとめにして、クライアント１０２と呼ばれるクライアントデバイスおよび／またはクライアントアプリケーションＣＮは、任意の数のサイトに配置され、任意の数の結合または接続を介して一次サーバＳ１に結合される任意の数Ｎ個のクライアントを含むことが可能である。複数のサーバをやはり含むことが可能な第２のサーバＳ２は、エンタープライズのバックアップサーバまたはスタンバイサーバＳ２として機能し、そのように機能する際、クライアント１０２にサーバサービスを提供するように結合する、または接続することができる。ニアラインサーバＮＬは、単一のニアラインサーバＮＬとして図示されているが、ニアラインサーバＮＬは、クラスタ化されたサーバアーキテクチャ、分散サーバアーキテクチャ、レプリケートされたサーバアーキテクチャ、および仮想化されたサーバアーキテクチャを含み、さらに、複数のマシンおよび／または複数のサイトにわたることが可能である。

ニアラインサーバＮＬは、一次サーバＳ１の通常の動作中、一次サーバＳ１を継続的にシャドーイング１３０する。このため、クライアント１０２は、通常の動作中、一次サーバＳ１に向かわされ１１０、ニアラインサーバＮＬが、一次サーバＳ１のすべてのデータのレプリカまたはコピーを格納する。一次サーバＳ１の検出された障害に応答して、ニアラインサーバＮＬは、スタンバイサーバＳ２へのリダイレクトされた復元１４０を実行する。リダイレクトされた復元１４０は、いくつかの動作を含み、それらの動作中、ニアラインサーバＮＬは、一次サーバデータのレプリカをスタンバイサーバＳ２に伝播させる、またはコピーする。また、ニアラインサーバＮＬは、すべてのクライアント１０２をスタンバイサーバＳ２にフェイルオーバさせ、または再ホーミングさせて１１５、クライアント１０２の再起動の後、サーバサービスの継続性が、スタンバイサーバＳ２を介して、クライアントデバイス１０２によるサービスへのアクセスを自動的に再確立１２０することにより、保たれるようにする。

本明細書で使用されるシャドーイングは、アプリケーション整合性のある仕方でエンタープライズアプリケーションデータのレプリカを作成して、保持することを含む。これは、従来のレプリケーションまたは継続的データ保護に優り、そのようなレプリケーションまたは保護と比べて、相対的により効率的である。また、シャドーイングは、ＭＡＰＩ（Ｍｅｓｓａｇｉｎｇ Ａｐｐｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）またはＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの機構を使用する従来のキャプチャと比べても、相対的により効率的である。シャドーイングされるアプリケーションデータは、元のアプリケーションのフォーマットでニアラインサーバＮＬ上に格納されており、データ破損、またはリカバリ不能なメディア障害が生じると、即時に、またはほぼリアルタイムで、一次サーバＳ１および／またはスタンバイサーバＳ２に利用可能である。

クライアント（例えば、Ｅｎｔｅｒｐｒｉｓｅ Ｃｌｉｅｎｔ）およびサーバ（例えば、Ｅｎｔｅｒｐｒｉｓｅ ＳｅｒｖｅｒおよびＡｌｔｅｒｎａｔｅ Ｓｅｒｖｅｒ）は、任意のタイプおよび／または組合せのプロセッサベースのデバイスであることが可能である。単一のテンス（ｔｅｎｓｅ）のシステムおよび／またはサーバへの言及は、そのシステムまたはサーバの複数の実例を含むことが可能である。本明細書で説明されるＳＰＳ実施形態の様々なコンポーネント間の結合には、ホストシステム構成に適切なように、無線結合タイプ、有線結合タイプ、混成有線／無線結合タイプ、およびその他のネットワーク結合タイプが含まれることが可能である。ＳＰＳのコンポーネント間のネットワークコンポーネントおよび／または結合には、いくつかを挙げると、ＷＡＮ（ワイドエリアネットワーク）、ＬＡＮ（ローカルエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、独自ネットワーク、バックエンドネットワーク、およびインターネットを含むが、以上には限定されない、任意のタイプ、数、および／または組合せのネットワーク、および対応するネットワークコンポーネントが含まれることが可能である。トランスポート、相互接続、またはネットワークのような用語の本明細書における用法には、従来のイーサネット、ＳＡＮ（ストレージエリアネットワーク）、および／またはその他のタイプのネットワークが含まれる。プロトコルには、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰ））および階層型プロトコル、ｉＳＣＳＩ（Ｉｎｔｅｒｎｅｔ Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ（ＳＣＳＩ））、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ、ＩｎｆｉｎｉＢａｎｄ、ＨＴ（ＨｙｐｅｒＴｒａｎｓｐｏｒｔ）、ＶＩ（Ｖｉｒｔｕａｌ Ｉｎｔｅｒｆａｃｅ）、ＲＤＭＡ（Ｒｅｍｏｔｅ Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）、および一連の他のプロトコルが含まれることが可能である。

図２Ａは、或る実施形態の下におけるサービス保存２００の流れ図である。ＳＰＳのコンポーネントは、１つまたは複数の生きているサーバを継続的にシャドーイング２０２するように機能する。生きているサーバは、複数のクライアントデバイスにサービスを提供するデータを含む。ＳＰＳは、シャドーイング中に一次サーバデータのレプリカを生成して、保持する２０４。クライアントに対するサービスは、その１つまたは複数の生きているサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して自動的に復元２０６される。クライアントに対するサービスの自動的復元には、ニアラインサーバからのデータのレプリカを、１つまたは複数のスタンバイサーバにコピーすることが含まれる。

サービス保存に加えて、或る実施形態のＳＰＳは、サーバリソースの構成セットアップ（例えば、ハードウェア、ソフトウェア、データなど）を確認するとともに、サービス保存システムの予備試験またはドレスリハーサルを行うのに使用されることが可能である。サービス確認が使用されることが可能なイベントには、いくつかを挙げると、サーバを新たなソフトウェアバージョンに移行させること、およびメンテナンスのために一次サーバを機能停止させることが含まれる。サーバを新たなソフトウェアバージョンに移行させることには、データ移行のためのＳＰＳの使用が含まれ、ただし、データ移行とは、コンピュータシステム間、ストレージタイプ間、および／またはフォーマット間でデータを移すことである。ＳＰＳのサービス確認能力は、サービス確認が、クライアントの再ホーミングを要求しないこと以外は、本明細書で説明されるサービス保存と同じように働く。

図２Ｂは、或る実施形態の下におけるサービス確認２５０を含むサービス保存の流れ図である。ＳＰＳのコンポーネントは、サービスのステータスを判定２２０する、あるいは予備試験が、管理者によって選択されているかどうかを判定２２０する。エンタープライズサーバサービスが提供されているとＳＰＳが判定２２０すると、動作は、そのサービスのステータスを引き続き監視することに戻る。サーバサービスが、ダウンしている、または利用できない（例えば、障害に起因して）とＳＰＳが判定２２０すると、一次サーバまたは一次サーバサイトは、非活性化２２２される、または機能停止させられる。リダイレクトされた復元が、実行され２２４、その間、ニアラインサーバが、一次サーバデータのレプリカをスタンバイサーバにコピーする。スタンバイサーバが、活性化され２２６、スタンバイサーバの動作が、検証または点検される。クライアントは、スタンバイサーバに再ホーミング２２８されて、クライアントの再起動の後、サーバサービスの継続性が、スタンバイサーバを介して、クライアントによるサービスへのアクセスを自動的に再確立することにより、保たれるようにする。動作は、そのサービスのステータスを引き続き監視することに戻る。

予備試験またはドレスリハーサルが選択されているとＳＰＳが判定２２０すると、一次サーバまたは一次サーバサイトは、クライアントにサービスを引き続き提供する。リダイレクトされた復元が、実行され２２４、その間、ニアラインサーバが、一次サーバデータのレプリカをスタンバイサーバにコピーする。スタンバイサーバは、スタンバイサーバの動作が、スタンバイサーバの任意のコンポーネントおよび／またはアプリケーションの検出のために評価されることが可能であるように、活性化される。スタンバイサーバ動作の検証の後、スタンバイサーバは、スタンバイステータス２３８に戻される。動作は、サービスのステータスを引き続き監視することに戻る。

エンタープライズ設定またはエンタープライズ構成におけるサーバのサービス保存を考慮して、或る実施形態のＳＰＳは、一次エンタープライズサーバに関する総合的災害保護、およびエンタープライズサービスの自動化されたリカバリを提供する。ニアラインサーバＮＬは、前述した継続的なアプリケーションシャドーイングを使用して、一次サーバをほぼリアルタイムで保護する。ニアラインサーバＮＬは、ハードウェア障害またはソフトウェア障害が生じた場合、エンタープライズデータベース、ストレージグループ、および／またはエンタープライズサーバ全体を独力で復元することができる。或る実施形態のサービス保存は、ニアラインサーバＮＬの能力を拡張し、エンタープライズサーバを再起動すること、およびサービスディレクトリの中のメールボックスを再マッピングすることを含め、ローカルスタンバイエンタープライズサーバおよび／またはリモートスタンバイエンタープライズサーバへのエンタープライズデータの自動的復元を可能にする。ＳＰＳの自動化されたリカバリプロセスは、すべてのエンタープライズサーバデータを復元し、サービスディレクトリの中のメールボックスを再バインドし、システムメールボックスをクリーンアップし、すべてのクライアントを再ホーミングし、エンタープライズサーバを再起動する。完了すると、ユーザは、いくつかを挙げると、エンタープライズ電子メールおよびアーカイブ電子メールへの完全なアクセスを伴って、スタンバイエンタープライズサーバへのアクセスを有する。このため、ニアラインサーバＮＬによって実行されるエンタープライズサーバの自動化されたリカバリは、サービスの損失を最小限に抑え、クリティカルなエンタープライズサービスのビジネス継続性を提供する。

１つの特定のサービス構成は、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒに関する総合的災害保護、およびＥｘｃｈａｎｇｅサービスの自動化されたリカバリを提供する、或る実施形態のＳＰＳを含む。ニアラインサーバは、継続的なアプリケーションシャドーイングを使用して、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒをほぼリアルタイムで保護する。前述したとおり、ニアラインサーバは、ハードウェア障害またはソフトウェア障害が生じた場合に、Ｅｘｃｈａｎｇｅデータベース、Ｓｔｏｒａｇｅ Ｇｒｏｕｐ、またはＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒ全体を復元することができる。このため、ニアラインサーバは、Ｅｘｃｈａｎｇｅサービスを再起動すること、およびＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｅｒの中のメールボックスを再マッピングすることを含め、ローカル（またはリモート）スタンバイＥｘｃｈａｎｇｅ ＳｅｒｖｅｒへのＥｘｃｈａｎｇｅデータの復元を提供するように機能する。したがって、Ｅｘｃｈａｎｇｅサービスリカバリに関して、或る実施形態のＳＰＳは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙの中のメールボックスを再バインドし、Ｅｘｃｈａｎｇｅ ＲｏｌｅおよびＥｘｃｈａｎｇｅ Ｓｅｒｖｉｃｅを識別し、Ｅｘｃｈａｎｇｅ ＲｏｌｅおよびＥｘｃｈａｎｇｅ Ｓｅｒｖｉｃｅを再ホーミングし、Ｐｕｂｌｉｃ Ｆｏｌｄｅｒ Ｓｔｏｒｅを再ホーミングし、システムメールボックスをクリーンアップして、重複アイテムを除去し、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｉｃｅを再起動し、かつ／またはエンドユーザに対するＯｕｔｌｏｏｋサービスおよびＳＳＲサービスを復元する。

ニアラインサーバを含むＳＰＳのコンポーネントは、任意の数のサイトに物理的に配置されることが可能である。例えば、ニアラインサーバは、一次サーバＳ１と一緒に、一次サイトに物理的に配置されることが可能である。図３は、或る実施形態の下における、ニアラインサーバＮＬが、一次サーバＳ１と同一のサイト３０２に配置されるＳＰＳ３００のブロック図である。別の例として、ニアラインサーバは、スタンバイサーバＳ２と一緒に、スタンバイサイトに物理的に配置されることが可能である。図４は、或る実施形態の下における、ニアラインサーバＮＬが、スタンバイサーバＳ２と同一のサイト４０２に配置されるＳＰＳ４００のブロック図である。

ニアラインサーバＮＬの配置にかかわらず、或る実施形態のＳＰＳは、サーバ障害またはサイト障害が生じると、最新のアプリケーション整合性のあるデータコピーを、ニアラインサーバＮＬを介して提供し、したがって、サービスを復元することができる。図５は、或る実施形態の下における、ニアラインサーバＮＬが、サービス保存のためのアプリケーション整合性のあるデータコピーを提供することができる多数のやり方を示すＳＰＳ５００のブロック図である。前述したとおり、サービス障害が生じた場合、ニアラインサーバＮＬは、リダイレクトされた復元動作１４０Ｓにおいて、置換サーバまたはスタンバイサーバＳ２へのデータアクセスを直接に提供することができ、リダイレクトされた復元１４０Ｓの後に続き、復元１４０Ｓと同時に、スタンバイサーバＳ２は、スタンバイサーバＳ２にフェイルオーバ１１５Ａしたクライアント１０２に、エンタープライズサービスを提供する。同様に、ニアラインサーバＮＬは、直接復元オペレーション１４０Ｐにおいて、一次サーバＳ１へのデータアクセスを直接に提供することができ、直接復元１４０Ｐの後に続き、または復元１４０Ｐと同時に、一次サーバＳ１は、クライアント１０２にエンタープライズサービスを引き続き提供する。代替として、ニアラインサーバＮＬは、エンタープライズデータのレプリカを使用することにより、置換サーバに成り済まして、ニアラインサーバＮＬにフェイルオーバ１１５Ｂしたクライアント１０２にエンタープライズサービスを直接に提供することができる。

代替の実施形態のＳＰＳは、破局的なサイト障害に応答してエンタープライズサービスを復元する際に、前述したシャドーイング、リダイレクトされた復元、およびフェイルオーバを使用する。後段でさらに詳細に説明されるとおり、クライアント１０２は、置換（スタンバイ）サーバＳ２にフェイルオーバ１１５Ａする、またはリモート災害復旧サイト（例えば、図４の復旧サイト４０２）に配置されたニアラインサーバＮＬに直接にフェイルオーバ１１５Ｂすることができる。

図６は、或る実施形態の下における、ローカルサービス保存またはリモートサービス保存を含むＳＰＳ６００である。この実施形態のＳＰＳ６００は、メッセージングサーバ６０２に関してフェイルオーバサービス保存を提供することの実施例であり、メッセージングサーバ６０２について、この実施例で説明されるが、ＳＰＳは、前述したとおり、任意のサーバタイプに対して使用されることが可能である。動作の際、ニアラインサーバＮＬは、一次メッセージングサーバ６０２においてプロダクション障害が生じたことを検出する（または通知される）。ニアラインサーバＮＬは、そのような障害に先回りして備える。障害が生じると、ニアラインサーバＮＬは、シャドーデータベース６０４から、一次メッセージングサーバ６０２のアプリケーションデータの最新の使用可能なコピーを実現することができる。このデータコピーまたはデータレプリカは、ホットスタンバイメッセージングサーバ６１２に、その後、または同時にコピーされることが可能である。代替として、ＮＡＳデータサービスプロトコルまたはＳＡＮデータサービスプロトコル、および／またはＤＦＳ−Ｒ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｒｅｐｌｉｃａｔｉｏｎ）などのレプリケーション技術を使用して、スタンバイメッセージングサーバ６１２にデータを直接に供給することも可能である。また、ニアラインサーバＮＬが、ＭＡＰＩ、ＩＭＡＰ４（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌバージョン４）またはＰＯＰ３（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌバージョン３）、またはその他のプロトコルなどを含むことが可能なアプリケーションプロトコルを直接に供給することにより、スタンバイメッセージングサーバ６１２に成り済ますことも可能である。データレプリカが、スタンバイメッセージングサーバ６１２にコピーされると、クライアントアプリケーション６０１は、スタンバイメッセージングサーバ６１２にフェイルオーバ６１５する。さらに、メッセージングサーバ６０２および／またはニアラインサーバＮＬの他のデータ（例えば、メタデータ（例えば、Ｍｅｔａｂａｓｅ）、およびＩｎｄｅｘｅｄ Ｏｂｊｅｃｔ ＲｅｐｏｓｉｔｏｒｙのＲｅｐｏｓｉｔｏｒｙ）が、代替の実施形態において、レプリケートされることが可能である。

クライアント６０１、およびその他のエンタープライズコンポーネント（図示せず）は、一次メッセージングサーバ６０２およびニアラインサーバＮＬの存在を別々のエンティティとして直接に認識していることが可能である。また、クライアント６０１が、リソースまたはサービスの単一のシステムビューを獲得し続けるように、クライアント６０１間のプロキシ６６０エンティティ、および／または他の１つまたは複数の関連したエンタープライズコンポーネントの介在を含むことが可能な、他の変種も可能である。このプロキシ６６０は、１つまたは複数のサーバ、および１つまたは複数のフェイルオーバエンティティ（例えば、サーバ）を集約する。障害が生じると、プロキシ６６０は、クライアント６０１および／またはエンタープライズからの要求を代替のリソースにフェイルオーバ６１５させることができる。一次リソースが復元されると、プロキシは、その要求を一次リソースにフェイルバック６１５させる（フェイルバック）ことができる。プロキシ６６０（ならびにエンタープライズサーバおよびニアラインサーバＮＬ）は、クラスタ化される、レプリケートされる、仮想化される、分散されることが可能であり、かつ／またはグリッドのコンポーネントであることが可能である。プロキシのいくつかの部分が、クライアント、エンタープライズサーバ、データサロゲート、その他のエンタープライズコンポーネント、または何らかの変種もしくは組合せにまたがることが可能である。

障害中、ニアラインサーバＮＬが、オプションの再ハイドレータモジュール６７０を介して、データの履歴スナップショットを実現することも可能である。この履歴スナップショットは、データの最新のコピーが、ＳＰＡＭまたはウイルスに感染している可能性があるケースで、またはそのようなコピーが、何らかの理由で信頼されない場合に、使用されることが可能である。監査目的で、ニアラインサーバＮＬが、いくつかの時間におけるスナップショットを監査アプリケーションに同時に供給して、監査アプリケーションが、複数の時点における複数のプロダクションサーバの状態の時間的ビューまたは空間的ビューを得ることができるようにすることが可能である。時間におけるスナップショットは、データおよびメタデータで構成された、指定されたパターンと合致するデータの任意の細分性のために供給されることが可能である。したがって、ＳＰＳは、データの様々な部分に関する高度な基準を使用して、選択的なロールバックおよび／またはロールフォワードを提供することができる。

前述したとおり、或る実施形態のＳＰＳは、ニアラインサーバ上に格納されたレプリカデータの継続的な保護もサポートする。図７Ａは、或る実施形態の下における、ニアラインサーバＮＬ１が、スタンバイニアラインサーバＮＬ２上にレプリケートされるＳＰＳ７００のブロック図である。ＳＰＳ７００は、第１のサーバＳ１に結合された第１のニアラインサーバＮＬ１を含む。一次サーバと呼ばれることが可能であり、複数のサーバを含むことが可能な第１のサーバＳ１は、エンタープライズの一次サーバＳ１として機能し、そのように機能する際、多数のクライアント１０２にサーバサービスを提供するように結合または接続される。第２のニアラインサーバＮＬ２が、第１のニアラインサーバＮＬ１に結合される。第２のニアラインサーバＮＬ２は、本明細書で説明されるとおり、リダイレクトされた復元を介して、第１のサーバＳ１および／または第２のサーバＳ２にレプリカデータを提供するように結合される。複数のサーバをやはり含むことが可能な第２のサーバＳ２は、エンタープライズのバックアップサーバまたはスタンバイサーバＳ２として機能し、そのように機能する際、多数のクライアント１０２にサーバサービスを提供するように結合または接続されることが可能である。

第１のニアラインサーバＮＬ１は、一次サーバＳ１のデータセンタサイトに、スタンバイサーバＳ２のリカバリサイトに、または別のリモートサイトに配置されることが可能である。同様に、第２のニアラインサーバＮＬ２も、一次サーバＳ１のデータセンタサイトに、スタンバイサーバＳ２のリカバリサイトに、または別のリモートサイトに配置されることが可能である。

第１のニアラインサーバＮＬ１は、一次サーバＳ１の通常の動作中、一次サーバＳ１を継続的にシャドーイング１３０する。このため、クライアント１０２は、通常の動作中、一次サーバＳ１に向かわされ１１０、第１のニアラインサーバＮＬ１が、一次サーバＳ１のすべてのデータのレプリカまたはコピーを生成して、格納する。さらに、ＳＰＳ７００のコンポーネントが、第１のニアラインサーバＮＬ１のデータを第２のニアラインサーバＮＬ２上にレプリケート７０２する。レプリケーション７０２は、非同期の、バイトレベルのレプリケーションであることが可能であるが、そのように限定されない。

ＳＰＳ７００は、第２のサーバ、つまり、スタンバイニアラインサーバＮＬ２を使用して、いくつかを挙げると、シャドーボリューム、ＳＱＬデータベース、およびメッセージアイテムを含むデータである、第１のニアラインサーバＮＬ１上に存在するすべてのデータを保護する。第１のニアラインサーバＮＬ１上の単一ボリュームの障害または完全なシステム障害が生じた場合、データは、第２のニアラインサーバＮＬ２を使用して、迅速に復元されることが可能である。データ復元が完了すると、レプリケーションソフトウェアは、データボリュームを自動的に再同期して、レプリケーションが再び始まる。このようにして、ニアラインサーバ上のクリティカルなエンタープライズデータおよびアーカイブデータが、常に保護される。

より具体的には、第１のニアラインサーバＮＬ１の検出された障害（例えば、ハードウェア障害および／またはソフトウェア障害）に応答して、第２のニアラインサーバＮＬ２が、活性になるように昇格させられる。活性になると、第２のニアラインサーバＮＬ２は、一次サーバＳ１の検出された障害（例えば、ハードウェア障害および／またはソフトウェア障害）に応答して、スタンバイサーバＳ２に対してリダイレクトされた復元１４０を実行する。リダイレクトされた復元１４０は、第２のニアラインサーバＮＬ２が、一次サーバデータのレプリカをスタンバイサーバＳ２にコピーする動作を含む。また、第２のニアラインサーバＮＬ２は、すべてのクライアント１０２をスタンバイサーバＳ２に再ホーミング１１５して、クライアント１０２の再起動の後、サーバサービスの継続性が、スタンバイサーバＳ２を介して、クライアントデバイス１０２によるサービスへのアクセスを自動的に再確立１２０することにより、保たれるようにする。

ＳＰＳ７００のコンポーネントの役割は、エンタープライズサービスがスタンバイサーバＳ２によって提供される動作において変化する。図７Ｂは、或る実施形態の下における、スタンバイサーバＳ２が、一次サーバＳ１の障害の後に一次サービスプロバイダの役割をしている場合のＳＰＳ７００のブロック図である。第２のニアラインサーバＮＬ２は、スタンバイサーバＳ２の通常の動作中にスタンバイサーバＳ２を継続的にシャドーイング１３０Ｂする。このため、クライアント１０２は、通常の動作中、スタンバイサーバＳ２に向かわされ１１０Ｂ、第２のニアラインサーバＮＬ２は、スタンバイサーバＳ２のすべてのデータのレプリカまたはコピーを生成して、格納する。さらに、ＳＰＳ７００のコンポーネントは、第２のニアラインサーバＮＬ２のデータを第１のニアラインサーバＮＬ１上にレプリケート７０２Ｂする。

次に、ＳＰＳ７００は、第１のニアラインサーバＮＬ１を使用して、第２のニアラインサーバＮＬ２上に存在するすべてのデータを保護する。第２のニアラインサーバＮＬ２上の単一ボリュームの障害または完全なシステム障害が生じた場合、データは、第１のニアラインサーバＮＬ１を使用して、迅速に復元されることが可能である。データ復元が完了すると、レプリケーションソフトウェアは、データボリュームを自動的に再同期して、レプリケーションが再び始まる。このようにして、活性のニアラインサーバ上のクリティカルなエンタープライズデータおよびアーカイブデータが、常に保護される。

一次サーバＳ１が復旧させられると、第２のニアラインサーバＮＬ２は、第２のニアラインサーバＮＬ２のレプリカデータが、一次サーバＳ１に伝播される、またはコピーされる高速フェイルバック１４０Ｘを実行することができる。第１のニアラインサーバＮＬ１が、活性になるように昇格させられ、活性になると、すべてのクライアント１０２を一次サーバＳ１に再ホーミング１１５して、クライアント１０２の再起動の後、サーバサービスの継続性が、図７Ａに関連して前述したとおり、一次サーバＳ１を介して、クライアントデバイス１０２によるサービスへのアクセスを自動的に再確立１１０することにより、保たれるようにする。代替として、一次サーバＳ１が復旧した後、第１のニアラインサーバＮＬ１は、一次サーバＳ１へのレプリカデータのリダイレクトされた復元１４０Ｂを実行することができる。自動的サービス保存は、複数の地理的に異なるサイトにまたがることが可能である。このことは、ニアラインサーバなどの複数の機構を組み込むことが可能であり、前述したとおり、データ保護アプリケーションにおいてデータをトランスポートするため、格納するため、および後処理するために使用される機構を組み込み、拡張することが可能である。自動的サービス保存の分散の結果、エンタープライズデータは、サーバ障害、データセンタ障害、およびサイト障害を含む可能性がある破局的障害に対して障害許容力がある。そのような障害が存在する場合、ＳＰＳが、データの最新のコピーを戻すこと、および／または置換サーバの展開を円滑にすることにより、クライアントおよびアプリケーションへの直接のサービス保存を円滑にすることができる可能性がある。このサービス保存には、他のエンタープライズコンポーネントの協力がかかわることが可能であり、あるいは、これらのフェイルオーバ動作およびフェイルバック動作をトランスペアレントにするプロキシの導入、あるいは何らかの変種または組合せがかかわることが可能である。

したがって、ＳＰＳによって提供されるサーバサイトのサービス保存には、エンタープライズサーバおよびニアラインサーバを含め、すべてのサーバリソースの保護が含まれる。図８Ａは、或る実施形態の下におけるサーバサイトサービス保存を提供するように構成されたＳＰＳ８００のブロック図である。ＳＰＳ８００構成は、各サイトの特定の要件に合致するように構成されることが可能であるという点で、柔軟性がある。ＳＰＳ８００は、第１のサーバＳ１に結合された第１のニアラインサーバＮＬ１と、第２のサーバＳ２に結合された第２のニアラインサーバＮＬ２とを含む。第１のニアラインサーバＮＬ１は、１つまたは複数のネットワーク結合８９９またはネットワーク接続を介して、第２のニアラインサーバＮＬ２に結合される。

第１のサーバＳ１、および第１のニアラインサーバＮＬ１は、一次データセンタＳＩＴＥ１とも呼ばれる、エンタープライズの第１のサーバサイトＳＩＴＥ１のコンポーネントである。一次サーバと呼ばれることが可能であり、複数のサーバを含むことが可能な第１のサーバＳ１は、エンタープライズの一次サーバＳ１として機能し、そのように機能する際に、多数のクライアント１０２にエンタープライズサービスを提供するように結合される。第２のサーバＳ２、および第２のニアラインサーバＮＬ２は、リカバリデータセンタＳＩＴＥ２とも呼ばれる、エンタープライズの第２のサーバサイトＳＩＴＥ２のコンポーネントである。複数のサーバも含むことが可能な第２のサーバＳ２は、エンタープライズのバックアップサーバまたはスタンバイサーバＳ２として機能し、そのように機能する際、多数のクライアント１０２にサーバサービスを提供するように結合または接続されることが可能である。

第１のニアラインサーバＮＬ１は、一次サーバＳ１の通常の動作中、一次サーバＳ１を継続的にシャドーイング８３０する。このため、クライアント１０２は、通常の動作中、一次サーバＳ１に向かわされ８１０、第１のニアラインサーバＮＬ１は、一次サーバＳ１のすべてのデータのレプリカまたはコピーを生成して、格納する。さらに、ＳＰＳ８００のコンポーネントは、第１のニアラインサーバＮＬ１のデータを第２のニアラインサーバＮＬ２上にレプリケート８５０する。レプリケーション８５０は、非同期の、バイトレベルのレプリケーションであることが可能であるが、そのように限定されない。

ＳＰＳ８００は、第２のニアラインサーバ、つまり、スタンバイニアラインサーバＮＬ２を使用して、第１のニアラインサーバＬ１上に存在するすべてのデータを保護する。第１のニアラインサーバＮＬ１上の単一ボリュームの障害または完全なシステム障害が生じた場合、データは、第２のニアラインサーバＮＬ２および第２のサーバＳ２を使用して、迅速に復元されることが可能である。より具体的には、第１のサーバサイトＳＩＴＥ１の検出された障害（例えば、ハードウェア障害および／またはソフトウェア障害）に応答して、第２のニアラインサーバＮＬ２は、活性になるように昇格させられ、エンタープライズサーバサービスのフェイルオーバを管理する。活性になると、第２のニアラインサーバＮＬ２は、一次サーバＳ１の検出された障害（例えば、ハードウェア障害および／またはソフトウェア障害）に応答して、第２のサイトＳＩＴＥ２の第２のサーバＳ２へのリダイレクトされた復元８４０を実行する。リダイレクトされた復元８４０は、第２のニアラインサーバＮＬ２が、一次サーバデータのレプリカを第２のサーバＳ２にコピーする動作を含む。また、第２のニアラインサーバＮＬ２は、クライアント１０２をスタンバイサーバＳ２に再ホーミング８１５して、クライアント１０２の再起動の後、サーバサービスの継続性が、スタンバイサーバＳ２を介して、クライアント１０２によるサービスへのアクセスを自動的に再確立８２０することにより、保たれるようにする。前述したとおり、一次サーバＳ１が復旧させられると、第２のニアラインサーバＮＬ２は、第２のニアラインサーバＮＬ２のレプリカデータが、一次サーバＳ１に伝播される、またはコピーされる高速フェイルバック８４０Ｘを実行することができ、代替として、第２のニアラインサーバＮＬ２は、一次サーバＳ１へのレプリカデータのリダイレクトされた復元も実行することができる。

図８Ｂは、或る実施形態の下における、複数のサーバサイトの１つまたは複数にサービス保存を提供するように構成されたＳＰＳ８００Ｂのブロック図である。ＳＰＳ８００Ｂは、図８Ａに関連して前述した概念を複数のサイトに拡張する。サーバサイトは、いくつかのプロダクションサーバサイト（例えば、サイト１、サイト２、サイト３など）を含む。前述したとおり、各プロダクションサイトＳＩＴＥＸ（ただし、Ｘは、１、２、３などを表す）は、ニアラインサーバＮＬＸに結合された一次サーバＳＸを含む（例えば、サイト１は、ニアラインサーバＮＬ１に結合された一次サーバＳ１を含むといった具合である）。各プロダクションサイトＳＩＴＥＸのニアラインサーバＮＬＸは、一次サーバＳＸの通常の動作中、対応する一次サーバＳＸを継続的にシャドーイング８３０−Ｘする（例えば、ニアラインサーバＮＬ１は、一次サーバＳ１の通常の動作中、一次サーバＳ１をシャドーイング８３０−１するといった具合である）。

サービス保存は、プロダクションサイトＳＩＴＥＸのそれぞれに結合されたリカバリサイトＲＳを使用して提供される。リカバリサイトＲＳは、リカバリニアラインサーバＲＮＬに結合されたリカバリサーバＳＳを含む。ＳＰＳ８００Ｂのコンポーネントは、各サイトのニアラインサーバＮＬＸのデータを、リカバリニアラインサーバＲＮＬ上にレプリケート８５０−Ｘする（例えば、ＳＩＴＥ２のニアラインサーバＮＬ２のデータが、リカバリサイトＲＳにおけるリカバリニアラインサーバＲＮＬ上にレプリケート８５０−２されるといった具合である）。複数のサーバを含むことも可能なリカバリサーバＲＳは、エンタープライズのバックアップサーバまたはスタンバイサーバとして機能し、そのように機能する際、前述したとおり、プロダクションサーバサイトの１つまたは複数のサイトの障害に応答して、プロダクションサイトのいずれか１つ、またはすべてによってサービスを提供される多数のクライアント（図示せず）に、サーバサービスを提供するように結合または接続されることが可能である。

図９は、代替の実施形態の下における、複数の地理的に異なるサイトにわたってサーバサイトサービス保存を提供するように構成された例示的なＳＰＳ９００のブロック図である。ＳＰＳは、前述したとおり、サービス保存とともに、いくつかを挙げると、データ保護、アーカイブ、メールボックス拡張、セルフサービス、ポリシー管理、および監査の役割、コンプライアンス、キーワード警報、法的発見、訴訟支援、ライフサイクル管理、多層ストレージ、災害保護、ビジネス継続性、およびサービスプロキシを含むデータ管理目的で、プロダクションデータのアプリケーション整合性のある一時的レプリカを生成して、保持する。或る実施形態のＳＰＳ９００は、エンタープライズサーバ９０１、エンタープライズクライアント９０２、サーバアクセス９０３、データレプリカもしくはデータサロゲート９０４、シャドーイング９０５、リダイレクション９０６、代替のデータレプリカもしくはデータサロゲート９０７、災害保護９０８、セルフサービス−オーディタアクセス９０９、およびサービスプロキシ保存９１０の１つまたは複数を含む。ＳＰＳ９００の、これらのコンポーネント９０１〜９１０のそれぞれについて、後段で詳細に説明する。

エンタープライズサーバ９０１は、メッセージングサーバ、コラボレーションサーバ、ポータルサーバ、および／またはデータベースサーバを含む多数のタイプおよび／または組合せのサーバを含む。エンタープライズサーバ９０１は、様々な構造化されたデータ、半構造化されたデータ、および構造化されていないデータをホストする。これらのサーバ９０１は、グリッドの個々の、クラスタ化された、レプリケートされた構成要素、仮想化された、および／または任意の組合せまたは変種を含むことが可能である。例示的なエンタープライズサーバ９０１には、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒが含まれるが、本明細書で説明される実施形態は、そのように限定されない。

エンタープライズクライアント９０２には、サーバへのエンドユーザアクセスを提供する多数のタイプおよび／または組合せのクライアントが含まれる。例示的なクライアント９０２が、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｕｔｌｏｏｋであるが、本明細書で説明される実施形態は、そのように限定されない。

エンタープライズクライアント９０２とサーバ９０１の間の対話は、本明細書では、サーバアクセス９０３または通常のアクセスと呼ばれる。Ｍｉｃｒｏｓｏｆｔ（登録商標）ＥｘｃｈａｎｇｅおよびＭｉｃｒｏｓｏｆｔ（登録商標）Ｏｕｔｌｏｏｋを含む例示的なＳＰＳにおいて、サーバアクセス９０３のためのプロトコルは、ＭＡＰＩであることが可能であるが、本明細書で説明される実施形態は、そのように限定されない。他の可能なプロトコルには、ＩＭＡＰ４およびＰＯＰ３が含まれる。

データレプリカまたはデータサロゲート９０４は、本明細書で説明されるとおり、サーバに関する様々なデータ管理ソリューション、およびクライアントに関する強化された能力を可能にする。或る実施形態のＳＰＳ９００は、１つまたは複数の代替のサロゲート９０７を含むことが可能であり、サロゲート９０７は、破局的なサイト災害からプロダクションデータを保護するためにソースから隔離された任意のデータサロゲートのリモートコピーを含む。前述したシャドーイング９０５は、プロダクションエンタープライズデータの現在のコピー９０４またはレプリカを、データサロゲートの中に保持する。レプリカデータは、オプションとして、複数の代替のフォーマットに変換され、メタデータで補われることが可能である。

ＳＰＳ９００は、サーバ９０１および／または代替のサーバが、データ関連の破損または損失を被った後、リダイレクション９０６を使用して、サーバ９０１および／または代替のサーバを復活させる。リダイレクション９０６において使用されるデータには、データサロゲート９０４内にシャドーでホストされるデータが含まれる。「リダイレクト」という用語は、より具体的には、ターゲットサーバが、オリジナルのサーバとは異なる場合に使用され、ターゲットとオリジナルが同一である場合に使用される用語は、「復元」である。

災害保護９０８とは、ＳＰＳ９００が、破局的なサイト災害が生じた場合に、ビジネス業務をサポートするために、データおよび／またはサービスを復元する能力を指す。セルフサービス−オーディタアクセス９０９は、クライアント９０２が、データサロゲート９０４への直接の、ただし、セキュリティで保護されたアクセスを有する能力を含み、例えば、このアクセス９０９には、いくつかを挙げると、エンドユーザの履歴アーカイブへのエンドユーザアクセス、および履歴メッセージング情報を処理する必要があるオーディタが含まれる。サービスプロキシ保存９１０に関して、これは、データサロゲート９０４におけるプロダクションデータのアプリケーション整合性のあるコピーの存在を指し、あるいは代替のサロゲート９０７の１つが、信頼性、スケール、または効率を高めるために、ＳＰＳ９００によるシャドーサーバ、プロキシサーバ、または置換サーバの元のサービスもしくは動作のデリバリを円滑にする。

発送をログ記録するニアラインサーバの組合せは、データサロゲートを生成する。一般に、或る実施形態では、一次サーバは、前述したとおり、ニアラインサーバに結合され、先書きログを生成している。ニアラインサーバは、それらのログ記録を受け取り、それらのログ記録を、以前に受け取られた一次サーバデータベースのベースラインコピーに適用する。ニアラインサーバによって、それらのログ記録がデータに適用された結果は、アプリケーション整合性のあるデータサロゲートである。このように、ログ発送を使用して、何らかのイベント、または事前定義されたスケジュールに基づいて定期的に更新されるデータのシャドーコピーが、生成され、または作成されて、保持される。一部の形態の従来のログ発送とは異なり、或る実施形態のデータ管理アプリケーションは、シャドーコピーが更新されている間に、シャドーコピーを同時に操作することができる。ニアラインサーバまたはログ発送を使用して本明細書で提供されるデータサロゲーションの説明は、データサロゲーションは、様々な他の技術を使用して実施されてもよいので、単に例に過ぎない。

データサロゲーションが、ニアラインサーバを使用して実施される場合、ニアラインサーバは、単一のマシンに限定されず、スケーラビリティおよびフォールトトレランスのために機能の特殊化と負荷分散の様々な組合せを提供する複数のマシンが関与する分散システムを含むことが可能である。さらに、ニアラインシステムのためのストレージは、必ずしも単一のストレージシステムではない可能性があり、場合により、均質な機能、および異質な機能（データ管理、データ解析、ブリック抽出、索引付きオブジェクトリポジトリ、フルテキスト索引付け、データマイニングなどの）のために、ストレージエリアネットワーク（ＳＡＮ）を使用する、ストレージデバイスの集合を含むことが可能である。さらに、ニアラインサーバは、ニアラインサーバの障害許容力、ならびにニアラインサーバがホストしているデータの利用可能性を促進するために、ローカルでレプリケートされることが可能である。

図１０は、或る実施形態の下における、複数の地理的に異なるサイトにわたってサーバサイトサービス保存を提供するように構成された例示的なＳＰＳ１０００のブロック図である。メッセージングサーバが、この実施例において使用されるが、概念は、そのように限定されず、他のタイプのアプリケーションサーバに拡張されることが可能である。単一のクライアント１００２、および単一のメッセージングサーバＭ１だけが示されているが、このＳＰＳ１０００は、より多くの数のクライアントおよびサーバに拡張されることが可能である。この実施例において、サービス保存には、例として、適切なネットワークを介するデータレプリケーションが含まれる。また、或る実施形態のＳＰＳ１０００は、２つのピアサーバ（例えば、ニアラインサーバ）が、サービス保存のために互いを活用しているように、双方向のレプリケーションも含むことが可能である。これは、代替の実施形態において、ｎ方向のレプリケーションにさらに拡張されることが可能であり、ただし、「ｎ」は、任意の恣意的な数を表し、相互接続性は、メッシュ、ツリー、グラフの任意の恣意的な組合せ、ならびにその他の変種および組合せを含むトポロジを適宜、使用することが可能である。さらに、フェイルオーバおよびフェイルバックを、クライアント、サーバ、その他の関連したエンタープライズコンポーネント、および／またはコンポーネントの何らかの変種もしくは組合せにトランスペアレントにするように機能する、オプションのプロキシが、存在してもよい。

図１１は、別の代替の実施形態の下におけるサーバサイトサービス保存を提供するように構成された別の例示的なＳＰＳ１１００のブロック図である。ネットワーク構成は、Ａｃｔｉｖｅ ＳｉｔｅおよびＳｔａｎｄｂｙ Ｓｉｔｅを含むが、１つのＡｃｔｉｖｅ Ｓｉｔｅ、および１つのＳｔａｎｄｂｙ Ｓｉｔｅには限定されない。ネットワーク接続は、クライアント（クライアント１、クライアント２、クライアント３、クライアント４など）をＡｃｔｉｖｅ ＳｉｔｅおよびＳｔａｎｄｂｙ Ｓｉｔｅに結合する。Ａｃｔｉｖｅ Ｓｉｔｅは、ドメインコントローラＡ−ＤＣ、メッセージング−コラボレーションサーバＡ−ＥＳ（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ）、ニアラインサーバＡ−ＮＰ（例えば、Ｍｉｍｏｓａ Ｓｙｓｔｅｍｓ，Ｉｎｃ．のＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒ）、ニアラインデータベースサーバＡ−ＮＰＤＢ（例えば、Ｍｉｍｏｓａ Ｓｙｓｔｅｍｓ，Ｉｎｃ．のＮｅａｒＰｏｉｎｔ（商標）Ｄａｔａｂａｓｅ Ｓｅｒｖｅｒ）、クライアントウェブアクセスＡ−ＯＷＡ（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｕｔｌｏｏｋ Ｗｅｂ Ａｃｃｅｓｓ）、および公開フォルダサーバＡ−ＰＦの１つまたは複数を含む。同様に、Ｓｔａｎｄｂｙ Ｓｉｔｅも、ドメインコントローラＳ−ＤＣ、メッセージング−コラボレーションサーバＳ−ＥＳ（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ）、ニアラインサーバＳ−ＮＰ（例えば、Ｍｉｍｏｓａ Ｓｙｓｔｅｍｓ，Ｉｎｃ．のＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒ）、ニアラインデータベースサーバＳ−ＮＰＤＢ（例えば、Ｍｉｍｏｓａ Ｓｙｓｔｅｍｓ，Ｉｎｃ．のＮｅａｒＰｏｉｎｔ（商標）Ｄａｔａｂａｓｅ Ｓｅｒｖｅｒ）、クライアントウェブアクセスＳ−ＯＷＡ（例えば、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｏｕｔｌｏｏｋ Ｗｅｂ Ａｃｃｅｓｓ）、および公開フォルダサーバＳ−ＰＦの１つまたは複数を含む。

或る実施形態のＳＰＳの動作の例が、後段で説明される。この実施例のＳＰＳは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｅｘｃｈａｎｇｅ ＳｅｒｖｅｒおよびＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｅｒと一体化されたＭｉｍｏｓａ ＮｅａｒＰｏｉｎｔ（商標）ソリューションを含む実施形態である。動作の際、ネットワーク管理者またはシステム管理者が、事前構成され、正しいことが試験されているリカバリポリシーを使用して、「シングルクリック」で、Ｅｘｃｈａｎｇｅサービスの完全なリカバリを開始する。以下に、ＳＰＳを使用するポリシー構成およびリカバリ動作を説明する。

ＳＰＳは、多くの自動化されたフィーチャ、ウィザード駆動のメニュー、および事前試験を含み、信頼できるＥｘｃｈａｎｇｅリカバリを確実にする。一次データセンタにおいてサーバ損失イベント、サイト損失イベント、またはデータ損失イベントが生じた場合、管理者は、ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅにおける「ワンクリック」を介して、Ｅｘｃｈａｎｇｅサービスの完全なリカバリを開始することができる。以下は、ＳＰＳを使用する総合的なＥｘｃｈａｎｇｅリカバリの説明である。

この実施例は、ＥｘｃｈａｎｇｅメッセージングサービスおよびＮｅａｒＰｏｉｎｔ（商標）サービス（ＳＰＳ）が、完全に動作しており、Ｅｘｃｈａｎｇｅ ＳｅｒｖｅｒとＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒが、一次データセンタに並置されているものと想定する。ＮｅａｒＰｏｉｎｔ（商標）は、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒを管理しており、完全なシャドーコピーを完成させており、継続的な保護プロセスが、ＮｅａｒＰｏｉｎｔ（商標）Ｌｏｇ Ｓｈｉｐｐｉｎｇを使用して実行されている。さらに、ＮｅａｒＰｏｉｎｔ（商標）は、セルフサービスアクセス、保有および処分、Ｍａｉｌｂｏｘ Ｅｘｔｅｎｓｉｏｎ、およびデータ排除に関する管理者によって定義されたポリシーを使用して、アーカイブを管理している。

災害リカバリステップが、ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅを使用して、ＮｅａｒＰｏｉｎｔ（商標）サーバペアを確立することを始め、レプリケーションを始める。管理者は、ＮｅａｒＰｏｉｎｔ（商標）サーバを「右クリック」して、「ＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒ Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ Ｓｅｔｕｐ」を選択することができる。図１２は、或る実施形態の下における、ＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒ ＤＲ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ）セットアップの選択の例示的なスクリーンショットである。

次に、管理者は、リカバリサイトにおいてＮｅａｒＰｏｉｎｔ（商標）の名前を入力する。図１３は、或る実施形態の下におけるＮｅａｒＰｏｉｎｔ（商標）サーバ名エントリの例示的なスクリーンショットである。このＮｅａｒＰｏｉｎｔ（商標）サーバ名は、一般に、リカバリサイトに配置された第２のＮｅａｒＰｏｉｎｔ（商標）サーバの名前である。１つだけのＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒが展開されている場合、そのサーバの名前が、入力される。この実施例では、レプリケーションサービスは、全く展開されない。

ＮｅａｒＰｏｉｎｔ（商標）は、それら２つのＮｅａｒＰｏｉｎｔ（商標）サーバの比較を実行して、それらのサーバの構成が一致することを確かめる。試験に合格したことを確認するＣｈｅｃｋ Ｒｅｐｏｒｔが、発行される。図１４は、或る実施形態の下における例示的なＮｅａｒＰｏｉｎｔ（商標）Ｃｈｅｃｋ Ｒｅｐｏｒｔである。管理者が、「終了（ｆｉｎｉｓｈ）」を選択すると、レプリケーションソフトウェアは、ＮｅａｒＰｏｉｎｔ（商標）サーバの継続的な保護を始める。すべてのレプリケーションソフトウェア設定は、ＮｅａｒＰｏｉｎｔ（商標）によってトランスペアレントに管理される。

管理者は、Ｅｘｃｈａｎｇｅ Ｓｅｒｅｖｅｒリカバリペアを構成することにより、Ｅｘｃｈａｎｇｅ ＤＲをセットアップすることを続ける。図１５は、或る実施形態の下におけるＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒリカバリペア構成の例示的なスクリーンショットである。このスクリーンにおいて、一次Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒの名前が、入力され、スタンバイＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒの名前が、入力される。ＮｅａｒＰｏｉｎｔ（商標）は、スタンバイサーバが、正しく構成されていることを自動的に検証し、一致するＳｔｏｒａｇｅ Ｇｒｏｕｐ名およびＭａｉｌｂｏｘ Ｓｔｏｒｅ名について調べ、Ｍａｉｌｂｏｘ Ｓｔｏｒｅが、デフォルトのシステムメールボックスを除いて空であることを確認する。スタンバイサーバの名前は、一次Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒと一致することを要求されず、このことは、同一のＤｏｍａｉｎにおいて同一の名前を有する２つのサーバを管理するという要件なしに、スタンバイサーバを迅速にセットアップすることを可能にする。

セットアップが完了すると、管理者は、レプリケーションサービス（展開される場合）およびＥｘｃｈａｎｇｅリカバリペアを、ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅ上のステータスページを使用して監視する。災害が生じた場合、ＮｅａｒＰｏｉｎｔ（商標）コンソール上で作業して、Ａｄｍｉｎｉｓｔｒａｔｏｒは、前述したとおり、完全なＥｘｃｈａｎｇｅリカバリを開始する。

管理者は、ＤＲ Ｓｔａｔｕｓページを使用して、ＮｅａｒＰｏｉｎｔ（商標）レプリケーションサービスおよびＥｘｃｈａｎｇｅリカバリペアを含むＤＲ構成のステータスを監視する。図１６は、或る実施形態の下におけるＮｅａｒＰｏｉｎｔ（商標）ＤＲ Ｓｔａｔｕｓページの実施例である。ページの最上部分は、Ｅｘｃｈａｎｇｅリカバリペア、および対応する構成ステータスを含む、またはリストアップする。緑の光は、構成が、正しく、リカバリの準備ができていることを示す。ページの中央部分または中心部分は、レプリケーション動作、およびそれらの動作のステータスをリストアップする。ページの最下部分は、ＤＲ ＮｅａｒＰｏｉｎｔ（商標）ステータスをリストアップする。

災害が、一次Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒを襲った場合、管理者は、ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅを使用して、Ｅｘｃｈａｎｇｅリカバリを開始する。レプリケートされるＮｅａｒＰｏｉｎｔ（商標）サーバを伴う構成において、リカバリは、リカバリサイトにおけるＮｅａｒＰｏｉｎｔ（商標）サーバの使用を含み、さもなければ、リカバリは、単一のＮｅａｒＰｏｉｎｔ（商標）サーバの使用を含む。管理者は、ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅにログオンした後、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒの「右クリック」を使用して、Ｅｘｃｈａｎｇｅのリカバリを開始し、「Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ Ｆａｉｌｏｖｅｒ」を選択する。図１７は、或る実施形態の下におけるＤｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ Ｆａｉｌｏｖｅｒの選択の例示的なスクリーンショットである。

管理者によってリカバリが開始されると、ＮｅａｒＰｏｉｎｔ（商標）は、すべてのＥｘｃｈａｎｇｅサーバの自動的リカバリを実行する。或る実施形態における自動的リカバリは、Ｅｘｃｈａｎｇｅデータベースを復元すること、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙの中のメールボックスを再バインドすること、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒを再構成すること、Ｐｕｂｌｉｃ Ｆｏｌｄｅｒ Ｓｔｏｒｅを再ホーミングすること、Ｅｘｃｈａｎｇｅ ＲｏｌｅおよびＥｘｃｈａｎｇｅ Ｓｅｒｖｉｃｅを識別すること、システムメールボックスをクリーンアップして、重複アイテムを除去すること、およびＥｘｃｈａｎｇｅ Ｓｅｒｖｉｃｅを再開することの１つまたは複数を含む。これらのリカバリ動作は、エンドユーザに対する電子メールサービスを復元する。

Ｅｘｃｈａｎｇｅ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｒを使用してクリーンアップされる必要があるＥｘｃｈａｎｇｅサービスは、リカバリが完了すると、ＮｅａｒＰｏｉｎｔ（商標）によってリストアップされる。図１８は、或る実施形態の下における、クリーニングを要求するＥｘｃｈａｎｇｅサービスのリストを示す例示的なスクリーンショットである。クリーニングを要求するＥｘｃｈａｎｇｅサービスの例が、Ｒｅｃｉｐｉｅｎｔ Ｕｐｄａｔｅ ＳｅｒｖｉｃｅおよびＯｆｆｌｉｎｅ Ａｄｄｒｅｓｓ Ｌｉｓｔ（Ｇｌｏｂａｌ Ａｄｄｒｅｓｓ）セットアップであり、これらはともに、サイト特有である。ＮｅａｒＰｏｉｎｔ（商標）Ａｄｍｉｎｉｓｔｒａｔｏｒ Ｃｏｎｓｏｌｅを使用して、管理者は、新たなＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒを管理し、完全なシャドーコピーおよびログ発送を使用して、データ保護を始める。Ｅｘｃｈａｎｇｅリカバリは、現時点で、完了であり、ユーザは、スタンバイＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒ上で実行される、すべての電子メールを含むユーザのメールボックスへのアクセスを有する。また、ユーザは、ＯｕｔｌｏｏｋおよびＯＷＡ（Ｏｕｔｌｏｏｋ Ｗｅｂ Ａｃｃｅｓｓ）を介して、ユーザのすべてのアーカイブ電子メールへのアクセスも引き続き有する。

前述したＳＰＳは、エンタープライズサーバにインストールされたエージェントソフトウェアの必要なしに、エンタープライズサーバに関する、より高いレベルの災害復旧保護を提供する。ＳＰＳは、エンタープライズサーバ上のデータと、アーカイブされたデータをともに保護する自動化された災害復旧ソリューションを提供する。ＳＰＳは、ニアラインサーバデータをリモートサイトに継続的にレプリケートしながら、エンタープライズデータをローカルで継続的に保護する。ＳＰＳのリカバリプロセスは、自動化され、事前構成されて、迅速な信頼できる結果をもたらして、迅速に、最小限のデータ損失、および最小限のサービス混乱しか伴わずに、エンタープライズサービスが復元されるようにする。

従来のエンタープライズリカバリソリューションは、ファイルシステムレプリケーションソリューションとしての遺伝的形質に基づき、エンタープライズデータをレプリケートすることに、ファイルベースまたはブロックベースのアプローチをとる。破損が、エンタープライズデータベースを襲った場合、これらのソリューションは、その破損をスタンバイサーバに即時にレプリケートして、そのサーバが破損する。これに対して、ＳＰＳは、シャドーイングを使用して、リカバリの準備のできたエンタープライズデータの整合性のあるコピーを常に有して、破損したデータが、スタンバイサーバに到達することを防止するという点で、アプリケーションインテリジェントである。

さらに、従来のエンタープライズリカバリソリューションは、既存のエンタープライズ環境に非常に侵襲的であり、バイトレベルの変更を傍受するカーネルレベルのエージェントがインストールされることを要求する。カーネルレベルのエージェントは、通常、エンタープライズサーバによってサポートされず、サービス中断のリスクを高める。これらの従来のシステムとは異なり、ＳＰＳは、ニアラインサーバ上で実行され、エージェントソフトウェアでエンタープライズ環境を阻害しない。このため、既存のエンタープライズ環境は、そのままであり、すべての災害保護は、ニアラインサーバ上で、「オフホスト」で管理される。

さらに、サーバリカバリソリューションは、通常、時間がかかり、誤りが生じやすく、保守するのが高価な手動のステップ、およびスクリプトに依拠する。これに対して、ＳＰＳは、サーバおよびサイトに関する完全に自動化されたリカバリソリューションを提供する。完全にプログラム的な方法を使用して、システム管理者は、或る実施形態のＳＰＳに対して「ワンクリック」で、完全なサーバリカバリおよび／またはサイトリカバリを実行することができる。したがって、システム管理者は、前もってセットアップされた災害復旧ポリシーが、事前試験され、直ちに実行される準備ができていることを知っていて、より迅速に、より確信をもって、リカバリを実行することができる。したがって、ＳＰＳは、管理するのが非常に複雑であり、費用がかかる、非常に高価である可能性があるアレイベースの、信頼できないホストベースの災害復旧ソリューションの使用を実質的に回避することができる。

或る実施形態のＳＰＳは、１つまたは複数の生きているサーバを継続的にシャドーイングすることを含む方法を含む。或る実施形態の生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態の方法は、シャドーイング中にデータのレプリカを生成して、保持することを含む。或る実施形態の方法は、その１つまたは複数の生きているサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して、クライアントに対するサービスを自動的に復元することを含む。或る実施形態の復元することは、スタンバイサーバにデータのレプリカをコピーすることを含む。

或る実施形態の生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のレプリカは、生きているサーバのデータの１つまたは複数の部分を含む。

或る実施形態のデータのレプリカは、シャドーイング中に少なくとも１つのニアラインサーバ上に格納される。或る実施形態のデータのレプリカは、ニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のシャドーイングは、ニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持する。或る実施形態のシャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態の少なくとも１つのニアラインサーバは、スタンバイサーバと並置されたニアラインサーバを含む。或る実施形態のスタンバイサーバは、生きているサーバの地理的ロケーションに配置される。或る実施形態のスタンバイサーバは、生きているサーバとは異なる地理的ロケーションに配置される。

或る実施形態の復元することは、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つことを含む。
或る実施形態の復元することは、スタンバイサーバ上のデータに対応するサービスを再開することを含む。

或る実施形態の復元することは、ディレクトリサービスにおけるメールボックスをスタンバイサーバに再バインドすることを含む。
或る実施形態の復元することは、クライアントを再ホーミングすることを含む。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む。或る実施形態のデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納される。或る実施形態の方法は、第１のニアラインサーバからのレプリカを第２のニアラインサーバにレプリケートすることを含む。或る実施形態のデータのレプリカは、第１のニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のデータのレプリカは、第２のニアラインサーバからスタンバイサーバにコピーされる。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトにスタンバイサーバと並置された第２のニアラインサーバとを含む。或る実施形態のデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納される。或る実施形態の方法は、第１のニアラインサーバから第２のニアラインサーバにレプリカをレプリケートすることを含む。或る実施形態のデータのレプリカは、第１のニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のデータのレプリカは、第２のニアラインサーバからスタンバイサーバにコピーされる。

或る実施形態の生きているサーバは、１つまたは複数のメッセージング−コラボレーションサーバを含む。或る実施形態のデータは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む。

或る実施形態の生きているサーバは、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒを含む。或る実施形態のクライアントに対するサービスを復元することは、Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙの中のメールボックスを再バインドすることを含む。或る実施形態のクライアントに対するサービスを復元することは、Ｅｘｃｈａｎｇｅ役割およびＥｘｃｈａｎｇｅサービスを識別することを含む。或る実施形態におけるクライアントに対するサービスを復元することは、Ｅｘｃｈａｎｇｅ役割およびＥｘｃｈａｎｇｅサービスを再ホーミングすることを含む。或る実施形態のクライアントに対するサービスを復元することは、Ｐｕｂｌｉｃ Ｆｏｌｄｅｒ Ｓｔｏｒｅを再ホーミングすることを含む。或る実施形態のクライアントに対するサービスを復元することは、システムメールボックスから重複アイテムを除去することを含む。或る実施形態のクライアントに対するサービスを復元することは、Ｅｘｃｈａｎｇｅサービスを再開することを含む。或る実施形態のクライアントに対するサービスを復元することは、クライアントに対するＯｕｔｌｏｏｋサービスを復元することを含み、Ｏｕｔｌｏｏｋは、電子メール−個人情報管理アプリケーションである。或る実施形態のクライアントに対するサービスを復元することは、クライアントに対する信号安定ルーティングプロトコルサービスを復元することを含む。

或る実施形態のレプリカを生成して、保持することは、１つまたは複数の生きているサーバから受信されたデータ、およびそのデータの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成することを含む。或る実施形態の方法は、１つまたは複数の生きているサーバから受信された少なくとも１つのさらなるデータ変更の情報を使用して、少なくとも１つのデータサロゲートを更新することを含む。或る実施形態の更新することは、少なくとも１つのさらなるデータ変更の受信時、複数のさらなるデータ変更の受信の後、および少なくとも１つのさらなるデータ変更に対する処理動作の後の少なくともいずれかにおいて実行される。

或る実施形態の１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、ボイスオーバＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌサーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む。

或る実施形態のレプリカを生成して、保持することは、スタンバイサーバ上へのデータのホストベースのレプリケーションを含む。
或る実施形態のホストベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のホストベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのデータを書き込むことを含む。

或る実施形態のサービスを自動的に復元することは、スタンバイサーバが、障害の生じた、生きているサーバのＩＤおよびアドレスを引き受けることを含む。
或る実施形態のレプリカを生成して、保持することは、スタンバイサーバ上へのデータのストレージベースのレプリケーションを含む。或る実施形態のストレージベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のストレージベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのローカルストレージのデータをレプリケートすることを含む。或る実施形態のサービスを自動的に復元することは、スタンバイサーバが、障害の生じた、生きているサーバのＩＤおよびアドレスを引き受けることを含む。

或る実施形態のレプリカを生成して、保持することは、複数のクライアントのデータを、生きているサーバのコンポーネント、およびスタンバイサーバのコンポーネントに書き込むことを含む。或る実施形態のサービスを自動的に復元することは、クライアントを、障害が生じた、生きているサーバから、データが書き込まれたスタンバイサーバに切り替えることを含む。

或る実施形態のＳＰＳは、１つまたは複数のサーバを継続的にシャドーイングすることを含む方法を含む。或る実施形態のサーバは、複数のクライアントにサービスを提供するアプリケーションデータを含む。或る実施形態の方法は、シャドーイング中に、少なくとも１つのニアラインサーバ上にアプリケーションデータのコピーを生成して、保持することを含む。或る実施形態の方法は、１つまたは複数のサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して、クライアントに対するサービスを復元することを含む。或る実施形態の復元することは、ニアラインサーバからスタンバイサーバにアプリケーションデータのコピーをコピーすることを含む。

或る実施形態のサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のレプリカは、サーバ、ニアラインサーバ、およびスタンバイサーバの１つまたは複数のサーバのデータの１つまたは複数の部分を含む。

或る実施形態のシャドーイングは、ニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持する。或る実施形態のシャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態の復元することは、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つことを含む。
或る実施形態の復元することは、スタンバイサーバ上で、データに対応するサービスを再開することを含む。

或る実施形態の復元することは、ディレクトリサービス内のメールボックスをスタンバイサーバに再バインドすることを含む。
或る実施形態の復元することは、クライアントを再ホーミングすることを含む。

或る実施形態のサーバは、１つまたは複数のメッセージング−コラボレーションサーバを含む。
或る実施形態のデータは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む。

或る実施形態のサーバは、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒを含む。
或る実施形態のレプリカを生成して、保持することは、１つまたは複数のサーバから受信されたデータ、およびそのデータの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成することを含む。

或る実施形態の方法は、１つまたは複数のサーバから受信された少なくとも１つのさらなるデータ変更の情報を使用して、少なくとも１つのデータサロゲートを更新することを含む。

或る実施形態の更新することは、少なくとも１つのさらなるデータ変更の受信時、複数のさらなるデータ変更の受信の後、および少なくとも１つのさらなるデータ変更に対する処理動作の後の少なくともいずれかにおいて実行される。

或る実施形態のＳＰＳは、１つまたは複数の生きているサーバを継続的にシャドーイングすることを含む方法を含む。或る実施形態の生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態の方法は、シャドーイング中にデータのレプリカを生成して、保持することを含む。或る実施形態の方法は、１つまたは複数の生きているサーバの検出された障害に応答して、クライアントに対するサービスを自動的に復元することを含む。或る実施形態の復元することは、１つまたは複数の生きているサーバにデータのレプリカをコピーすることを含む。

或る実施形態のＳＰＳは、処理システムにおいて実行されると、１つまたは複数のサーバを継続的にシャドーイングすることにより、サービス保存を提供する実行可能命令を含むコンピュータ可読メディアを含み、サーバは、複数のクライアントにサービスを提供するアプリケーションデータを含む。或る実施形態の命令は、実行されると、シャドーイング中に、少なくとも１つのニアラインサーバ上でアプリケーションデータのレプリカを生成して、保持する。或る実施形態の命令は、実行されると、１つまたは複数のサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して、クライアントに対するサービスを自動的に復元し、サービスを復元することは、ニアラインサーバからスタンバイサーバにアプリケーションデータのコピーをコピーすることを含む。

或る実施形態のサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のレプリカは、サーバ、ニアラインサーバ、およびスタンバイサーバの１つまたは複数のサーバのデータの１つまたは複数の部分を含む。

或る実施形態のシャドーイングは、ニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持する。或る実施形態のシャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態の復元することは、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つこと、スタンバイサーバ上で、データに対応するサービスを再開すること、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすること、クライアントを再ホーミングすることの１つまたは複数を含む。

或る実施形態のレプリカを生成して、保持することは、１つまたは複数のサーバから受信されたデータ、およびそのデータの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成することを含む。

或る実施形態の命令は、実行されると、１つまたは複数のサーバから受信された少なくとも１つのさらなるデータ変更の情報を使用して、少なくとも１つのデータサロゲートを更新し、この更新は、少なくとも１つのさらなるデータ変更の受信時、複数のさらなるデータ変更の受信の後、および少なくとも１つのさらなるデータ変更に対する処理動作の後の少なくともいずれかにおいて実行される。

或る実施形態のＳＰＳは、複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバに結合された１つまたは複数のニアラインサーバを含むシステムを含む。或る実施形態のシステムは、ニアラインサーバに結合され、データのレプリカを生成して、保持することにより、生きているサーバを継続的にシャドーイングするように構成されたエンジンを含む。或る実施形態のエンジンは、１つまたは複数の生きているサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して、クライアントに対するサービスを自動的に復元するように構成される。或る実施形態の復元することは、スタンバイサーバにデータのレプリカをコピーすることを含む。

或る実施形態のシステムは、１つまたは複数のニアラインサーバに結合された少なくとも１つのネットワークを含む。或る実施形態の少なくとも１つのネットワークは、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、およびＳＡＮ（ストレージエリアネットワーク）を含む。

或る実施形態のシステムの生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のシステムのシャドーイングは、１つまたは複数のニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持し、シャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態のシステムの復元することは、１つまたは複数のニアラインサーバが、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つことを含む。

或る実施形態のシステムの復元することは、１つまたは複数のニアラインサーバが、スタンバイサーバ上で、データに対応するサービスを再開することを含む。
或る実施形態のシステムの復元することは、１つまたは複数のニアラインサーバが、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすることを含む。

或る実施形態のシステムの復元することは、１つまたは複数のニアラインサーバが、クライアントを再ホーミングすることを含む。
或る実施形態のシステムの少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む。或る実施形態のシステムのデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納され、データのレプリカは、第１のニアラインサーバから第２のニアラインサーバにレプリケートされる。或る実施形態のシステムのデータのレプリカは、第１のニアラインサーバからスタンバイサーバに伝播されることを含む。或る実施形態のシステムのデータのレプリカは、第２のニアラインサーバからスタンバイサーバに伝播されることを含む。

或る実施形態のシステムの少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトにスタンバイサーバと並置された第２のニアラインサーバとを含む。或るシステムのデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納され、データのレプリカは、第１のニアラインサーバから第２のニアラインサーバにレプリケートされる。或る実施形態のシステムのデータのレプリカは、第１のニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のシステムのデータのレプリカは、第２のニアラインサーバからスタンバイサーバにコピーされる。

或る実施形態のシステムのデータは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む。
或る実施形態のシステムの１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ、ボイスオーバＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌサーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む。

或る実施形態のシステムのレプリカを生成して、保持することは、スタンバイサーバ上へのデータのホストベースのレプリケーションを含む。或る実施形態のシステムのホストベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のシステムのホストベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のシステムのサービスを自動的に復元することは、スタンバイサーバが、障害の生じた、生きているサーバのＩＤおよびアドレスを引き受けることを含む。或る実施形態のシステムのレプリカを生成して、保持することは、スタンバイサーバ上へのデータのストレージベースのレプリケーションを含む。或る実施形態のシステムのストレージベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のシステムのストレージベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのローカルストレージのデータをレプリケートすることを含む。或る実施形態のシステムのサービスを自動的に復元することは、スタンバイサーバが、障害の生じた、生きているサーバのＩＤおよびアドレスを引き受けることを含む。

或る実施形態のシステムは、クライアント、生きているサーバ、およびスタンバイサーバの間に結合された少なくとも１つのプロキシを含む。或る実施形態のシステムのレプリカを生成して、保持することは、プロキシが、複数のクライアントのデータを、生きているサーバの少なくとも１つのサーバのコンポーネント、およびスタンバイサーバの少なくとも１つのサーバのコンポーネントに書き込むことを含む。或る実施形態のシステムのサービスを自動的に復元することは、プロキシが、クライアントを、障害が生じた、生きているサーバから、データが書き込まれたスタンバイサーバに切り替えることを含む。

或る実施形態のＳＰＳは、処理システムにおいて実行されると、１つまたは複数の生きているサーバを継続的にシャドーイングすることにより、サービス保存を提供する実行可能命令を含むコンピュータ可読メディアを含む。或る実施形態の生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態のサービス保存を提供することは、シャドーイング中にデータのレプリカを生成して、保持することを含む。或る実施形態のサービス保存を提供することは、１つまたは複数の生きているサーバの検出された障害に応答して、１つまたは複数のスタンバイサーバを使用して、クライアントに対するサービスを自動的に復元することを含む。或る実施形態の復元することは、スタンバイサーバにデータのレプリカをコピーすることを含む。

或る実施形態のＳＰＳは、１つまたは複数の生きているサーバを継続的にシャドーイングすることを含む方法を含み、生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態の方法は、シャドーイング中にデータのレプリカを生成して、保持することを含む。或る実施形態の方法は、１つまたは複数のスタンバイサーバのイベントに応答して、１つまたは複数のスタンバイサーバにデータのレプリカを自動的に転送することを含み、イベントは、生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、そのアプリケーションの第２のバージョンへの移行を含む移行イベントを含む。

或る実施形態の方法は、データのレプリカをホストするスタンバイサーバを活性化することを含む。
或る実施形態の方法は、第２のバージョンの下で、活性化されたスタンバイサーバの動作を評価することを含む。

或る実施形態の方法は、活性化されたスタンバイサーバをスタンバイ状態に戻すことを含む。
或る実施形態の方法は、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することを含み、活性化されたスタンバイサーバは、データのレプリカをホストしている。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つことを含む。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、スタンバイサーバ上のデータに対応するサービスを再開することを含む。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすることを含む。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、クライアントを再ホーミングすることを含む。或る実施形態のクライアントにサービスを提供することは、１つまたは複数の生きているサーバを使用することを含む。

或る実施形態の生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のレプリカは、生きているサーバのデータの１つまたは複数の部分を含む。

或る実施形態のデータのレプリカは、シャドーイング中に少なくとも１つのニアラインサーバ上に格納される。或る実施形態のデータのレプリカは、ニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のシャドーイングは、ニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持し、シャドーイングは、データの完全な保全性および整合性を保つ。或る実施形態の少なくとも１つのニアラインサーバは、スタンバイサーバと並置されたニアラインサーバを含む。或る実施形態のスタンバイサーバは、生きているサーバの地理的ロケーション、および生きているサーバとは異なる地理的ロケーションの１つまたは複数のロケーションに配置される。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む。或る実施形態のデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納される。或る実施形態の方法は、第１のニアラインサーバから第２のニアラインサーバにレプリカをレプリケートすることを含む。或る実施形態のデータのレプリカは、第１のニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のデータのレプリカは、第２のニアラインサーバからスタンバイサーバにコピーされる。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトにスタンバイサーバと並置された第２のニアラインサーバとを含む。或るシステムのデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納される。或る実施形態の方法は、第１のニアラインサーバから第２のニアラインサーバにレプリカをレプリケートすることを含む。或る実施形態のデータのレプリカは、第１のニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のデータのレプリカは、第２のニアラインサーバからスタンバイサーバにコピーされる。

或る実施形態の生きているサーバは、１つまたは複数のメッセージング−コラボレーションサーバを含む。
或る実施形態のデータは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む。

或る実施形態のレプリカを生成して、保持することは、１つまたは複数の生きているサーバから受信されたデータ、およびそのデータの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成することを含む。或る実施形態の方法は、１つまたは複数の生きているサーバから受信された少なくとも１つのさらなるデータ変更の情報を使用して、少なくとも１つのデータサロゲートを更新することを含み、更新することは、少なくとも１つのさらなるデータ変更の受信時、複数のさらなるデータ変更の受信の後、および少なくとも１つのさらなるデータ変更に対する処理動作の後の少なくともいずれかにおいて実行される。

或る実施形態の１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、ボイスオーバＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌサーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む。

或る実施形態のレプリカを生成して、保持することは、スタンバイサーバ上へのデータのホストベースのレプリケーション、およびスタンバイサーバ上へのデータのストレージベースのレプリケーションの１つまたは複数を含む。或る実施形態のホストベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のホストベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のストレージベースのレプリケーションは、生きているサーバのローカルストレージに、生きているサーバのデータを書き込むことを含む。或る実施形態のストレージベースのレプリケーションは、スタンバイサーバのリモートストレージに、生きているサーバのローカルストレージのデータをレプリケートすることを含む。

或る実施形態のレプリカを生成して、保持することは、複数のクライアントのデータを、生きているサーバのコンポーネント、およびスタンバイサーバのコンポーネントに書き込むことを含む。

或る実施形態の第１のバージョンは、アプリケーションの元のバージョンであり、第２のバージョンは、そのアプリケーションの新たなバージョンである。
或る実施形態の第１のバージョンは、アプリケーションの新たなバージョンであり、第２のバージョンは、そのアプリケーションの元のバージョンである。

或る実施形態のＳＰＳは、１つまたは複数の生きているサーバを継続的にシャドーイングすることを含む方法を含み、生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態の方法は、シャドーイング中にデータのレプリカを生成して、保持することを含む。或る実施形態の方法は、１つまたは複数のスタンバイサーバのイベントに応答して、データのレプリカを１つまたは複数のスタンバイサーバに自動的に伝播させることを含み、イベントは、移行イベントおよびドリルイベントの１つまたは複数を含む。

或る実施形態の移行イベントは、生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、そのアプリケーションの第２のバージョンへの移行を含む。或る実施形態の第１のバージョンは、アプリケーションの元のバージョンであり、第２のバージョンは、そのアプリケーションの新たなバージョンである。或る実施形態の第１のバージョンは、アプリケーションの新たなバージョンであり、第２のバージョンは、そのアプリケーションの元のバージョンである。

或る実施形態のドリルイベントは、データのレプリカをホストするスタンバイサーバを活性化することを含む。或る実施形態のドリルイベントは、活性化されたスタンバイサーバの動作を評価することを含む。或る実施形態の方法は、活性化されたスタンバイサーバをスタンバイ状態に戻すことを含む。

或る実施形態の方法は、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することを含み、活性化されたスタンバイサーバは、データのレプリカをホストしている。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つことを含む。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、スタンバイサーバ上のデータに対応するサービスを再開すること、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすること、およびクライアントを再ホーミングすることの１つまたは複数を含む。或る実施形態の方法は、１つまたは複数の生きているサーバを使用して、クライアントにサービスを提供することを含む。

或る実施形態の生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のレプリカは、生きているサーバのデータの１つまたは複数の部分を含む。

或る実施形態のデータのレプリカは、シャドーイング中に少なくとも１つのニアラインサーバ上に格納される。或る実施形態のデータのレプリカは、ニアラインサーバからスタンバイサーバにコピーされる。或る実施形態のシャドーイングは、ニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持し、シャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態の少なくとも１つのニアラインサーバは、第１のニアラインサーバと、第２のニアラインサーバとを含む。或る実施形態の方法は、シャドーイング中に第１のニアラインサーバ上にデータのレプリカを格納すること、および第１のニアラインサーバから第２のニアラインサーバにレプリカをレプリケートすることを含む。或る実施形態のデータのレプリカは、第１のニアラインサーバ、および第２のニアラインサーバの１つまたは複数からスタンバイサーバにコピーされる。

或る実施形態のレプリカを生成して、保持することは、１つまたは複数の生きているサーバから受信されたデータ、およびそのデータの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成することを含む。

或る実施形態のＳＰＳは、処理システムにおいて実行されると、１つまたは複数の生きているサーバを継続的にシャドーイングすることにより、サーババージョン移行を提供する実行可能命令を含むコンピュータ可読メディアを含み、生きているサーバは、複数のクライアントにサービスを提供するデータを含む。或る実施形態の命令は、実行されると、シャドーイング中にデータのレプリカを生成して、保持する。或る実施形態の命令は、実行されると、１つまたは複数のスタンバイサーバのイベントに応答して、１つまたは複数のスタンバイサーバにデータのレプリカを自動的に伝播させる。或る実施形態のイベントは、移行イベントおよびドリルイベントの１つまたは複数を含む。

或る実施形態のＳＰＳは、複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバに結合された１つまたは複数のニアラインサーバを含むシステムを含む。或る実施形態のシステムは、ニアラインサーバに結合され、データのレプリカを生成して、保持することにより、生きているサーバを継続的にシャドーイングするように構成されたエンジンを含む。或る実施形態のエンジンは、１つまたは複数のスタンバイサーバのイベントに応答して、１つまたは複数のスタンバイサーバにデータのレプリカを自動的に転送するように構成される。或る実施形態のイベントは、移行イベントおよびドリルイベントの１つまたは複数を含む。

或る実施形態の移行イベントは、生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、そのアプリケーションの第２のバージョンへの移行を含む。

或る実施形態のドリルイベントは、データのレプリカをホストするスタンバイサーバを活性化することを含む。或る実施形態のドリルイベントは、活性化されたスタンバイサーバの動作を評価することを含む。或る実施形態のシステムは、活性化されたスタンバイサーバをスタンバイ状態に戻すことを含む。

或る実施形態のエンジンは、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供するように構成され、活性化されたスタンバイサーバは、データのレプリカをホストしている。或る実施形態のエンジンは、活性化されたスタンバイサーバを使用して、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つように構成される。或る実施形態の、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供することは、スタンバイサーバ上のデータに対応するサービスを再開すること、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすること、およびクライアントを再ホーミングすることの１つまたは複数を含む。或る実施形態のエンジンは、１つまたは複数の生きているサーバを使用して、クライアントにサービスを提供するようにも構成される。

或る実施形態の生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のシステムは、１つまたは複数のニアラインサーバ、および１つまたは複数の生きているサーバに結合された少なくとも１つのネットワークを含み、少なくとも１つのネットワークは、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、およびＳＡＮ（ストレージエリアネットワーク）の１つまたは複数を含む。

或る実施形態のエンジンは、１つまたは複数のニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持することにより、シャドーイングするように構成され、シャドーイングすることは、データの完全な保全性および整合性を保つ。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む。或る実施形態のデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納され、データのレプリカは、第１のニアラインサーバから第２のニアラインサーバにレプリケートされる。或る実施形態のデータのレプリカは、第１のニアラインサーバと第２のニアラインサーバの１つまたは複数からスタンバイサーバに伝播される。

或る実施形態の少なくとも１つのニアラインサーバは、第１のサイトに生きているサーバと並置された第１のニアラインサーバと、第２のサイトにスタンバイサーバと並置された第２のニアラインサーバとを含む。或る実施形態のデータのレプリカは、シャドーイング中に第１のニアラインサーバ上に格納され、データのレプリカは、第１のニアラインサーバから第２のニアラインサーバにレプリケートされる。或る実施形態のデータのレプリカは、第１のニアラインサーバと第２のニアラインサーバの１つまたは複数からスタンバイサーバにコピーされる。

或る実施形態のデータは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む。
或る実施形態の１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ、ボイスオーバＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌサーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む。

或る実施形態のＳＰＳは、複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバに結合された１つまたは複数のニアラインサーバを含むシステムを含む。或る実施形態のシステムは、ニアラインサーバに結合され、データのレプリカを生成して、保持することにより、生きているサーバを継続的にシャドーイングするように構成されたエンジンを含む。或る実施形態のエンジンは、１つまたは複数のスタンバイサーバのイベントに応答して、１つまたは複数のスタンバイサーバにデータのレプリカを自動的に転送するように構成される。或る実施形態のイベントは、生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、そのアプリケーションの第２のバージョンへの移行を含む移行イベントを含む。

或る実施形態のエンジンは、活性化されたスタンバイサーバを使用して、クライアントにサービスを提供するように構成され、活性化されたスタンバイサーバは、データのレプリカをホストしている。或る実施形態のエンジンは、活性化されたスタンバイサーバを使用して、クライアントによるサービスへのアクセスを自動的に再確立することにより、サービスの継続性を保つように構成される。或る実施形態の活性化されたスタンバイサーバを使用してクライアントにサービスを提供することは、スタンバイサーバ上のデータに対応するサービスを再開すること、ディレクトリサービスの中のメールボックスをスタンバイサーバに再バインドすること、およびクライアントを再ホーミングすることの１つまたは複数を含む。或る実施形態のエンジンは、１つまたは複数の生きているサーバを使用して、クライアントにサービスを提供するようにも構成される。

或る実施形態の生きているサーバとスタンバイサーバのそれぞれは、識別され、独立にアドレス指定される。
或る実施形態のエンジンは、１つまたは複数のニアラインサーバ上に、ほぼリアルタイムでデータのレプリカを生成して、保持することによってシャドーイングするように構成され、シャドーイングは、データの完全な保全性および整合性を保つ。

或る実施形態の１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ、ボイスオーバＩｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌサーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む。

本明細書で説明されるＳＰＳの態様は、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、ＰＡＬ（プログラマブルアレイ論理）デバイス、電気的にプログラマブルな論理−メモリデバイスなどのＰＬＤ（プログラマブル論理デバイス）、および標準のセルベースのデバイス、ならびにＡＳＩＣ（特定用途向け集積回路）を含め、様々な回路にプログラミングされた機能として実施されることが可能である。ＳＰＳの態様を実施するための他のいくつかの可能性には、以下が含まれる。すなわち、メモリ（ＥＥＰＲＯＭ（電気的に消去可能なプログラマブル読み取り専用メモリ）などの）を有するマイクロコントローラ、組み込み型マイクロプロセッサ、ファームウェア、ソフトウェアなどである。さらに、ＳＰＳの態様は、ソフトウェアベースの回路エミュレーション、ディスクリートのロジック（順次ロジックおよび組合せロジック）、カスタムデバイス、ファジイ（ニューラル）ロジック、量子デバイス、および以上のデバイスタイプの任意のタイプの混成を有するマイクロプロセッサで実体化されることが可能である。もちろん、基礎をなすデバイス技術は、様々なコンポーネントタイプ、例えば、ＣＭＯＳ（相補形金属酸化膜半導体）のようなＭＯＳＦＥＴ（金属酸化物半導体電界効果トランジスタ）技術、ＥＣＬ（エミッタ結合ロジック）のようなバイポーラ技術、ポリマー技術（例えば、シリコン共役ポリマー、および金属共役ポリマー金属構造）、アナログ−デジタル混合などで提供されることが可能である。

本明細書で開示される様々なシステムおよび方法のコンポーネントは、それらのコンポーネントの動作、レジスタ転送、論理コンポーネント、トランジスタ、レイアウト形状、および／またはその他の特徴の点で、様々なコンピュータ可読メディアで実体化されたデータおよび／または命令として、コンピュータ支援設計ツールを使用して記述され、表される（または表現される）ことが可能であることに留意されたい。そのようなフォーマットされたデータおよび／または命令が実現されることが可能なコンピュータ可読メディアには、様々な形態の不揮発性記憶メディア（例えば、光学記憶メディア、磁気記憶メディア、または半導体記憶メディア）、ならびに無線、光、または有線のシグナリングメディア、あるいはこれらの任意の組合せを介して、そのようなフォーマットされたデータおよび／または命令を転送するのに使用されることが可能な搬送波が含まれるが、以上には限定されない。

搬送波による、そのようなフォーマットされたデータおよび／または命令の転送の例には、１つまたは複数のデータ転送プロトコル（例えば、ＨＴＴＰ、ＦＴＰ、ＳＭＴＰなど）を介した、インターネットおよび／または他のコンピュータネットワークを介する転送（アップロード、ダウンロード、電子メールなど）が含まれるが、以上には限定されない。１つまたは複数のコンピュータ可読メディアを介してコンピュータシステム内で受信されると、前述したシステムおよび方法の、そのようなデータベースの、かつ／または命令ベースの表現は、他の１つまたは複数のコンピュータプログラムの実行と一緒に、コンピュータシステム内部の処理エンティティ（例えば、１つまたは複数のプロセッサ）によって処理されることが可能である。

文脈が、そうでないことを明確に要求しない限り、この説明の全体にわたり、「含む」という言葉、およびそれに類する言葉は、排他的、または網羅的な意味ではなく、包含的な意味で、つまり、「〜を含むが、〜に限定されない」という意味で解釈されるべきである。単数または複数を使用する言葉は、それぞれ、複数または単数も含む。さらに、「本明細書で」、「以下に」、「前段で」、「後段で」という言葉、および類似する意味の言葉は、本出願の特定の部分ではなく、本出願全体を参照する。「または」という言葉が、２つ以上のアイテムのリストに関連して使用される場合、その言葉は、その言葉の以下の解釈のすべてを範囲に含む。すなわち、リストの中のアイテムのいずれか、リストの中のアイテムのすべて、およびリストの中のアイテムの任意の組合せである。

ＳＰＳの実施形態の以上の説明は、網羅的であること、または説明されるシステムおよび方法を、開示される形態そのものに限定することを意図していない。ＳＰＳの特定の実施形態、および実施例が、例示の目的で本明細書において説明されているが、当業者には認識されるとおり、データを管理するための他のシステムおよび方法の範囲内で、様々な均等の変形形態が可能である。本明細書で提供されるＳＰＳの教示は、前述したシステムおよび方法に関してだけでなく、他の処理システムおよび処理方法にも適用されることが可能である。

前述した様々な実施形態の要素および動作は、さらなる実施形態をもたらすように組み合わせられることが可能である。前段の詳細な説明に鑑みて、以上、およびその他の変更が、ＳＰＳに行われることが可能である。

一般に、添付の特許請求の範囲において、使用される用語は、本明細書および特許請求の範囲で開示される特定の実施形態にＳＰＳを限定するものと解釈されるべきではなく、特許請求の範囲の下で機能するすべての処理システムを含むように解釈されなければならない。したがって、ＳＰＳは、本開示によって限定されず、代わりに、ＳＰＳの範囲は全面的に、特許請求の範囲によって決定されるべきである。

ＳＰＳのいくつかの態様が、いくつかの請求項形態で提示されるが、本発明人は、任意の数の請求項形態におけるＳＰＳの様々な態様を企図している。したがって、本発明人は、本出願を出願した後、さらなる請求項を追加して、ＳＰＳの他の態様に関する、そのようなさらなる請求項形態を追求する権利を保留する。

或る実施形態の下におけるＳＰＳ（Ｓｅｒｖｉｃｅ Ｐｒｅｓｅｒｖａｔｉｏｎ Ｓｙｓｔｅｍ）を示すブロック図である。 或る実施形態の下におけるサービス保存を示す流れ図である。 或る実施形態の下におけるサービス確認を含むサービス保存を示す流れ図である。 或る実施形態の下における、ニアラインサーバが、一次サーバと同一のサイトに配置されるＳＰＳを示すブロック図である。 或る実施形態の下における、ニアラインサーバが、スタンバイサーバと同一のサイトに配置されるＳＰＳを示すブロック図である。 或る実施形態の下における、サービス保存のためにアプリケーション整合性のあるデータコピーを提供するニアラインサーバを示すＳＰＳのブロック図である。 或る実施形態の下におけるローカルサービス保存またはリモートサービス保存を含むＳＰＳを示す図である。 或る実施形態の下における、ニアラインサーバが、スタンバイニアラインサーバ上でレプリケートされるＳＰＳを示すブロック図である。 或る実施形態の下における、スタンバイサーバが、一次サーバの障害の後に一次サービスプロバイダの役割をしている場合のＳＰＳを示すブロック図である。 或る実施形態の下におけるサーバサイトサービス保存を提供するように構成されたＳＰＳを示すブロック図である。 或る実施形態の下における、複数のサーバサイトの１つまたは複数にサービス保存を提供するように構成されたＳＰＳを示すブロック図である。 或る実施形態の下における、複数の地理的に異なるサイトにわたってサーバサイトサービス保存を提供するように構成された例示的なＳＰＳを示すブロック図である。 代替の実施形態の下における、複数の地理的に異なるサイトにわたってサーバサイトサービス保存を提供するように構成された例示的なＳＰＳを示すブロック図である。 代替の実施形態の下におけるサーバサイトサービス保存を提供するように構成された別の例示的なＳＰＳを示すブロック図である。 或る実施形態の下におけるＮｅａｒＰｏｉｎｔ（商標）Ｓｅｒｖｅｒ ＤＲ（Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ）セットアップの選択の例示的なスクリーンショットである。 或る実施形態の下におけるＮｅａｒＰｏｉｎｔ（商標）サーバ名エントリの例示的なスクリーンショットである。 或る実施形態の下における例示的なＮｅａｒＰｏｉｎｔ（商標）Ｃｈｅｃｋ Ｒｅｐｏｒｔを示す図である。 或る実施形態の下における例示的なＮｅａｒＰｏｉｎｔ（商標）を使用するＥｘｃｈａｎｇｅ Ｓｅｒｖｅｒリカバリペア構成の例示的なスクリーンショットである。 或る実施形態の下における例示的なＮｅａｒＰｏｉｎｔ（商標）ＤＲ Ｓｔａｔｕｓページを示す図である。 或る実施形態の下における例示的なＮｅａｒＰｏｉｎｔ（商標）を使用するＤｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ Ｆａｉｌｏｖｅｒの選択の例示的なスクリーンショットである。 或る実施形態の下における、クリーニングを要求するＥｘｃｈａｎｇｅサービスのＮｅａｒＰｏｉｎｔ（商標）リストを示す例示的なスクリーンショットである。

Claims (85)

1. 複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバを継続的にシャドーイングするステップと、
   前記シャドーイングするステップ中に前記データのレプリカを生成して、保持するステップと、
   １つまたは複数のスタンバイサーバに、前記１つまたは複数のスタンバイサーバのイベントに応答して、前記データの前記レプリカを自動的に転送するステップとを含み、前記イベントは、前記生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、前記アプリケーションの第２のバージョンへの移行を含む移行イベントを含む方法。
2. 前記データの前記レプリカをホストする前記スタンバイサーバを活性化するステップをさらに含む請求項１に記載の方法。
3. 前記第２のバージョンの下で前記活性化されたスタンバイサーバの動作を評価するステップをさらに含む請求項２に記載の方法。
4. 前記活性化されたスタンバイサーバをスタンバイ状態に戻すステップをさらに含む請求項３に記載の方法。
5. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップをさらに含み、前記活性化されたスタンバイサーバは、前記データの前記レプリカをホストしている請求項２に記載の方法。
6. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記クライアントによる前記サービスへのアクセスを自動的に再確立することにより、前記サービスの継続性を保つステップを含む請求項５に記載の方法。
7. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記スタンバイサーバ上の前記データに対応するサービスを再開するステップを含む請求項５に記載の方法。
8. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、ディレクトリサービスの中のメールボックスを前記スタンバイサーバに再バインドするステップを含む請求項５に記載の方法。
9. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記クライアントを再ホーミングするステップを含む請求項５に記載の方法。
10. 前記１つまたは複数の生きているサーバを使用して、前記クライアントに前記サービスを提供するステップをさらに含む請求項５に記載の方法。
11. 前記生きているサーバと前記スタンバイサーバのそれぞれは、識別され、独立にアドレス指定される請求項１に記載の方法。
12. 前記レプリカは、前記生きているサーバの前記データの１つまたは複数の部分を含む請求項１に記載の方法。
13. 前記データの前記レプリカは、前記シャドーイングするステップ中に少なくとも１つのニアラインサーバ上に格納される請求項１に記載の方法。
14. 前記データの前記レプリカは、前記ニアラインサーバから前記スタンバイサーバにコピーされる請求項１３に記載の方法。
15. 前記シャドーイングするステップは、前記ニアラインサーバ上に、ほぼリアルタイムで前記データの前記レプリカを生成して、保持し、前記シャドーイングするステップは、前記データの完全な保全性および整合性を保つ請求項１３に記載の方法。
16. 前記少なくとも１つのニアラインサーバは、前記スタンバイサーバと並置されたニアラインサーバを含む請求項１３に記載の方法。
17. 前記スタンバイサーバは、前記生きているサーバの地理的ロケーション、および前記生きているサーバとは異なる地理的ロケーションの１つまたは複数のロケーションに配置される請求項１６に記載の方法。
18. 前記少なくとも１つのニアラインサーバは、第１のサイトに前記生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む請求項１に記載の方法。
19. 前記データの前記レプリカは、前記シャドーイングするステップ中に前記第１のニアラインサーバ上に格納される請求項１８に記載の方法。
20. 前記第１のニアラインサーバから前記第２のニアラインサーバに前記レプリカをレプリケートするステップをさらに含む請求項１９に記載の方法。
21. 前記データの前記レプリカは、前記第１のニアラインサーバから前記スタンバイサーバにコピーされる請求項２０に記載の方法。
22. 前記データの前記レプリカは、前記第２のニアラインサーバから前記スタンバイサーバにコピーされる請求項２０に記載の方法。
23. 前記少なくとも１つのニアラインサーバは、第１のサイトに前記生きているサーバと並置された第１のニアラインサーバと、第２のサイトに前記スタンバイサーバと並置された第２のニアラインサーバとを含む請求項１に記載の方法。
24. 前記データの前記レプリカは、前記シャドーイングするステップ中に前記第１のニアラインサーバ上に格納される請求項２３に記載の方法。
25. 前記第１のニアラインサーバから前記第２のニアラインサーバに前記レプリカをレプリケートするステップをさらに含む請求項２４に記載の方法。
26. 前記データの前記レプリカは、前記第１のニアラインサーバから前記スタンバイサーバにコピーされる請求項２５に記載の方法。
27. 前記データの前記レプリカは、前記第２のニアラインサーバから前記スタンバイサーバにコピーされる請求項２６に記載の方法。
28. 前記生きているサーバは、１つまたは複数のメッセージング−コラボレーションサーバを含む請求項１に記載の方法。
29. 前記データは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む請求項２８に記載の方法。
30. 前記レプリカを生成して、保持するステップは、前記１つまたは複数の生きているサーバから受信された前記データ、および前記データの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成するステップを含む請求項１に記載の方法。
31. 前記１つまたは複数の生きているサーバから受信された少なくとも１つのさらなるデータ変更の情報を使用して、前記少なくとも１つのデータサロゲートを更新するステップをさらに含み、前記更新するステップは、前記少なくとも１つのさらなるデータ変更の受信時、複数のさらなるデータ変更の受信の後、および前記少なくとも１つのさらなるデータ変更に対する処理動作の後の少なくともいずれかにおいて実行される請求項３０に記載の方法。
32. 前記１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、ボイスオーバ・インターネット・プロトコル・サーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む請求項１に記載の方法。
33. 前記レプリカを生成して、保持するステップは、前記スタンバイサーバ上への前記データのホストベースのレプリケーション、および前記スタンバイサーバ上への前記データのストレージベースのレプリケーションの１つまたは複数を含む請求項１に記載の方法。
34. ホストベースのレプリケーションは、
    前記生きているサーバのデータを、前記生きているサーバのローカルストレージに書き込むステップと、
    前記生きているサーバのデータを、前記スタンバイサーバのリモートストレージに書き込むステップとを含む請求項３３に記載の方法。
35. ストレージベースのレプリケーションは、
    前記生きているサーバのデータを、前記生きているサーバのローカルストレージに書き込むステップと、
    前記生きているサーバの前記ローカルストレージのデータを、前記スタンバイサーバのリモートストレージにレプリケートするステップとを含む請求項３３に記載の方法。
36. 前記レプリカを生成して、保持するステップは、前記複数のクライアントのデータを、生きているサーバのコンポーネント、およびスタンバイサーバのコンポーネントに書き込むステップを含む請求項１に記載の方法。
37. 前記第１のバージョンは、前記アプリケーションの元のバージョンであり、前記第２のバージョンは、前記アプリケーションの新たなバージョンである請求項１に記載の方法。
38. 前記第１のバージョンは、前記アプリケーションの新たなバージョンであり、前記第２のバージョンは、前記アプリケーションの元のバージョンである請求項１に記載の方法。
39. 複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバを継続的にシャドーイングするステップと、
    前記シャドーイングするステップ中に前記データのレプリカを生成して、保持するステップと、
    １つまたは複数のスタンバイサーバに、前記１つまたは複数のスタンバイサーバのイベントに応答して、前記データの前記レプリカを自動的に伝播させるステップとを含み、前記イベントは、移行イベントおよびドリルイベントの１つまたは複数を含む方法。
40. 前記移行イベントは、前記生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、前記アプリケーションの第２のバージョンへの移行を含む請求項３９に記載の方法。
    
41. 前記第１のバージョンは、前記アプリケーションの元のバージョンであり、前記第２のバージョンは、前記アプリケーションの新たなバージョンである請求項４０に記載の方法。
42. 前記第１のバージョンは、前記アプリケーションの新たなバージョンであり、前記第２のバージョンは、前記アプリケーションの元のバージョンである請求項４０に記載の方法。
43. 前記ドリルイベントは、
    前記データの前記レプリカをホストする前記スタンバイサーバを活性化するステップと、
    前記活性化されたスタンバイサーバの動作を評価するステップとを含む請求項３９に記載の方法。
44. 前記活性化されたスタンバイサーバをスタンバイ状態に戻すステップを含む請求項４３に記載の方法。
45. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップをさらに含み、前記活性化されたスタンバイサーバは、前記データの前記レプリカをホストしている請求項３９に記載の方法。
46. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記クライアントによる前記サービスへのアクセスを自動的に再確立することにより、前記サービスの継続性を保つステップを含む請求項４５に記載の方法。
47. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記スタンバイサーバ上の前記データに対応するサービスを再開するステップ、ディレクトリサービスの中のメールボックスを前記スタンバイサーバに再バインドするステップ、および前記クライアントを再ホーミングするステップの１つまたは複数を含む請求項４５に記載の方法。
48. 前記１つまたは複数の生きているサーバを使用して、前記クライアントに前記サービスを提供するステップをさらに含む請求項４５に記載の方法。
49. 前記生きているサーバと前記スタンバイサーバのそれぞれは、識別され、独立にアドレス指定される請求項３９に記載の方法。
50. 前記レプリカは、前記生きているサーバの前記データの１つまたは複数の部分を含む請求項３９に記載の方法。
51. 前記データの前記レプリカは、前記シャドーイングするステップ中に少なくとも１つのニアラインサーバ上に格納される請求項３９に記載の方法。
52. 前記データの前記レプリカは、前記ニアラインサーバから前記スタンバイサーバにコピーされる請求項５１に記載の方法。
53. 前記シャドーイングするステップは、前記ニアラインサーバ上に、ほぼリアルタイムで前記データの前記レプリカを生成して、保持し、前記シャドーイングするステップは、前記データの完全な保全性および整合性を保つ請求項５１に記載の方法。
54. 前記少なくとも１つのニアラインサーバは、第１のニアラインサーバと、第２のニアラインサーバとを含む請求項３９に記載の方法。
55. 前記シャドーイングするステップ中に前記第１のニアラインサーバ上に前記データの前記レプリカを格納するステップと、前記第１のニアラインサーバから前記第２のニアラインサーバに前記レプリカをレプリケートするステップとをさらに含む請求項５４に記載の方法。
56. 前記データの前記レプリカは、前記第１のニアラインサーバと前記第２のニアラインサーバの１つまたは複数から前記スタンバイサーバにコピーされる請求項５５に記載の方法。
57. 前記レプリカを生成して、保持するステップは、前記１つまたは複数の生きているサーバから受信された前記データ、および前記データの複数のデータ変更の情報を使用して、少なくとも１つのデータサロゲートを生成するステップを含む請求項３９に記載の方法。
58. 処理システムにおいて実行されると、
    複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバを継続的にシャドーイングするステップ、
    前記シャドーイングするステップ中に前記データのレプリカを生成して、保持するステップ、および
    １つまたは複数のスタンバイサーバに、前記１つまたは複数のスタンバイサーバのイベントに応答して、前記データの前記レプリカを自動的に伝播させるステップによってサーババージョン移行をサポートする実行可能命令を含み、前記イベントは、移行イベントおよびドリルイベントの１つまたは複数を含むコンピュータ可読メディア。
59. 複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバに結合された１つまたは複数のニアラインサーバと、
    前記ニアラインサーバに結合され、データのレプリカを生成して、保持することにより、前記生きているサーバを継続的にシャドーイングするように構成されたエンジンとを含み、前記エンジンは、１つまたは複数のスタンバイサーバに、前記１つまたは複数のスタンバイサーバのイベントに応答して、前記データの前記レプリカを自動的に転送するように構成され、前記イベントは、移行イベントおよびドリルイベントの１つまたは複数を含むシステム。
60. 前記移行イベントは、前記生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、前記アプリケーションの第２のバージョンへの移行を含む請求項５９に記載のシステム。
61. 前記ドリルイベントは、
    前記データの前記レプリカをホストする前記スタンバイサーバを活性化するステップと、
    前記活性化されたスタンバイサーバの動作を評価するステップとを含む請求項５９に記載のシステム。
62. 前記活性化されたスタンバイサーバをスタンバイ状態に戻すステップを含む請求項６１に記載のシステム。
63. 前記エンジンは、前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するように構成され、前記活性化されたスタンバイサーバは、前記データの前記レプリカをホストしている請求項５９に記載のシステム。
64. 前記エンジンは、前記活性化されたスタンバイサーバを使用して、前記クライアントによる前記サービスへのアクセスを自動的に再確立することにより、前記サービスの継続性を保つように構成される請求項６３に記載のシステム。
65. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記スタンバイサーバ上の前記データに対応するサービスを再開するステップ、ディレクトリサービスの中のメールボックスを前記スタンバイサーバに再バインドするステップ、および前記クライアントを再ホーミングするステップの１つまたは複数を含む請求項６３に記載のシステム。
66. 前記エンジンは、前記１つまたは複数の生きているサーバを使用して、前記クライアントに前記サービスを提供するようにも構成される請求項６３に記載のシステム。
67. 前記生きているサーバと前記スタンバイサーバのそれぞれは、識別され、独立にアドレス指定される請求項５９に記載のシステム。
68. 前記１つまたは複数のニアラインサーバ、および前記１つまたは複数の生きているサーバに結合された少なくとも１つのネットワークをさらに含み、前記少なくとも１つのネットワークは、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、およびＳＡＮ（ストレージエリアネットワーク）の１つまたは複数を含む請求項５９に記載のシステム。
69. 前記エンジンは、前記１つまたは複数のニアラインサーバ上に、ほぼリアルタイムで前記データの前記レプリカを生成して、保持することにより、シャドーイングするように構成され、前記シャドーイングするステップは、前記データの完全な保全性および整合性を保つ請求項５９に記載のシステム。
70. 前記少なくとも１つのニアラインサーバは、第１のサイトに前記生きているサーバと並置された第１のニアラインサーバと、第２のサイトに配置された第２のニアラインサーバとを含む請求項５９に記載のシステム。
71. 前記データの前記レプリカは、前記シャドーイングするステップ中に前記第１のニアラインサーバ上に格納され、前記データの前記レプリカは、前記第１のニアラインサーバから前記第２のニアラインサーバにレプリケートされる請求項７０に記載のシステム。
72. データのレプリカは、前記第１のニアラインサーバと前記第２のニアラインサーバの１つまたは複数から前記スタンバイサーバに伝播される請求項７１に記載のシステム。
73. 前記少なくとも１つのニアラインサーバは、第１のサイトに前記生きているサーバと並置された第１のニアラインサーバと、第２のサイトに前記スタンバイサーバと並置された第２のニアラインサーバとを含む請求項５９に記載のシステム。
74. 前記データの前記レプリカは、前記シャドーイングするステップ中に前記第１のニアラインサーバ上に格納され、前記データの前記レプリカは、前記第１のニアラインサーバから前記第２のニアラインサーバにレプリケートされる請求項７３に記載のシステム。
75. 前記データの前記レプリカは、前記第１のニアラインサーバと前記第２のニアラインサーバの１つまたは複数から前記スタンバイサーバにコピーされる請求項７４に記載のシステム。
76. 前記データは、アプリケーションデータ、データベース、ストレージグループ、メールボックスデータ、およびサーバデータの１つまたは複数を含む請求項５９に記載のシステム。
77. 前記１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、エクスチェンジ・サーバ（Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ）、ボイスオーバ・インターネット・プロトコル・サーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む請求項５９に記載のシステム。
78. 複数のクライアントにサービスを提供するデータを含む１つまたは複数の生きているサーバに結合された１つまたは複数のニアラインサーバと、
    前記ニアラインサーバに結合され、データのレプリカを生成して、保持することにより、前記生きているサーバを継続的にシャドーイングするように構成されたエンジンとを含むシステムであって、
    前記エンジンは、１つまたは複数のスタンバイサーバに、前記１つまたは複数のスタンバイサーバのイベントに応答して、前記データの前記レプリカを自動的に転送するように構成され、前記イベントは、前記生きているサーバによってホストされる少なくとも１つのアプリケーションの第１のバージョンから、前記アプリケーションの第２のバージョンへの移行を含む移行イベントを含むシステム。
79. 前記エンジンは、前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するように構成され、前記活性化されたスタンバイサーバは、前記データの前記レプリカをホストしている請求項７８に記載のシステム。
80. 前記エンジンは、前記活性化されたスタンバイサーバを使用して、前記クライアントによる前記サービスへのアクセスを自動的に再確立することにより、前記サービスの継続性を保つように構成される請求項７９に記載のシステム。
81. 前記活性化されたスタンバイサーバを使用して、前記クライアントに前記サービスを提供するステップは、前記スタンバイサーバ上の前記データに対応するサービスを再開するステップ、ディレクトリサービスの中のメールボックスを前記スタンバイサーバに再バインドするステップ、および前記クライアントを再ホーミングするステップの１つまたは複数を含む請求項７９に記載のシステム。
82. 前記エンジンは、前記１つまたは複数の生きているサーバを使用して、前記クライアントに前記サービスを提供するようにも構成される請求項７９に記載のシステム。
83. 前記生きているサーバと前記スタンバイサーバのそれぞれは、識別され、独立にアドレス指定される請求項７８に記載のシステム。
84. 前記エンジンは、前記１つまたは複数のニアラインサーバ上に、ほぼリアルタイムで前記データの前記レプリカを生成して、保持することにより、シャドーイングするように構成され、前記シャドーイングするステップは、前記データの完全な保全性および整合性を保つ請求項７８に記載のシステム。
85. 前記１つまたは複数の生きているサーバは、ローカルサーバ、リモートサーバ、データベースサーバ、メッセージングサーバ、電子メールサーバ、インスタントメッセージングサーバ、エクスチェンジ・サーバ（Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ）、ボイスオーバ・インターネット・プロトコル・サーバ、コラボレーションサーバ、ポータル、ＣＲＭ（顧客関係管理）サーバ、ＥＲＰ（エンタープライズリソース計画）サーバ、ビジネスツービジネスサーバ、およびコンテンツ管理サーバの１つまたは複数を含む請求項７８に記載のシステム。

Images