JP2016530656A - 分散型ディザスタリカバリファイル同期サーバシステム - Google Patents

Abstract

例示的な実装は、サーバからのデータだけでなくサーバに接続されたクライアントからのデータもリカバリすることに向けられる。最終のバックアップの後に作成されたまたは修正されたコンテンツを識別するためのアルゴリズムが、組み入れられている。このアルゴリズムは、また、共用フォルダのためのマウントポイントにおける変更を識別して解明して、情報の漏れを防止する。サーバは、故障から回復すると、クライアントにそれらの次回の接続時におけるリカバリに関して告知する。各クライアントは、次に、そのマウントポイントおよびファイル経路の現在の状態を判断し、それらを、サーバのマウントポイントおよびファイル経路と比較する。比較の後で、クライアントは、マウントポイントの差異を、それらの名称を変更することによって把握して示し、ローカルデータ全体（すべてのファイル、フォルダ、マウントポイント）をサーバに送る。サーバは、これらの差異を調整する。

Description

本開示は、ストレージシステムに関し、さらに詳しくは、ディザスタリカバリの間のサーバ／ストレージシステムのためのファイル同期に関する。

関連する技術では、クライアントネットワークとストレージプロバイダとに関係するストレージ／サーバシステムが存在する。ストレージゲートウェイは、クライアントネットワークから、更新データを、更新されたデータをあるボリュームに記憶するストレージサービスに送る。データは、ローカルデータストアにも記憶される。ローカルデータストアに記憶されたデータに何かが起こる場合には、失われたデータは、ストレージサービスにおけるボリュームに記憶されているデータを用いることにより、リカバリされる。

しかし、関連する技術は、ストレージサービスのディザスタリカバリを考慮しておらず、ストレージサービスにおけるボリュームのリカバリも考慮していない。

本出願の態様は、サーバを含み、このサーバは、複数のクライアントデバイスとのインターフェースとなるように構成されたインターフェースと、リカバリポイントにおいてサーバによって管理される第１のファイルのバージョンに関する情報を記憶するように構成されたメモリと、プロセッサであって、複数のファイルを、それらの複数のファイルを複数のクライアントデバイスにおいて用いることによってサーバにおいてファイルをリカバリするために、複数のクライアントデバイスから受信し、リカバリポイントにおける第１のファイルのバージョンよりも新しいバージョンを有する複数の受信されたファイルの第２のファイルに対して、第２のファイルの１つを第１のファイルの新たなバージョンとして管理し、第２のファイルの別の１つを第２のファイルの先の１つに対するコンフリクトファイルとして管理するように構成されたプロセッサとを含み得る。

本出願の追加的な態様は、サーバを管理するための方法を含む。この方法は、リカバリポイントにおいてサーバによって管理される第１のファイルのバージョンに関する情報を記憶するステップと、複数のファイルを、それらの複数のファイルを複数のクライアントデバイスにおいて用いることによってサーバにおいてファイルをリカバリするために、複数のクライアントデバイスから受信するステップと、リカバリポイントにおける第１のファイルのバージョンよりも新しいバージョンを有する複数の受信されたファイルの第２のファイルに対して、第２のファイルの１つを第１のファイルの新たなバージョンとして管理し、第２のファイルの別の１つを第２のファイルの先の１つに対するコンフリクトファイルとして管理するステップとを含み得る。

本出願の追加的な態様は、サーバを管理するためのコンピュータプログラムを含む。このコンピュータプログラムは、リカバリポイントにおいてサーバによって管理される第１のファイルのバージョンに関する情報を記憶するステップと、複数のファイルを、それらの複数のファイルを複数のクライアントデバイスにおいて用いることによってサーバにおいてファイルをリカバリするために、複数のクライアントデバイスから受信するステップと、リカバリポイントにおける第１のファイルのバージョンよりも新しいバージョンを有する複数の受信されたファイルの第２のファイルに対して、第２のファイルの１つを第１のファイルの新たなバージョンとして管理し、第２のファイルの別の１つを第２のファイルの先の１つに対するコンフリクトファイルとして管理するステップとのための命令を含み得る。

例示的実装が実装され得る例示的システムアーキテクチャの図解である。 例示的実装が実装され得る例示的コンピュータシステムの図解である。 ある例示的実装によるファイルシステムとマウントポイントとの例示的クライアントおよびサーバのビューの図解である。 ある例示的実装による流れ図である。 ある例示的実装による流れ図実行の例の図解である。 ある例示的実装による流れ図実行の例の図解である。 ある例示的実装によるリカバリＰＵＴのための流れ図である。 ある例示的実装によるリカバリＵＰＤＡＴＥのための流れ図である。 図５Ａおよび図５Ｂの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。 図５Ａおよび図５Ｂの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。 図５Ａの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。 図５Ａの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。 図５Ａおよび図５Ｂの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。 図５Ａおよび図５Ｂの例示的実装に基づくクライアントとサーバとの間の例示的対話の図解である。

以下の詳細な説明は、本出願の図面と例示的実装とのさらなる詳細を提供する。複数の図面の間で重複する要素の参照番号と説明とは、見やすくするために、割愛される。説明を通じて用いられる用語は例として提供され、限定のためのものであることは意図されていない。たとえば、「自動的」という用語の使用は、本出願の実装を実践する技術における通常の技量の１つの所望の実装に応じて、それらの実装の一定の態様に対するユーザまたは管理者の制御に関係する完全に自動的なまたは半自動的な実装に関係し得る。また、本明細書で説明される実装は、限定を意図しておらず、所望の実装に応じて、様々な方法での実装が可能である。

本明細書で説明される例示的実装は、ディザスタリカバリ状況におけるサーバ／ストレージシステムのクライアントからのデータリカバリおよび共用フォルダのための単純化されたデータ復元に関係する。

組織は、自らのデータへの連続的なアクセスを有することに依存し得る。したがって、重要なシステムおよびアプリケーションは、システムが故障した場合にデータ損失を最小化するための堅固なディザスタリカバリ計画を必要とし得る。組織化されていない不変のデジタルコンテンツが増加するにつれ、データを管理しバックアップすることは、困難となり得る。分散クライアントサーバシステムと関連する技術分野では、システムにおけるサーバからのデータは、別のシステムに、周期的にバックアップされる。周期的なデータバックアップは、（連続的なデータバックアップと比較すれば）システム性能に最小限の影響を与えるだけであり得るが、データ損失の潜在性を生じさせ、最終のバックアップ以降にシステムに追加されたデータは、どのようなものであっても、故障の後では回復不能となり得る。

図１は、例示的な実装がその上で実装され得る、例示的なシステムアーキテクチャを図解している。このシステムアーキテクチャは、図２に記載されているサーバ２０５を含み得るのであって、そのサーバは、１つまたは複数のデータベースに対応する１つまたは複数のノードを管理するように構成され得る。このサーバは、サーバにおける１つまたは複数のノードによって管理されるデータベースに対応するデータを記憶するための（たとえば、ストレージシステムまたは他の外部ストレージなどの）オブジェクトストレージ１０２を維持し得る。このサーバは、ネットワーク１０１を経由して、１つまたは複数のクライアント（クライアントコンピュータ１００）と対話し得る。クライアントとサーバとは、表現状態転送（ＲＥＳＴ）アプリケーションプログラミングインターフェース（ＡＰＩ）１０３を介して、相互に対話し得る。定常状態の動作の間にサーバと周期的に通信するクライアントが、存在し得る。クライアントは、新たなファイルコンテンツをサーバに送り、更新されたファイルをサーバから受信することによって、サーバとの間でファイルを同期させる。ある与えられたユーザのためのすべてのクライアントが、同じ組のファイルを同期させる。異なるユーザのためのクライアントは、それらのユーザのために、ファイルを同期させる。サーバの詳細は、図２で説明されている。各クライアントは、プロセッサと、メモリと、ストレージドライブとを含んでおり、クライアントにおけるプロセッサは、たとえば図４Ａに説明されているように１つまたは複数の実装を容易化するように構成され得る。

図２は、その上に例示的な実装が実装され得る、例示的なコンピュータシステム２００を図解している。コンピュータシステム２００は、Ｉ／Ｏユニット２３５と、ストレージ２６０（および／またはメモリ）と、当業者に知られているように１つまたは複数のユニットを実行させるように動作可能なプロセッサ２１０とに関係するサーバ２０５を含む。図２に図解されているサーバ２０５は、１つのノードと関係する構成を表現しているが、このサーバは、図１に図解されるように追加的なノードを有することが可能である。サーバ２０５は、ＲＥＳＴインターフェース１０３などのインターフェースを介して、サービスと関連する１つまたは複数のクライアントと対話し得る。本明細書で用いられる「コンピュータ可読媒体」という用語は、実行のためにプロセッサ２１０に命令を提供することに参加する任意の媒体を指しており、限定を意味しないが、光ディスク、磁気ディスク、リードオンリメモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびドライブなどのコンピュータ可読記憶媒体の形式で存在し得、または、電子的情報を記憶するのに適した非一時的な媒体もしくは搬送波などの媒体を含み得るコンピュータ可読信号媒体の任意の他のタイプの形式でも存在し得る。Ｉ／Ｏユニットは、キーボード、マウス、タッチデバイスなどの入力デバイスもしくは音声コマンドを用い得るユーザインターフェース２４０またはオペレータインターフェース２４５からの入力を処理する。

サーバ２０５は、また、（たとえば、図１に図解されているオブジェクトストレージ１０２などの）外部ストレージ２５０に接続されることがあり得るが、この外部ストレージは、ストレージシステム（ＲＡＩＤシステムもしくはＤＩＳＤアレイ）、ポータブルハードドライブ、光媒体（ＣＤもしくはＤＶＤ）、ディスク媒体、またはそこからサーバ２０５がデータを読み出すことが可能な任意の他の媒体などのストレージを含み得る。サーバ２０５は、ユーザからの追加的な情報を要求することに加えて、データと他の情報とをユーザに出力するために、ディスプレイなどの出力デバイス２５５に接続され得る。サーバ２０５から、ユーザインターフェース２４０とオペレータインターフェース２４５と外部ストレージ２５０とインターフェース１０３と出力デバイス２５５とへの接続は、８０２．１１標準、Ｂｌｕｅｔｏｏｔｈ（登録商標）もしくはセルラープロトコルなどの無線プロトコルを介し得、または、ケーブルもしくは光ファイバなどの物理的な伝送媒体を介することがあり得る。出力デバイス２５５は、したがって、ユーザとの対話のための入力デバイスとして、さらに作用し得る。

プロセッサ２１０は、たとえば図４Ａ、図５Ａおよび図５Ｂに記載されている１つまたは複数の実装を容易にするように構成され得る。このプロセッサは、サーバをクライアントデバイスからリカバリし、サーバのリカバリの後では、クライアントリカバリファイルとクライアントからのファイル更新とを処理するために、図５Ａおよび図５Ｂに記載されているように、決定を処理し得る。サーバ２０５は、（たとえば、サーバにおける故障または事故が原因で）故障する場合には、サーバのリカバリを行うためにリカバリプロセスを実行する。このプロセスは、ファイルをリカバリし、サーバ２０５を以前のバックアップポイントにロールバックして、そのポイントがリカバリポイントであると決定するために、（たとえば、ストレージ２６０もしくは外部ストレージ２５０として実装されている）ストレージシステムに記憶されているバックアップまたはスナップショットを用いることを含み得る。すなわち、リカバリポイントとは、ストレージシステムに記憶されているバックアップまたはスナップショットを用いることによってリカバリプロセスを実行した直後であって、クライアントにおけるデータを用いることによってリカバリプロセスを実行する前の時点を意味する。リカバリの後では、サーバ２０５は、次に、クライアントからのファイルを更新または追加してクライアントとの同期を完了するために、１つまたは複数のクライアントと対話し得る。例示的な実装では、ストレージ２６０は、リカバリポイントにおいてサーバによって管理される第１のファイルのバージョンに関する情報と、サーバのファイルに関する情報とを記憶するように構成されたメモリという形態を取り得る。

サーバは、リカバリを完了すると、リカバリのためにクライアントからファイルを受け取ったインターフェース１０３を介して、１つまたは複数のクライアントとの対話を開始し得る。プロセッサ２１０は、よって、複数のクライアントデバイスにおける複数のファイルを用いることによってサーバにおけるファイルをリカバリするために、複数のクライアントデバイスから複数のファイルを受信し、（たとえば、リカバリポイントにおけるサーバでの対応するファイルなどの）第１のファイルのバージョンよりも新しいバージョンを有する複数の受信されたファイルである第２のファイルに関しては、第２のファイルの１つを第１のファイルの新たなバージョンとして管理し、第２のファイルの別の１つを第２のファイルの先の１つのファイルに対するコンフリクトファイルとして管理するように、構成され得る。さらなる詳細は、図５Ａおよび図５Ｂにおいて提供される。

プロセッサ２１０は、図５Ａおよび図５Ｂにおけるさらなる詳細に図解されているように、決定に基づいてコンフリクトファイルを生成するように構成され得る。サーバのリカバリの後には、プロセッサは、クライアントからのファイルをリカバリするためのクライアントリカバリファイルの形式のファイルＰＵＴを、または、クライアントがサーバに更新を提出するときには、更新されたクライアントファイルの形式のファイルＵＰＤＡＴＥを、受け取り、処理し得る。クライアントリカバリファイルまたは更新されたクライアントファイルがストレージに記憶されているサーバのファイルの１つに対応するときには、決定に応じて、コンフリクトファイルが生成され得る。決定がクライアントリカバリファイルまたは更新されたクライアントファイルをコンフリクトファイルとして記憶することを示すときには、コンフリクトファイルが生成される。これらの決定は、図５Ａおよび図５Ｂの流れ図に基づき、クライアント更新ファイルまたはクライアントリカバリファイルに対して、なされる。クライアントリカバリファイルまたは更新されたクライアントファイルと関連するコンテンツは、コンテンツファイルを生成するのに用いられる。たとえば、更新されたクライアントファイル（ファイルＵＰＤＡＴＥ）とクライアントリカバリファイル（ファイルＰＵＴ）とは、実際のファイルコンテンツを有しないことがあり得るのであって、クライアント上に記憶されているファイルへのインデクスであり得る。そのような例示的な実装では、サーバは、コンフリクトファイルを生成するために、更新されたクライアントファイルまたはクライアントリカバリファイルのインデクスによって示されるように、ファイルコンテンツをクライアントからリトリーブする。あるいは、コンテンツが、更新されたクライアントファイルまたはクライアントリカバリファイルに付属されていることもあり得る。

プロセッサ２１０は、また、そのファイルがサーバによって管理されているファイルと対応しないときには、受信されたファイルまたは更新を記憶するようにも構成され得る。ファイルがサーバによって管理されているファイルと対応しないときには、そのファイルは、サーバによってそれ以前には管理されていなかったか、または、そうでなければ、サーバがリカバリされたときに失われた新たなファイルであると推測され得る。次に、ファイルのコンテンツは、サーバと関連するストレージシステムとの実装に応じて、リトリーブされ、ストレージ２６０または外部ストレージ２５０に記憶され得る。さらなる詳細は、図５Ａおよび図５Ｂで提供される。

図３は、ある例示的な実装により、ファイルシステムとマウントポイントとに関して、例示的なクライアントとサーバとのビューを図解している。サーバでは、あるユーザに属するフォルダとファイルとが、ファイルシステムに編成されている。ファイルシステムに関する情報は、サーバ２５０におけるストレージ２６０または他のメモリデバイスに記憶されている。各ファイルシステムは、図３で「ｆｓＩｄ」として図解されている一意的な識別子を有する。ファイルシステムは、ファイルとフォルダとを含む。各ユーザは、そのユーザのためのすべての経路のベース（またはルート）である自分自身のプライベートファイルシステムを有する。図３における参照番号３２１、３２２、３２３はプライベートファイルシステムのためのサーバテーブルの一例を示しており、各サーバテーブルはストレージ２６０に記憶される。プライベートファイルシステムのための各サーバテーブルは、そのプライベートファイルシステムのファイルシステム識別子と、そのプライベートファイルシステムにおける各ファイルのための経路名と、関係する共用フォルダのためのマウントポイントのメタデータとを含む。メタデータは、マウントポイントの経路と、マウントポイントの共用識別子（ｆｓＩｄ）とを含む。たとえば、Ｕｓｅｒ１、Ｃｌｉｅｎｔ１のサーバテーブル３２１については、プライベートファイルシステムのファイルシステム識別子は「４１１６７８」であり、プライベートファイルシステムにおけるすべてのファイルに対する経路名は「／Ｆｏｌｄｅｒ３／ｍａｒｋ．ｔｘｔ」および「／Ｆｏｌｄｅｒ４／ｄａｒｋ．ｔｘｔ」であり、関係する共用フォルダのためのマウントポイントの経路は「／ＳｈａｒｅｄＦｏｌｄｅｒ１」であり、マウントポイントの共用識別子（ｆｓＩｄ）は「１２３４５６７」である。クライアントでは、このフォルダは、単一のトップレベルのフォルダにマップされる。各ファイルはバージョンを有しており、このバージョンとは、そのファイルへの各変化のたびに増加する数字である。さらに、各ファイルに関して、セキュアハッシュが維持される。２つのファイルが同じハッシュを有する場合には、それらは同じコンテンツを有する（すなわち、相互に異なることがない）と推測され、システムは、重複するファイルを転送または記憶することを回避できる。

複数のユーザがフォルダを共用することもあり得る。サーバでは、共用フォルダは、独立のファイルシステムである。図３の参照番号３２４は、共用フォルダのためのサーバテーブルの一例を示しており、共用フォルダのためのサーバテーブルはストレージ２６０に記憶される。これらの共用フォルダは、共用識別子（たとえば、ＳｈａｒｅｄＦｏｌｄｅｒ１）を有するフォルダとそのフォルダに付属する１つのメタデータとを作成することによって、ユーザのプライベートファイルシステムにマップされる。メタデータは、上で説明されたように、プライベートシステムのためのサーバテーブルにおいて管理される。共用識別子は、共用フォルダのファイルシステム識別子である。クライアントでは、共用フォルダのためのローカルマウントポイントテーブルは、共用フォルダとその共用フォルダのための共用識別子（ｆｓＩｄ）とに対するマウントポイントの経路を含む。異なるユーザのためのマウントポイントは、異なる名称を有することがあり得る。共用識別子は、クライアントへの不透明なトークンであり、ファイルシステム識別子を含む。クライアントは、共用識別子を有する任意のフォルダを、共用フォルダのマウントポイントとして扱う。さらに、サーバ２５０におけるストレージ２６０は、サーバ２６０に記憶される各ファイルに対するバージョン情報を記憶し、この情報は、図５Ａおよび図５Ｂのプロセスにおいて用いられる。さらに、クライアントにおけるメモリも、クライアントに記憶される各ファイルに対するバージョン情報を記憶する。

クライアントが各ファイルに関してサーバに変更を送るときには、それらは、「基礎バージョン」としてそのファイルの以前のバージョンを含む。この基礎板がサーバにおけるそのファイルの現在のバージョンと一致しない場合には、サーバは、新たなコンテンツを用いて、コンフリクトファイルを作成する。コンフリクトファイルの名称は、「ｆｉｌｅ−ｎａｍｅ（ｙｙｙｙ−ｍｍ−ｄｄにおけるユーザ名のコンフリクト）．ｆｉｌｅ−ｅｘｔｅｎｓｉｏｎ」など、ユーザのためにそれらを明確に識別するための一意的なフォーマットを有し得る。

図３の例では、ユーザ（Ｕｓｅｒ１）はクライアントを登録し、１つの共用フォルダと１つのプライベートフォルダとを備えたフォルダ構造を作成する。Ｕｓｅｒ１は別のＣｌｉｅｎｔ２を登録し、Ｃｌｉｅｎｔ２はＣｌｉｅｎｔ１およびサーバと同じビューを見ることになる。Ｕｓｅｒ２はクライアントを登録し、Ｕｓｅｒ１はＵｓｅｒ２とフォルダ「ＳｈａｒｅｄＦｏｌｄｅｒ１」を共用する。Ｕｓｅｒ２は、「ＳｈａｒｅｄＦｏｌｄｅｒ１」を「ＭｙＳｈａｒｅ」に名称変更する。

リカバリ
故障の状況においては、サーバは、完全に失われてしまうことがあり得るのであって、バックアップからリカバリなされなければならないことがあり得る。この状況では、リカバリの前にサーバと同期していたクライアントは、サーバよりも「先に進んで」いることになるであろう。クライアントは、サーバが有していない変更を有している。ファイルのバージョンは、サーバにおけるこれらのファイルのバージョンよりも高いであろう。クライアントが自らの状態をサーバから直接に更新した場合には、ローカルな変更がすべて失われてしまうことがあり得る。図４Ａ、図５Ａ、図５Ｂでは、サーバまたはクライアントがプロセスの主体である場合には、サーバまたはクライアントにおけるプロセッサが、メモリ（たとえば、ストレージ）に記憶されているソフトウェアを実行することによって、プロセスを実行することができる。故障がサーバ（または、外部ストレージ）で生じる場合には、サーバは、ストレージ２６０および／または外部ストレージ２５０に記憶されているデータを用いることによって、サーバにおけるファイルシステムをリカバリする。その後で、サーバは各クライアントと通信し、各クライアントに記憶されているデータを用いることによって、図４Ａ、図５Ａ、および図５Ｂに記載されているリカバリ手順を実行する。

図４Ａは、例示的な実装による流れ図を図解している。この例示的な流れ図では、マウントポイントまたは共用識別子に対する経路への変更が存在するときに生じる「．ＰＲＩＶＡＴＥ」を有するフォルダの名称変更が存在する。たとえば、フォルダの状態が「共用」から「プライベート」に変更されるときに、クライアントは、ローカルマウントポイントにおいて共用識別子を変更する。図４Ａに示されている例示的な実装は、サーバのリカバリを扱うための流れ図を図解しており、サーバのリカバリには、リカバリを実施するためにクライアントからの情報を用いる。

サーバの自己リカバリ（４００）の後で、サーバは、サーバがリカバリモードにあるということを任意の要求側クライアントに知らせる（４０１）。クライアントはリカバリモードをアクノレッジして、クライアントのプライベートファイルシステムのためのサーバテーブルと、上述した共用フォルダのためのメタデータを含むサーバテーブルとをサーバからフェッチすることを含むリカバリ手順を進める（４０２）。クライアントは、サーバテーブルをフェッチするか、または、そのメタデータを含む他の情報をフェッチすることによって、関係する共用フォルダのためのメタデータを取得できる。リカバリ手順の例示的な実装は、サーバがすべてのファイルの直近のコンテンツを有することができ、ファイルがまったく失われずまたは消去されないように、行われる。さらに、このリカバリ手順は、クライアントが、サーバと同期しておりユーザのための正しいファイルを有することになることを容易にする。この例示的な実装は、また、ファイルが、意図していない共用フォルダに書き込まれて、意図していないユーザにデータを漏らすことになり得ることを防止することができる。

クライアントは、リカバリのために以下の手順を行うことができる。クライアントは、その現在のローカルマウントポイントテーブルと、共用フォルダのための各マウントポイントのためのサーバテーブルにおけるメタデータとを比較して（４０３）、ローカルマウントポイントテーブルにおけるメタデータがサーバテーブルにおけるサーバメタデータと異なっているかどうかを判断する（４０４）。マウントポイントの経路またはローカルマウントポイントテーブルのマウントポイント共用識別子のいずれかがサーバテーブルのそれと異なるときには、マウントポイントから「．ＰＲＩＶＡＴＥ」への名称変更が生じる（４０５）。（たとえば、マウントポイントの経路が変更になるか、または、共用識別子のマウントポイントが、クライアントにおいてローカルに変更になる。）共用識別子は一意的なＩｄであり、クライアントに対しては不透明である。よって、マウントポイントにおけるすべてのマウントポイントについて、クライアントにおけるリストがサーバにおけるリストと比較される。このようにして、いずれかに対して経路または共用識別子が異なる場合には、クライアントは、それらのマウントポイントを名称変更する。

クライアントにおけるローカルマウントポイントメタデータ（たとえば、共用フォルダ）に対する共用識別子がサーバにおけるマウントポイントメタデータと異なる場合（メタデータは、マウントポイントの経路またはマウントポイントの共用識別子を含む）には（Ｙｅｓ）、クライアントは、元のマウントポイントの名称の最後に「．ＰＲＩＶＡＴＥ」または別のサフィックスを追加することによって、これらのマウントポイントの名称を変更し、ローカル共用識別子を削除し、対応するマウントポイントを通常のフォルダ（たとえば、プライベートフォルダ）の中に作成する（４０５）。後で、これらのフォルダは、新たなファイルおよびフォルダとして、サーバに送られることになる。新たな名称は、ユーザに対して、フォルダの共用状態属性にコンフリクトが存在し、それらがフォルダを再び共用することがあり得るということを示す。

共用フォルダのマウントポイントの比較の終了は、マウントポイントのすべてが比較される（４０６）と、生じる。すべてのマウントポイントが比較されているわけではない場合（Ｎｏ）には、比較は、次のマウントポイントを用いて反復される（４０３）。比較が終了する（Ｙｅｓ）と、クライアントは、ローカルな状態全体を横断し、（たとえば、ある時点で同期していた）バージョンを有する（たとえば、ファイル、フォルダ、マウントポイント）すべてのローカルアイテムを、真に設定されたリカバリフラグを有するサーバに送る（４０７）。リカバリフラグがブーリアンフラグであることは要求されず、所望の実装に応じて、他の実装もまた可能である。たとえば、ある例示的な実装は、ファイルを管理しているクライアントが、サーバと直近に同期していたときよりも後にローカルな変更を有するかどうかに応じて、「ｒｅｃｏｖｅｒｙＰｕｔ」（ＰＵＴ）または「ｒｅｃｏｖｅｒｙＵｐｄａｔｅ」（ＵＰＤＡＴＥ）の値を含み得る。ローカルアイテムの送信とサーバとの同期プロセスとは、ファイル名、ファイル経路、ハッシュおよび各ファイルのサイズに関する情報を有するＲＥＳＴによるＡＰＩのＰＵＴを含む。サーバがまだそれらを有していない場合には、それは、ファイルのコンテンツも含み得る。サーバは、既存の状態を有する３つのＰＵＴと調停をする。リカバリＰＵＴの詳細は、図５Ａとの関係でさらに説明される。

すべてのＰＵＴを調停する際に、クライアントは、サーバに、リカバリが完了したことを告げる（４０８）。次に、クライアントは、バージョンを有していなかった（たとえば、一度もサーバと同期しなかった）すべてのローカルファイルを、通常の動作またはＰＵＴとしてサーバに送る（４０９）。これらのファイルは、定常状態の場合と同じように、サーバに追加される。このステップは、先のプロセスによって「．ＰＲＩＶＡＴＥ」と名称変更された任意のフォルダを含む。クライアントは、次に、ユーザのすべてのファイルに関するすべてのメタデータを、サーバからプルする（４１０）。これにより、クライアントは、サーバ状態に更新されることになる。

図４Ｂおよび図４Ｃは、ある例示的実装による流れ図の実行の例を図解している。図４Ｂの例において、リカバリポイントは、バックアップからの復元が完了した後でのサーバデータの状態である。クライアント１は、ＳｈａｒｅｄＦｏｌｄｅｒ１という名称のプライベートフォルダを有し、共用フォルダは１つも有していない。Ｕｓｅｒ１のために、クライアント１はサーバと通信し、サーバは自らがリカバリモードにあることを示す。クライアントは、ローカルマウントポイントテーブルにおけるマウントポイントメタデータと、サーバ上のサーバテーブルにおけるマウントポイントメタデータとを比較する。サーバにおけるマウントポイントの名称ＳｈａｒｅｄＦｏｌｄｅｒ１はクライアントには存在しないが、クライアントは同じ名称を有するプライベートフォルダを有する。本開示において説明されているように、実装を名称変更することなく、サーバは、ユーザのプライベートフォルダ「ＳｈａｒｅｄＦｏｌｄｅｒ１」のすべてのプライベートコンテンツの共用を開始し得る。そのような状況を避けるために、クライアントは、プライベートフォルダ「ＳｈａｒｅｄＦｏｌｄｅｒ１」を「ＳｈａｒｅｄＦｏｌｄｅｒ１．ＰＲＩＶＡＴＥ」に名称変更する。クライアントは、また、サーバから、マウントポイントＳｈａｒｅｄＦｏｌｄｅｒ１の詳細をプルする。

図４Ｃの例において、リカバリポイントは、バックアップからの復元が完了した後でのサーバデータの状態である。クライアント１は、ディザスタが発生する前の一定の時刻において、その共用フォルダマウントポイントを、「ＳｈａｒｅｄＦｏｌｄｅｒ１」から「ＮｅｗＳｈａｒｅ」に名称変更し、それが、クライアント１の現在の状態である。ユーザ１のためのクライアント１はサーバと通信し、サーバは自らがリカバリモードにあることを示す。クライアント１は、ローカルマウントポイントテーブルにおけるマウントポイントメタデータと、サーバテーブルにおけるサーバ上のマウントポイントメタデータとを比較する。サーバにおけるマウントポイントの名称（マウントポイントの経路）「ＳｈａｒｅｄＦｏｌｄｅｒ１」は、クライアントにおけるマウントポイントの名称（マウントポイントの経路）「ＮｅｗＳｈａｒｅ」と異なる。したがって、「ＮｅｗＳｈａｒｅ」は、プライベートフォルダの中に作成され、その新たな名称は「ＮｅｗＳｈａｒｅ．ＰＲＩＶＡＴＥ」である。

上の例において、マウントポイントの名称は、用いられるメタデータの一例である。同様の名称変更は、共用識別子が同一の経路を有するフォルダに対して異なるときにも生じ得る。

リカバリプット（ｒｅｃｏｖｅｒｙ ｐｕｔ）およびリカバリ更新（ｒｅｃｏｖｅｒｙ ｕｐｄａｔｅ）の例示的実装
クライアントは、リカバリのためにファイルを送るときには、ＲＥＳＴ ＰＵＴ動作を用いる。この動作の間には、ファイルに関して２つの可能性が存在し得る。すなわち、それらが、同期していたときとまったく同じコンテンツであるか、または、ファイルが同期された後で、ユーザによってローカルに修正されたか、のいずれかである。以後、第１の場合はＰＵＴと称され、第２の場合はＵＰＤＡＴＥと称される。より詳しくは、ＰＵＴのリカバリプロセスは、ファイルと関連する現在のメタデータ（たとえば、サイズおよび／または修正時刻）が、そのローカルデータベースにクライアントが記録したものから変化していない（たとえば、サーバと直近に同期してから、ファイルがローカルに変化していない）場合に、用いることが可能である。ＵＰＤＡＴＥのリカバリプロセスは、サーバへの直近の同期の後でファイルがローカルに変化している（たとえば、サーバがダウンしていて更新を受け取っていなかった間に、ユーザがファイルをローカルに更新した）場合に、用いることが可能である。サーバが利用可能になり（たとえば、故障からリカバリ）、クライアントにリカバリを告げると、クライアントはローカルに変化したファイルをＵＰＤＡＴＥとして送るのであるが、その理由は、サーバとの直近の成功した同期の後で、ファイルがローカルに変化しているからである。ＰＵＴとＵＰＤＡＴＥとの間の差は、クライアントがサーバと同期した直近の時点の後でファイルがローカルに変更されているかどうかである。それぞれの場合において、サーバは、クライアントからのデータを用いて、それ自体をリカバリしようと試みる。

以下の例では、ＣｌｉｅｎｔＶｅｒｓｉｏｎとは、ＰＵＴまたはＵＰＤＡＴＥにおいてクライアントによって送られたバージョンである。ＳｅｒｖｅｒＶｅｒｓｉｏｎとは、サーバ上のファイルのバージョンである。

サーバがリカバリを経験するときには、各ファイルシステムにはＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎというマークが付され、このＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎはリカバリの間は変更されない。このＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎは、図５Ａのリカバリの開始時点におけるファイルシステムでのすべてのファイルの中で最高のバージョンよりも高い。リカバリの間は、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも大きいかそれと等しいどの遭遇したＣｌｉｅｎｔＶｅｒｓｉｏｎも、システムに対して、サーバからのバックアップ復元の後で、遭遇したより高いＣｌｉｅｎｔＶｅｒｓｉｏｎが作成されたことを示す。ＣｌｉｅｎｔＶｅｒｓｉｏｎ、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎおよびＳｅｒｖｅｒＶｅｒｓｉｏｎは、ファイルのバージョン数を示すメタデータとしての実装が可能であり、または、所望の実装に応じた他の方法による実装が可能である。

以下の実装を用いると、それによって、より少数のコンフリクトファイルが作成されるようにしながら、サーバ上のすべてのファイルコンテンツを受け入れることが可能であり得る。関連技術の実装では、コンフリクトファイルが、ＣｌｉｅｎｔＶｅｒｓｉｏｎがＳｅｒｖｅｒＶｅｒｓｉｏｎと一致しないときには常に、作成され得る。しかし、リカバリプットを用いることで、この例示的実装により、サーバのリカバリの後で、あるファイルへの第１の更新が成功することが可能になる。図５Ａおよび図５Ｂに示されている例示的実装は、サーバとクライアントとの間のサーバによる調停プロセスを図解している。図５Ａおよび図５Ｂに図解されているプロセスを開始する前に、サーバは、各クライアントから送られる各ファイルに対するリカバリフラグを参照して、クライアントが、各ファイルに対するＰＵＴまたはＵＰＤＡＴＥのリカバリプロセスを要求しているかどうかを判断する。既に説明されたように、リカバリフラグは、ファイルがサーバとの直近の同期の後でローカルな変更を有したかどうかに応じて、「ｒｅｃｏｖｅｒｙＰｕｔ」（ＰＵＴ）または「ｒｅｃｏｖｅｒｙＵｐｄａｔｅ」（ＵＰＤＡＴＥ）を含み得る。

図５Ａは、ある例示的実装によるリカバリＰＵＴのための流れ図を図解している。リカバリＰＵＴは、上で説明されたように、クライアントリカバリファイルの形式であり得る。サーバは、ＣｌｉｅｎｔＶｅｒｓｉｏｎを得るために、クライアントからファイルＰＵＴを受信する（５００）。ＣｌｉｅｎｔＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しいかどうかを確認するために、比較が行われる（５０１）。新しくない場合（Ｎｏ）にはＰＵＴは無視される（５０２）のであるが、その理由は、ＣｌｉｅｎｔＶｅｒｓｉｏｎが、サーバおよび外部ストレージにおけるファイルを用いることによりリカバリが可能な最高のバージョンよりも前のバージョンであり、よって、サーバは既に更新済みであり（サーバは、既にクライアントバージョンを有している）、それにより、ＰＵＴは廃棄可能であるからである。

そうでない（Ｙｅｓ）場合には、ＳｅｒｖｅｒＶｅｒｓｉｏｎがゼロ（すなわち、サーバがコピーを有していない）かどうかを確認するために、チェックが行われる（５０３）。ＳｅｒｖｅｒＶｅｒｓｉｏｎがゼロ（Ｙｅｓ）である場合には、そのファイルを新たなファイルとして記憶するためにＰＵＴが実行される（５０４）のであるが、その理由は、そのファイルがサーバには存在しないからである。そうでない（Ｎｏ）場合には、ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古いかどうかを確認するために、チェックが行われる（５０５）。ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古い（５０５においてＹｅｓである）場合には、それは、サーバが、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しいＣｌｉｅｎｔＶｅｒｓｉｏｎを有する別のファイルをクライアントからまだ受信していないことを示す。ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しい（５０５においてＮｏである）場合には、それは、サーバが、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しいＣｌｉｅｎｔＶｅｒｓｉｏｎを有する別のファイルをクライアントから既に受信したことを示す。

ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古い（Ｙｅｓ）場合には、ＰＵＴは、クライアントから受信されたファイルを用いることによって、既存のファイルへの更新として処理される（５０６）。クライアントからのファイルは、このようにして、サーバにおけるファイルの最新のバージョンとなるために用いられ、その時点でクライアントにおいて記憶されている他のバージョンのすべてよりも高いバージョンに設定される。これは、受信されたファイルを直近のバージョンとして指定し、このファイルに対するクライアントからの以後のファイルＰＵＴをコンフリクトファイルとなるように処理するために、なされる。そうでない（Ｎｏ）場合には、両者が同じコンテンツを有することを示すこと、すなわち、クライアントおよびサーバファイルが同じハッシュを有するかどうかを確認するために、チェックが行われる。

クライアントおよびサーバファイルが同じハッシュを有する（Ｙｅｓ）場合には、ＰＵＴは無視され（５０８）、廃棄され得る。クライアントは、自らがリカバリを完了した後で、そのファイルに対する新たな情報をプルすることになる。そうでない（Ｎｏ）場合には、クライアントファイルを用いて、コンフリクトファイルが作成される（５０９）のであるが、その理由は、別のクライアントがリカバリの後でそのファイルを既に更新しており、その更新がファイルの履歴の中にどのように適合するかどうかを判断することが可能でないことがあり得るからである。ある例示的実装では、サーバが、コンフリクトファイルを記憶するフォルダにおいてコンフリクトファイルを作成することがあり得る。こうして、サーバは、元のファイルと同じディレクトリにおいてコンフリクトファイルをプットすることができる。

上述した例示的実装において説明されたこのリカバリプロセスにより、サーバは、リカバリポイントにおけるサーババージョンよりも新しいバージョンを有する複数のファイルを受信する場合には、それら複数のファイルの１つを新たなバージョンを有する更新されたファイルとして管理し、それ以外のファイルを第１のファイルに対するコンフリクトファイルとして管理する。リカバリポイントは、ストレージ２６０と外部ストレージ２５０とのバックアップからの復元が完了した後におけるサーバのデータの状態である。第１のファイルとは、複数のファイルの中でサーバが最初に受信するファイルである。

上の例示的実装において説明されたこのリカバリプロセスによって、サーバは、サーバの内部／外部ストレージだけではなくクライアントにおけるメモリにも記憶されているファイルを用いることにより、ファイルをリカバリすることが可能である。さらに、サーバは、複数のクライアントにおけるファイルの間でのコンフリクトを解決することができる。

図５Ｂは、ある例示的実装によるリカバリＵＰＤＡＴＥのための流れ図を図解している。上で説明されたように、リカバリＵＰＤＡＴＥは、更新されたクライアントファイルの形式での実装が可能である。リカバリＵＰＤＡＴＥの例示的実装では、サーバにおけるファイルバージョンよりも新しいファイルバージョンを有する複数のクライアントが存在する場合に、サーバは、それらのクライアントバージョンの１つを更新されたバージョンとして扱い、別のクライアントバージョンをコンフリクトバージョンとして扱うように構成される。さらに、サーバは、クライアントファイルＵＰＤＡＴＥと同じバージョンであるバージョンのファイルを有する場合であっても、クライアントファイルＵＰＤＡＴＥを用いることによって、サーバにおけるファイルを更新する必要がある。

ファイルＵＰＤＡＴＥの例示的実装では、サーバは、クライアントからファイルＵＰＤＡＴＥを受信する（５１０）。ＳｅｒｖｅｒＶｅｒｓｉｏｎがゼロである、すなわち、サーバがそのファイルのコピーを有していないことを示しているかどうかを確認するために、チェックが行われる（５１１）。ＳｅｒｖｅｒＶｅｒｓｉｏｎがゼロである（Ｙｅｓ）場合には、ファイルＵＰＤＡＴＥは、サーバにおいてそのファイルを新たなファイルとして追加するために、新たなＰＵＴとして許容する（５１２）。

ＳｅｒｖｅｒＶｅｒｓｉｏｎがゼロではない（Ｎｏ）場合には、ＣｌｉｅｎｔＶｅｒｓｉｏｎがＳｅｒｖｅｒＶｅｒｓｉｏｎと同じであるかどうかを確認するために、チェックが行われる（５１３）。ＣｌｉｅｎｔＶｅｒｓｉｏｎがＳｅｒｖｅｒＶｅｒｓｉｏｎと同じである（Ｙｅｓ）場合には、ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古いかどうかを判断するために、チェックが行われる（５１４）。ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古い（Ｙｅｓ）場合には、既存のファイルのＵＰＤＡＴＥが許容される（５１５）のであるが、その理由は、この動作が既存のファイルの標準的な更新であるからである。そうでない（Ｎｏ）場合には、ＣｌｉｅｎｔＶｅｒｓｉｏｎは、サーバがロールバックしたときに失ったバージョンであり、よって、ＣｌｉｅｎｔＶｅｒｓｉｏｎは、ロールバックの時点におけるＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しい（５１６）。

そうではなくて、ＣｌｉｅｎｔＶｅｒｓｉｏｎがＳｅｒｖｅｒＶｅｒｓｉｏｎと同じではない場合には、ＳｅｒｖｅｒＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも古く、ＣｌｉｅｎｔＶｅｒｓｉｏｎがＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎよりも新しいかどうかを確認するために、チェックが行われる（５１７）。そうである（Ｙｅｓ）場合には、ＣｌｉｅｎｔＶｅｒｓｉｏｎがリカバリの後でのファイルへの最初の更新であるという結果になり、したがって、新たなＣｌｉｅｎｔＶｅｒｓｉｏｎを用いてサーバにおける既存のファイルを更新するＵＰＤＡＴＥが許容される（５１８）。そうでない（Ｎｏ）場合には、コンフリクトファイルが作成される（５１９）。

図５Ｃおよび図５Ｄは、図５Ａおよび図５Ｂの例示的実装に基づいて、クライアントとサーバとの間の例示的な対話を図解している。特に、図５Ｃおよび図５Ｄは、サーバが失ったバージョンをクライアントが有しているときに生じる例示的な対話を図解している。このように、例示的実装は、図５Ａおよび図５Ｂに図解されているように、リカバリＰＵＴまたはリカバリＵＰＤＡＴＥのいずれかに対して生じ得る。

図５Ｃでは、ユーザは、３つの登録されたクライアントを有する。サーバは、リカバリポイントにあり、失われたデータをクライアントからリカバリすることを試みる。リカバリポイントでは、ファイルａ．ｔｘｔのＳｅｒｖｅｒＶｅｒｓｉｏｎはＶ６であり、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎはＶ７である。Ｃｌｉｅｎｔ１におけるファイルａ．ｔｘｔのＣｌｉｅｎｔＶｅｒｓｉｏｎｓはＶ７であり、Ｃｌｉｅｎｔ２はＶ８であり、Ｃｌｉｅｎｔ３はＶ５である。Ｃｌｉｅｎｔ１はサーバと通信する。図５Ｄでは、サーバが、Ｃｌｉｅｎｔ１との対話から、自らがａ．ｔｘｔのより古いバージョンを有していることを認識し、よって、新たなバージョンを用いてそのバージョンを更新する。図５Ｄの例では、サーバはＳｅｒｖｅｒＶｅｒｓｉｏｎＶ１０を作成するのであるが、これは他のすべてのクライアントのバージョンよりも高く、他方で、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎはＶ７のままである。ＳｅｒｖｅｒＶｅｒｓｉｏｎは、サーバが依然としてクライアントとの同期化を行っている間にクライアント側でファイルがローカルに編集されるときに、コンフリクトファイルを作成するための状況を扱うために、最も高いバージョンに設定される。バージョン名はクライアントにおけるものとは同じではないが、コンテンツは同じである。こうして、ＳｅｒｖｅｒＶｅｒｓｉｏｎＶ１０はクライアント１においてＶ７と同じコンテンツを有しており、サーバはＳｅｒｖｅｒＶｅｒｓｉｏｎＶ１０をクライアント１に送る。クライアント１のビューは同じままであるが、ファイルａ．ｔｘｔのバージョン数は今ではＶ１０である。ただし、コンテンツは、先のＣｌｉｅｎｔＶｅｒｓｉｏｎＶ７と同じままである。図５Ｄは、クライアント／サーバの対話の後でのクライアントおよびサーバにおけるビューを図解している。

図５Ｅおよび図５Ｆは、図５Ａの例示的実装に基づくクライアントとサーバとの間の例示的な対話を図解している。特に、図５Ｅおよび図５Ｆは、図５Ｃおよび図５Ｄの対話の後の、クライアント３からの対話による、リカバリＰＵＴのための例示的な対話を図解している。図５Ｅでは、クライアント３は、バージョン５（Ｖ５）のファイルａ．ｔｘｔを有し、共用フォルダマウントポイント「Ｓｈａｒｅ１」を有さず、「Ｆｏｌｄｅｒ２」の下にはファイルを有しない。サーバビューは、図５Ｄからのクライアント１との対話の後のビューである。その展望から、クライアント３は、図５Ｅに図解されているように、サーバと対話する。図５Ｆでは、サーバは、自らがクライアント３よりも新しいバージョンのａ．ｔｘｔを有していることを認識し、よって、現在のサーババージョン（Ｖ１０）のａ．ｔｘｔをクライアント３に送る。クライアントは、また、クライアント３と同期されるべき「Ｓｈａｒｅ１」および「Ｆｏｌｄｅｒ２」の詳細をプルし、結果的に、図５Ｆに示されているビューを生じる。

図５Ｇおよび図５Ｈは、図５Ａおよび図５Ｂの例示的実装に基づくクライアントとサーバとの間の例示的な対話を図解している。特に、図５Ｇおよび図５Ｈは、図５Ｅおよび図５Ｆに図解されている対話の後で、クライアント２が以後の新たなバージョンを送るときに生じる例示的な対話を図解している。よって、この例示的な対話は、図５Ａおよび図５Ｂに図解されているように、リカバリＰＵＴまたはリカバリＵＰＤＡＴＥのいずれかに対して生じ得る。

図５Ｇの例では、クライアント２は、バージョン８（Ｖ８）のファイルａ．ｔｘｔを有し、共用フォルダマウントポイント「Ｓｈａｒｅ１」を有しない。サーバビューは、図５Ｆからのクライアント３との対話の後のビューである。クライアント２は、図５Ｇにおけるように、サーバと対話する。図５Ｈでは、サーバは、自らがクライアント２よりも古いバージョンのａ．ｔｘｔを有していることを認識するのであるが、その理由は、ＲｅｃｏｖｅｒｙＶｅｒｓｉｏｎＶ７がクライアント２のＣｌｉｅｎｔＶｅｒｓｉｏｎＶ８よりも古いからである。しかし、サーバは、既に、そのデータを一度リカバリしており（ＳｅｒｖｅｒＶｅｒｓｉｏｎがＶ１０に設定されていることによる）、よって、そのファイルに対するコンフリクトを生成する。クライアントは、作成されたコンフリクトファイルの詳細と既存のバージョンのａ．ｔｘｔとをクライアント２にプルする。クライアントは、また、クライアント２と同期されるべき「Ｓｈａｒｅ１」の詳細をプルする。クライアント２とサーバとに対する結果的なビューが、図５Ｈに示されている。

最後に、この詳細な説明のいくつかの部分は、コンピュータの内部における動作のアルゴリズムと記号表現とによって提示されている。これらのアルゴリズムによる説明と記号表現とは、自らの技術革新の本質を他の当業者に最も効果的に伝達するために、データ処理技術の当業者によって用いられる手段である。アルゴリズムとは、希望の目的状態または結果に至る一連の画定されたステップである。例示的実装においては、遂行されるステップは、有形の結果を達成するために、有形の実体の物理的操作を必要とする。

そうではないと特に断らない限り、ここでの議論から明らかなように、説明の全体を通じて、「処理」、「コンピューティング」、「計算」、「判断」、「表示」などの用語を用いての議論は、コンピュータシステムまたはそれ以外の情報処理デバイスの作用および処理を含み得る。なお、このコンピュータシステムまたはそれ以外の情報処理デバイスは、コンピュータシステムのレジスタおよびメモリにおいて物理（電子的）量として表現されているデータを操作して、コンピュータシステムのメモリもしくはレジスタ、または、他の情報記憶、伝送もしくは表示デバイスにおける物理量として同様に表現される他のデータに変換する。

例示的な実装は、また、本明細書における動作を行うための装置にも関係し得る。この装置は、要求される目的のために特別に構築されたものであり得、または、１つもしくは複数のコンピュータプログラムによって選択的に稼働もしくは再構成された１つもしくは複数の汎用コンピュータを含み得る。そのようなコンピュータプログラムは、コンピュータ可読な記憶媒体またはコンピュータ可読な信号媒体などのコンピュータ可読媒体に記憶させることができる。コンピュータ可読な記憶媒体は、これらに限定されることはないが、光ディスク、磁気ディスク、リードオンリメモリ、ランダムアクセスメモリ、ソリッドステートデバイスおよびドライブなどの有形的な媒体、または、電子的情報を記憶するのに適した任意の他のタイプの有形もしくは非一時的な媒体を含み得る。コンピュータ可読な信号媒体は、搬送波などの媒体を含み得る。本明細書で提示されているアルゴリズムと表示とは、どのような特定のコンピュータまたはそれ以外の装置とも、本質的に関係することはない。コンピュータプログラムは、所望の実装の動作を行う命令を含む純粋なソフトウェアによる実装を含み得る。

本明細書における例によると、様々な汎用のシステムが、プログラムおよびモジュールと共に用いられ得、または、所望の方法ステップを行うために、より特殊な装置を構築することが便利であることが判明することもあり得る。さらに、例示的な実装は、いずれか特定のプログラミング言語との関係で説明されているということはない。本明細書で説明されている例示的な実装の教示内容を実装するためには、多様なプログラミング言語が用いられ得る、ということが理解されるであろう。プログラミング言語の命令は、たとえば、中央処理装置（ＣＰＵ）、プロセッサまたはコントローラなどの１つまたは複数の処理デバイスによって実行され得る。

この技術分野で知られているように、上述の動作は、ハードウェア、ソフトウェアまたはソフトウェアおよびハードウェアの何らかの組合せによって、行われ得る。例示的実装の種々の態様は、回路および論理デバイス（ハードウェア）を用いて実装され得るのであり、他方で、他の態様は、マシン可読の媒体上に記憶された命令（ソフトウェア）を用いて実装され得るのであるが、これらの命令は、プロセッサによって実行されると、そのプロセッサに本出願の実装を遂行するための方法を行わせ得るのである。さらに、本出願のいくつかの例示的な実装は、もっぱらハードウェアにおいて実行され得るのであるが、他方では、他の例示的実装は、もっぱらソフトウェアにおいて実行され得る。さらに、説明された様々な機能を、単一のユニットにおいて実行させることが可能であり、または、任意の数の様態で、いくつかのコンポーネントの間で分担させることも可能である。ソフトウェアによって行われるときには、これらの方法は、コンピュータ可読媒体上に記憶されている命令に基づいて、汎用コンピュータのようなプロセッサによって実行され得る。必要である場合には、これらの命令は、圧縮されたおよび／または暗号化されたフォーマットで媒体上に記憶され得る。

さらに、本出願の他の実装が、本出願の明細書と教示内容の実践とを考察することにより、当業者には明らかであろう。説明されている例示的実装の様々な態様および／またはコンポーネントは、単独またはいずれかの組合せにおいて、用いられ得る。本明細書と例示的実装とは単なる例として考察されるべきであると意図されており、本出願の真の範囲および精神は、以下の特許請求の範囲によって示される。

Claims (12)

1. サーバであって、
   複数のクライアントデバイスとのインターフェースとなるように構成されたインターフェースと、
   リカバリポイントにおいて前記サーバによって管理される第１のファイルのバージョンに関する情報を記憶するように構成されたメモリと、
   プロセッサであって、
   複数のファイルを、前記複数のファイルを前記複数のクライアントデバイスにおいて用いることによって前記サーバにおいてファイルをリカバリするために、前記複数のクライアントデバイスから受信し、
   前記リカバリポイントにおける前記第１のファイルの前記バージョンよりも新しいバージョンを有する前記複数の受信されたファイルの第２のファイルに対し、前記第２のファイルの１つを前記第１のファイルの新たなバージョンとして管理し、前記第２のファイルの別の１つを前記第２のファイルの前記１つに対するコンフリクトファイルとして管理するように構成されたプロセッサと、
   を備えるサーバ。
2. 前記プロセッサは、さらに、前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するように構成されており、前記第１のファイルへの前記１つまたは複数の更新は、前記第１のファイルの前記新たなバージョンと同じバージョンを有する前記１つまたは複数の更新に対するコンフリクトファイルとして記憶される、請求項１に記載のサーバ。
3. 前記プロセッサは、さらに、前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するように構成されており、前記第１のファイルへの前記１つまたは複数の更新は、
   前記第１のファイルの前記新たなバージョンとは異なるバージョンと、
   前記第１のファイルの前記バージョンよりも新しくないバージョンと、
   を有する前記１つまたは複数の更新に対するコンフリクトファイルとして記憶される、請求項１に記載のサーバ。
4. 前記プロセッサは、
   前記複数のファイルの中のファイルを、前記複数のファイルの中で前記サーバにおける前記ファイルの対応する１つを有しないファイルに対する新たなファイルとして記憶し、
   前記更新の中で前記サーバにおける前記ファイルの対応する１つを有しないファイルに対する新たなファイルとして更新を記憶する
   ように構成されている、請求項１に記載のサーバ。
5. 前記プロセッサは、さらに、前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するように構成されており、前記第１のファイルへの前記１つまたは複数の更新は、前記第２のファイルの前記１つが前記第１のファイルの前記新たなバージョンとして管理される前に、前記第１のファイルを更新するのに用いられる、請求項１に記載のサーバ。
6. 前記プロセッサが、
   前記複数のクライアントデバイスからの前記複数のファイルの中の受信されたファイルであって、前記受信されたファイルよりも新しいバージョンである前記サーバにおける前記ファイルの対応する１つを有するファイルを廃棄するように構成されている、請求項１に記載のサーバ。
7. サーバを管理するための方法であって、
   リカバリポイントにおいて前記サーバによって管理される第１のファイルのバージョンに関する情報を記憶するステップと、
   複数のファイルを前記複数のクライアントデバイスから、前記複数のファイルを前記複数のクライアントデバイスにおいて用いることによって前記サーバにおいてファイルをリカバリするために受信するステップと、
   前記リカバリポイントにおける前記第１のファイルの前記バージョンよりも新しいバージョンを有する前記複数の受信されたファイルの第２のファイルに対し、前記第２のファイルの１つを前記第１のファイルの新たなバージョンとして管理し、前記第２のファイルの別の１つを前記第２のファイルの前記１つに対するコンフリクトファイルとして管理するステップと、
   を含む方法。
8. 前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するステップをさらに含み、前記第１のファイルへの前記１つまたは複数の更新は、前記第１のファイルの前記新たなバージョンと同じバージョンを有する前記１つまたは複数の更新に対するコンフリクトファイルとして記憶される、請求項７に記載の方法。
9. 前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するステップをさらに含み、前記第１のファイルへの前記１つまたは複数の更新は、
   前記第１のファイルの前記新たなバージョンとは異なるバージョンと、
   前記第１のファイルの前記バージョンよりも新しくないバージョンと、
   を有する前記１つまたは複数の更新に対するコンフリクトファイルとして記憶される、請求項７に記載の方法。
10. 前記複数のファイルの中のファイルを、前記複数のファイルの中で前記サーバにおける前記ファイルの対応する１つを有しないファイルに対する新たなファイルとして記憶するステップと、更新を、前記更新の中で前記サーバにおける前記ファイルの対応する１つを有しない更新に対する新たなファイルとして記憶するステップとをさらに含む、請求項７に記載の方法。
11. 前記サーバにおいてファイルをリカバリするために複数のファイルを前記複数のクライアントデバイスから受信する間に、前記第１のファイルへの１つまたは複数の更新を前記複数のクライアントデバイスの１つから受信するステップをさらに含み、前記第１のファイルへの前記１つまたは複数の更新は、前記第２のファイルの中の前記１つが前記第１のファイルの前記新たなバージョンとして管理される前に、前記第１のファイルを更新するのに用いられる、請求項７に記載の方法。
12. 前記複数のクライアントデバイスからの前記複数のファイルの中の受信されたファイルであって、前記受信されたファイルよりも新しいバージョンである前記サーバにおける前記ファイルの対応する１つを有するファイルを廃棄するステップをさらに含む、請求項７に記載の方法。