CN105593839A - 分布式灾难恢复文件同步服务器系统 - Google Patents

Abstract

示例实现方式涉及不仅从服务器、而且还从连接到服务器的客户端恢复数据。用于标识在上次备份之后被创建或者修改的内容的算法被并入。这一算法也标识和解决用于共享的文件夹的安装点的改变，从而防止信息泄露。在服务器从故障恢复时，它在它和客户端的下一连接时向客户端通知该恢复。每个客户端然侯确定它的安装点和文件路径的当前状态，并且比较它们与服务器的安装点和文件路径。在比较之后，客户端了解安装点差异并且通过对它们重命名来指示它们，并且向服务器发送全部本地数据(所有文件、文件夹、安装点)。服务器调和差异。

Description

分布式灾难恢复文件同步服务器系统

技术领域

本公开内容涉及存储系统，并且更具体地涉及在灾难恢复期间用于服务器/存储系统的文件同步。

背景技术

在相关领域中，存在涉及客户端网络和存储提供者的存储/服务器系统。存储网关从客户端网络向存储服务发送更新数据，存储服务按卷存储更新的数据。数据也被存储到本地数据存储库。如果在本地数据存储库中存储的数据发生某事，则将通过利用在存储服务中按卷存储的数据来恢复丢失的数据。

然而，相关领域并未考虑存储服务的灾难恢复，并且也未考虑存储服务中的卷恢复。

发明内容

本申请的各方面包括一种服务器，该服务器可以包括：接口，该接口被配置为与多个客户端设备对接；存储器，该存储器被配置为存储关于在恢复点处的、由服务器管理的第一文件的版本的信息；以及处理器，该处理器被配置为从多个客户端设备接收多个文件以通过使用多个客户端设备中的多个文件来恢复服务器中的文件，并且对于多个接收的文件中的具有比在恢复点处的第一文件的版本更加新的版本的第二文件，将第二文件中的一个第二文件管理作为第一文件的新版本，并且将第二文件中的另一第二文件管理作为与第二文件中的该一个第二文件的冲突文件。

本申请的附加方面包括一种用于管理服务器的方法。该方法可以包括：存储关于在恢复点处的、由服务器管理的第一文件的版本的信息；从多个客户端设备接收多个文件以通过使用多个客户端设备中的多个文件来恢复服务器中的文件，并且对于多个接收的文件中的具有比在恢复点处的第一文件的版本更加新的版本的第二文件，将第二文件中的一个第二文件管理作为第一文件的新版本，并且将第二文件中的另一第二文件管理作为与第二文件中的该一个第二文件的冲突文件。

本申请的附加方面包括一种用于管理服务器的计算机程序。该计算机程序可以包括用于以下操作的指令：存储关于在恢复点处的、由服务器管理的第一文件的版本的信息；从多个客户端设备接收多个文件以通过使用多个客户端设备中的多个文件来恢复服务器中的文件，并且对于多个接收的文件中的具有比在恢复点的处第一文件的版本更加新的版本的第二文件，将第二文件中的一个第二文件管理作为第一文件的新版本，并且将第二文件中的另一第二文件管理作为与第二文件中的该一个第二文件的冲突文件。

附图说明

图1图示了可以在其上实施示例实现方式的示例系统架构。

图2图示了可以在其上实施示例实现方式的示例计算机系统。

图3图示了根据示例实现方式的文件系统和安装点的示例客户端和服务器视图。

图4A图示了根据示例实现方式的流程图。

图4B和图4C图示了根据示例实现方式的流程图执行的示例。

图5A图示了根据示例实现方式的用于恢复PUT的流程图。

图5B图示了根据示例实现方式的用于恢复UPDATE的流程图。

图5C和图5D图示了基于图5A和图5B的示例实现方式的、在客户端与服务器之间的示例交互。

图5E和图5F图示了基于图5A的示例实现方式的、在客户端与服务器之间的示例交互。

图5G和图5H图示了基于图5A和图5B的示例实现方式的、在客户端与服务器之间的示例交互。

具体实施方式

以下具体描述提供对本申请的各图和示例实现方式的进一步细节。为了清楚而省略了在各图之间的冗余单元的标号和描述。贯穿该描述而被使用的术语被提供作为示例而并未旨在于限制。例如，使用术语“自动”可以根据实践本申请的实现方式的本领域普通技术人员的希望的实现方式而涉及全自动或者半自动实现方式，后者涉及用户或者管理员对实现方式的某些方面的控制。这里描述的实现方式也并未旨在于限制，而是可以根据希望的实现方式按照各种方式被实施。

这里描述的示例实现方式涉及从服务器/存储系统的客户端的数据恢复和在灾难恢复情形中的用于共享的文件夹的简化的数据恢复。

组织可以依赖于具有对它们的数据的连续访问。因此，关键系统和应用可能需要健壮的灾难恢复计划以最小化在系统故障的情况下的数据丢失。随着无结构非易变数字内容的增长，管理和备份数据可能有挑战性。在相关领域的分布式客户端服务器系统中，来自系统中的服务器的数据被周期性地备份到另一系统。周期性数据备份可以提供对系统性能的最小影响(在与连续数据备份比较时)，但是产生对于数据损失的潜在可能；自从上次备份起向系统添加的任何数据可能在故障之后变得不可恢复。

图1图示了可以在其上实施示例实现方式的示例系统架构。系统架构可以涉及如图2中描述的服务器205，服务器205可以被配置为管理与一个或者多个数据库对应的一个或者多个节点。服务器可以维护对象存储装置102(例如，存储系统或者其它外部存储装置)以在服务器中存储与由一个或者多个节点管理的数据库对应的数据。服务器可以通过网络101与一个或者多个客户端(客户端计算机100)交互。客户端和服务器可以经由代表状态转移(REST)应用编程接口(API)103相互交互。在稳定状态操作期间，可以存在与服务器周期性地通信的客户端。客户端通过向服务器发送新文件内容并且从服务器接收更新的文件来与服务器同步文件。用于给定的用户的所有客户端同步相同文件集合。用于不同用户的客户端同步用于那些用户的文件。在图2中说明了服务器的细节。每个客户端包括处理器、存储器、存储设备，并且客户端中的处理器可以被配置为有助于如例如在图4A中描述的一个或者多个实现方式。

图2图示了可以在其上实施示例实现方式的示例计算机系统200。计算机系统200包括可以涉及I/O单元235、存储装置260(和/或存储器)和可操作用于如本领域技术人员已知的那样执行一个或者多个单元的处理器210的服务器205。如图2中所示的服务器205代表涉及一个节点的配置，但是服务器可以如图1中所示具有附加节点。服务器205可以经由接口(比如REST接口103)与关联于服务的一个或者多个客户端对接。如这里所用的术语“计算机可读介质”是指参与向处理器210提供指令以用于执行的任何介质，该介质可以具有计算机可读存储介质的形式，比如但不限于光盘、磁盘、只读存储器、随机存取存储器、固态设备和驱动或者适合用于存储电子信息的任何其它类型的非瞬态介质或者计算机可读信号介质，这可以包括媒体(比如载波)。I/O单元处理来自用户接口240和操作者接口245的输入，这些接口可以利用输入设备，比如键盘、鼠标、触摸设备或者口头命令。

服务器205也可以连接到外部存储装置250(例如，比如如图1中所示的对象存储装置102)，该外部存储装置250可以包含存储装置，比如存储系统(RAID系统或者DISD阵列)、便携硬驱动、光介质(CD或者DVD)、盘介质或者服务器205可以从其读取数据的任何其它介质。服务器205也可以连接到输出设备255(比如显示器)以向用户输出数据和其它信息，以及请求来自用户的附加信息。从服务器205到用户接口240、操作者接口245、外部存储装置250、接口103和输出设备255的连接可以经由无线协议(比如802.11标准、 或者蜂窝协议)或者经由物理传输介质(比如线缆或者光纤)。输出设备255因此还可以充当用于与用户交互的输入设备。

处理器210可以被配置为有助于如例如图4A、图5A和图5B中描述的一个或者多个实现方式。处理器可以处理如图5A和图5B中描述的确定以从客户端设备恢复服务器并且在服务器恢复之后处理来自客户端的客户端恢复文件和文件更新。如果服务器205失败(例如，由于服务器上的故障或者事故)，则服务器将执行恢复过程以执行服务器恢复。这一过程可以包括利用在(例如，被实施为存储装置260或者外部存储装置250的)存储系统中存储的备份或者快照以恢复文件并且将服务器205回滚到之前的备份点，并且确定该点是恢复点。即，恢复点意味着恰在通过利用在存储系统中存储的备份或者快照来执行恢复过程之后和在通过利用客户端中的数据来执行恢复过程之前的点。在恢复之后，服务器205然后可以与一个或者多个客户端通信以更新或者添加来自客户端的文件以完成与客户端同步。在示例实现方式中，存储装置260可以采用存储器的形式，该存储器被配置为存储关于在恢复点处的、由服务器管理的第一文件的版本的信息和关于服务器的文件的信息。

在服务器已经完成恢复时，服务器可以开始经由接口103与一个或者多个客户端对接以从客户端接收文件以用于恢复。处理器210由此可以被配置为从多个客户端设备接收多个文件以通过使用多个客户端设备中的多个文件来恢复服务器中的文件，并且对于多个接收的文件中的具有比第一文件的版本更加新的版本的第二文件(例如，在恢复点处的、在服务器中的对应文件)，将第二文件中的一个第二文件管理作为第一文件的新版本，并且将第二文件中的另一第二文件管理作为与第二文件中的该一个第二文件的冲突文件。在图5A和图5B中提供进一步细节。

处理器210可以被配置为基于如图5A和图5B中进一步具体所示的确定来生成冲突文件。在服务器恢复之后，处理器可以接收和处理按照客户端恢复文件形式的文件PUT以恢复来自客户端的文件，或者在客户端向服务器提交更新时接收和处理按照更新的客户端文件形式的文件UPDATE。在客户端恢复文件或者更新的客户端文件对应于在存储装置中存储的服务器的文件之一时，可以根据确定来生成冲突文件。在该确定指示将客户端恢复文件或者更新的客户端文件存储作为冲突文件时生成冲突文件。基于图5A和图5B的流程图对客户端更新文件或者客户端恢复文件做出确定。与客户端恢复文件或者更新的客户端文件关联的内容用来生成内容文件。例如，更新的客户端文件(文件UPDATE)和客户端恢复文件(文件PUT)可以不具有实际文件内容而可以是指向在客户端上存储的文件的索引。在这样的示例实现方式中，服务器从客户端取回如由更新的客户端文件或者客户端恢复文件编索引的文件内容以生成冲突文件。备选地，也可以向内容附着更新的客户端文件或者客户端恢复文件。

处理器210也可以被配置为在文件不对应于由服务器管理的文件时存储接收的文件或者更新。在文件不对应于由服务器管理的文件时，文件可以被推断为先前未被服务器管理的或者在服务器恢复时以别的方式丢失的新文件。然后可以根据服务器和关联存储系统的实现方式来取回和在存储装置260或者外部存储装置250中存储文件的内容。在图5A和图5B中提供进一步细节。

图3图示了根据示例实现方式的文件系统和安装点的示例客户端和服务器视图。在服务器上，属于用户的文件夹和文件被组织成文件系统。关于文件系统的信息被存储在存储装置260或者在服务器250中的其它存储器设备中。每个文件系统具有在图3中被图示为“fsId”的唯一标识符。文件系统包含文件和文件夹。每个用户具有它们自己的私有文件系统，该私有文件系统是用于该用户的所有路径的基础(或者根)。图3中的标号321、322、323示出了用于私有文件系统的服务器表的一个示例，并且每个服务器表被存储在存储装置260中。用于私有文件系统的每个服务器表包含私有文件系统的文件系统标识符、用于私有文件系统中的每个文件的路径名称和用于相关共享文件夹的安装点的元数据。元数据包括安装点的路径和安装点的共享标识符(fsId)。例如，关于用户1(User1)、客户端1(Client1)的服务器表321，私有文件系统的文件系统标识符是“411678”，用于私有文件系统中的所有文件的路径名是“/Folder3/mark.txt”和“/Folder4/dark.txt”，用于相关共享文件夹的安装点的路径是“/SharedFolder1”，并且安装点的共享标识符(fsId)是“1234567”。在客户端上，这一文件夹被映射到单个顶级文件夹。每个文件具有版本，该版本是随着对文件的每个改变而增加的编号。此外，保持每个文件的安全哈希。如果两个文件具有相同哈希，则假设它们具有相同(即，并非互不相同)，并且系统可以避免传送或者存储重复文件。

用户也可以共享文件夹。在服务器上，共享的文件夹是独立文件系统。图3中的标号324示出了用于共享的文件夹的服务器表的一个示例，并且用于共享的文件夹的服务器表被存储在存储装置260中。通过创建有共享标识符(例如，SharedFolder1)文件夹和附着到文件夹的一条元数据来将这些共享的文件夹映射到用户的私有文件系统。如以上说明的那样在用于私有系统的服务器表中管理元数据。共享标识符是共享的文件夹的文件系统标识符。在客户端上，用于共享的文件夹的本地安装点表包括用于共享的文件夹的安装点的路径和用于共享的文件夹的共享标识符(fsId)并且被存储在客户端的存储器中。用于不同用户的安装点可以具有不同名称。共享标识符是对客户端不透明的令牌并且包含文件系统标识符。客户端将具有共享标识符的任何文件夹视为共享的文件夹安装点。另外，服务器250中的存储装置260存储用于在服务器260中存储的每个文件的版本信息，并且在图5A和图5B的过程中利用该信息。另外，客户端中的存储器也存储用于在客户端中存储的每个文件的版本信息。

在客户端向服务器用于每个文件的改变时，它们将该文件的先前版本包括作为“基础版本”。如果这一基础版本并未匹配服务器上的文件的当前版本，则服务器创建具有新内容的冲突文件。冲突文件名可以具有唯一格式以清楚地向用户标识它们，比如“文件名(用户名在-年月-日的冲突).文件扩展名”。

在图3的示例中，用户(User1)注册客户端并且创建有具一个共享的文件夹和一个私有文件夹的文件夹结构。User1注册另一Client2，并且Client2将看见与Client1和服务器相同的视图。User2注册客户端，并且User1与User2共享文件夹“SharedFolder1”。User2将“SharedFolder1”重命名为“MyShare”。

恢复

在故障的境况中，服务器可能被完全地丢失并且将必须从备份被恢复。在这一情形中，在恢复之前与服务器同步的客户端将“超前于”服务器。客户端具有服务器不具有的改变。文件版本将高于服务器上的那些文件的版本。如果客户端从服务器直接地更新它们的状态，则本地改变可能都被丢失。在图4A、图5A、图5B中，如果服务器或者客户端是过程的对象，则服务器或者客户端中的处理器可以通过执行在存储器(例如，存储装置)中存储的软件来执行过程。如果故障在服务器(或者外部存储装置)上出现，则服务器通过利用在存储装置260和/或外部存储装置250中存储的数据来恢复服务器中的文件系统。此后，服务器与每个客户端通信并且通过利用在每个客户端中存储的数据来执行如图4A、图5A和图5B中描述的恢复过程。

图4A图示了根据示例实现方式的流程图。在示例流程图中，存在用“.PRIVATE”重命名文件夹，这出现在存在对用于安装点或者共享标识符的路径的改变时。例如，客户端在文件夹的状态从“共享”被改变成“私有”时改变本地安装点中的共享标识符。如图4A中描绘的示例实现方式图示了用于处置服务器恢复的流程图，该流程图利用来自客户端的信息以进行恢复。

在服务器的自恢复(400)之后，服务器向任何请求客户端通知服务器在恢复模式中(401)。客户端确认恢复模式并且继续恢复过程，该恢复过程涉及从服务器取读如以上说明的用于客户端的私有文件系统的服务器表和包括用于共享的文件夹的元数据的服务器表(402)。客户端可以通过取读服务器表或者通过取读包括元数据的其它信息来获得用于相关共享文件夹的元数据。进行恢复过程的示例实现方式，从而使得服务器可以最终有所有文件的最新近内容，并且无文件被丢失或者删除。另外，恢复过程有助于让客户端最终与服务器同步有用于用户的正确文件。示例实现方式也可以防止文件被写入到非既定共享文件夹，这可能向非既定用户泄露数据。

客户端可以执行用于恢复的以下过程。客户端比较它的当前本地安装点表与服务器表中的用于共享的文件夹的每个安装点的元数据(403)，并且确定本地安装点表中的元数据是否不同于服务器表中的服务器元数据(404)。将安装点重命名为“.PRIVATE”出现在本地安装点表的安装点的路径或者安装点共享标识符不同于服务器表的安装点的路径或者安装点共享标识符时(405)。(例如，安装点的路径或者安装点共享标识符在客户端中本地改变)。共享标识符是唯一Id并且对客户端不透明。因此，对于客户端上的安装点列表中的每个安装点与服务器上的列表比较。因此，如果用于任何安装点的路径或者共享标识符不同，则客户端重命名那些安装点。

如果用于客户端上的本地安装点元数据(例如，共享的文件夹)的共享标识符不同于服务器上的安装点元数据(元数据包括安装点的路径或者安装点的共享标识符)(是)，则客户端通过向原安装点名称的末尾追加“.PRIVATE”或者另一前缀、去除本地共享标识符并且使对应的安装点进入规则文件夹(例如，私有文件夹)中来重命名这些安装点名称(405)。之后，这些文件夹将被发送到服务器作为新文件和文件夹。新名称向用户指示在文件夹的共享状态属性中存在冲突并且它们可以再次共享文件夹。

完成比较共享的文件夹的安装点出现在已经比较了所有安装点时(406)。如果安装点尚未都被比较(否)，则用下一安装点重新迭代比较(403)。在完成比较时(是)，客户端遍历整个本地状态并且向服务器发送具有版本(例如，在一个点同步)的所有本地项目(例如，文件、文件夹安装点)，其中恢复标志被设置成真(407)。不要求恢复标志是布尔标志；其它实现方式根据希望的实现方式也是可能的。例如，一个示例实现方式可以根据管理文件的客户端自从客户端上次与服务器同步起是否具有本地改变而涉及‘recoveryPut’(PUT)或者‘recoveryUpdate’(UPDATE)这些值。发送本地项目和与服务器的同步过程涉及具有关于每个文件的文件名、文件路径、哈希和大小的信息的RESTAPIPUT。如果服务器还不具有文件的内容，则它也可以包含它们。服务器调和这些PUT与现有状态。关于图5A进一步描述恢复PUT的细节。

在调和所有PUT时，客户端向服务器通知恢复已经被完成(408)。客户端然后向服务器发送不具有版本(例如，从未与服务器同步)的所有本地文件作为正常操作或者PUT(409)。这些文件变得与在稳定状态中相同被添加到服务器。这一步骤包括由更早的过程重命名成“.PRIVATE”的任何文件夹。客户端然后从服务器拉取关于用户的所有文件的元数据(410)。这将客户端带到与服务器状态最新。

图4B和图4C图示了根据示例实现方式的流程图执行的示例。在图4B的示例中，恢复点是在从备份的恢复已经完成之后的服务器数据的状态。Client1具有被命名为SharedFolder1的私有文件夹并且不具有任何共享的文件夹。对于User1，Client1与服务器通信并且服务器指示它在恢复模式中。客户端比较本地安装点表中的安装点元数据与服务器上的服务器表中的安装点元数据。服务器上的安装点名称ShareFolder1不存在于客户端上，但是客户端具有私有文件夹，该私有文件夹具有相同名称。当没有如在本公开内容中描述的重命名实现方式时，服务器可能开始共享用户的私有文件夹“SharedFolder1”的所有私有内容。为了避免该情形，客户端将私有文件夹“SharedFolder1”重命名成“SharedFolder1.PRIVATE”。客户端也从服务器拉取安装点SharedFolder1细节。

在图4C的示例中，恢复点是在从备份的恢复已经完成之后的服务器的数据的状态。Client1在灾难出现之前的某个时间将它的共享文件夹安装点从“SharedFolder1”重命名成“NewShare”，并且这是client1的当前状态。用于User1的Client1与服务器通信并且服务器指示它在恢复模式中。Client1比较本地安装点表中的安装点元数据与服务器表中的在服务器上的安装点元数据。服务器上的安装点名称(安装点的路径)“SharedFolder1”不同于客户端上的安装点名称(安装点的路径)“NewShare”。因此，使“NewShare”进入私有文件夹中并且它的新名称是“NewShare.PRIVATE”。

在以上示例中，安装点名称是使用的元数据的一个示例。相似重命名也可以出现在共享标识符对于具有相同路径的文件夹而言不同时。

恢复Put和恢复Update的示例实现方式

在客户端发送用于恢复的文件时，客户端使用RESTPUT操作。在这一操作期间，可以存在用于文件的两个可能性：它们确切地是与在它们被同步时相同的内容，或者它们在文件已经被同步之后由用户本地修改。第一情况将被称为PUT，并且第二情况将被称为UPDATE。更具体地，如果与文件关联的当前元数据(例如，大小和/或修改时间)尚未从客户端已经在它的本地数据库中记录的元数据改变(例如，文件自从与服务器的上次同步起尚未本地改变)则可以使用PUT的恢复过程。如果文件自从与上次同步到服务器起已经本地改变(例如，用户本地更新文件而服务器停机并且未接受上传)，则可以使用UPDATE的恢复过程。在服务器变成可用(例如，从故障恢复)并且向客户端通知该恢复时，客户端将本地改变的文件发送作为UPDATE，因为文件自从与服务器的上次成功同步起已经本地改变。在PUT与UPDATE之间的不同是文件是否自从客户端上次与服务器同步起已经被本地改变。在每种情况下，服务器尝试使用来自客户端的数据来恢复自身。

在以下示例中，ClientVersion是由客户端在PUT或者UPDATE中发送的版本。ServerVersion是服务器上的文件的版本。

在服务器经过恢复时，用RecoveryVersion标记每个文件系统，并且在恢复期间未改变RecoveryVersion。这一RecoveryVersion在图5A的恢复开始时被设置为比文件系统上的所有文件的最高版本更高的版本。在恢复期间，大于或者等于RecoveryVersion的任何遇到的ClientVersion向系统指示遇到的更高ClientVersion在从服务器的备份恢复之后被创建。ClientVersion、RecoveryVersion和ServerVersion可以被实施为指示文件版本号的元数据或者根据希望的实现方式通过其它方法。

利用以下实现方式，由此可以有可能接受服务器上的所有文件内容而创建更少冲突文件。在相关领域实现方式中，无论何时ClientVersion未匹配ServerVersion都将创建冲突文件。然而，通过利用恢复put，示例实现方式允许在服务器恢复之后对文件的第一更新成功。如图5A和图5B中描绘的示例实现方式图示了由服务器在服务器与客户端之间的调和过程。在开始如图5A和图5B中所示的过程之前，服务器参考从每个客户端发送的用于每个文件的恢复标志，并且确定客户端是否请求用于每个文件的恢复过程PUT或者UPDATE。如以上描述的那样，恢复标志可以根据文件自从它上次与服务器同步起是否具有局部改变来包括值‘recoveryPut’(PUT)或者‘recoveryUpdate’(UPDATE)。

图5A图示了根据示例实现方式的用于恢复PUT的流程图。恢复PUT可以如以上描述的那样按照客户端恢复文件的形式。服务器从客户端接收文件PUT(500)以获得ClientVersion。执行比较以查明ClientVersion是否比RecoveryVersion更加新(501)。如果不是(否)，则忽略PUT(502)，因为ClientVersion是在可以通过使用服务器和外部存储装置中的文件而被恢复的最高版本之前的版本，因此服务器已经最新(服务器已经具有客户端版本)，并且由此可以忽略PUT。

否则(是)执行检查(503)以查明ServerVersion是否为空(即，服务器不具有副本)。如果ServerVersion为空(是)，则执行PUT以将文件存储作为新文件(504)，因为文件并未存在于服务器上。否则(否)执行检查(505)以查明ServerVersion是否比RecoveryVersion更旧。如果ServerVersion比RecoveryVersion更旧(在505中为是)，则它指示服务器尚未从客户端接收具有比RecoveryVersion更加新的ClientVersion的另一文件。如果ServerVersion比RecoveryVersion更加新(在505中为否)，则它指示服务器已经从客户端接收了具有比RecoveryVersion更加新的ClientVersion的另一文件。

如果ServerVersion比RecoveryVersion更旧(是)，则通过使用从客户端接收的文件来处理PUT作为对现有文件的更新(506)。来自客户端的文件因此用来变成服务器上的文件的最新版本并且被设置为比当时在客户端上存储的所有其它版本更高的版本。完成这一点以将接收的文件指明作为最新版本，并且处理来自客户端的后续文件PUT以使这一文件成为冲突文件。否则(否)执行检查(507)以查明客户端和服务器文件是否具有相同哈希，这指示它们具有相同内容。

如果客户端和服务器文件具有相同哈希(是)，则忽略(508)并且可以丢弃PUT。客户端将在客户端完成恢复之后拉取用于文件的新信息。否则(否)利用客户端文件创建冲突文件(509)，因为另一客户端已经在恢复之后更新了文件，并且可以不可能确定更新如何相配到文件的历史中。在一个示例实现方式中，服务器可以在存储冲突的文件的文件夹中创建冲突文件。因此，服务器可以在与原有文件相同的目录中放入冲突文件。

通过在以上示例实现方式中描述的这一恢复过程，如果服务器接收在恢复点处具有比服务器版本更加新的版本的多个文件，则服务器将多个文件之一管理作为具有新版本的更新的文件，并且将其它文件管理作为与第一文件的冲突文件。恢复点是在从存储装置260和外部存储装置250的备份的恢复完成之后的服务器的数据的状态。第一文件是服务器在多个文件之中首先接收的文件。

通过如在以上示例实现方式中描述的这一恢复过程，服务器可以通过使用在不仅服务器的内部/外部存储装置而且也在客户端中的存储器中存储的文件来恢复文件。另外，服务器可以解决在多个客户端中的文件之中的冲突。

图5B图示了根据示例实现方式的用于恢复UPDATE的流程图。如以上描述的那样，可以按照更新的客户端文件的形式实施恢复UPDATE。对于恢复UPDATE的示例实现方式，如果存在具有比服务器中的文件版本更加新的文件版本的多个客户端，则服务器被配置为将客户端版本之一视为更新的版本而将另一客户端版本视为冲突版本。另外，即使服务器具有如下版本的文件(该版本是客户端文件UPDATE的相同版本)，服务器仍然需要通过使用客户端文件UPDATE来更新服务器中的文件。

在文件UPDATE的示例实现方式中，服务器从客户端接收文件UPDATE(510)。执行检查(511)以查明ServerVersion是否为空，由此指示服务器不具有文件的副本。如果ServerVersion为空(是)，则允许文件UPDATE(512)作为新PUT以将文件添加作为服务器中的新文件。

如果ServerVersion不为空(否)，则执行检查(513)以查明ClientVersion是否与ServerVersion相同。如果ClientVersion与ServerVersion(是)相同，则执行检查(514)以确定ServerVersion是否比RecoveryVersion更旧。如果ServerVersion比RecoveryVersion更旧(是)，则允许现有文件的UPDATE(515)，因为该操作是对现有文件的标准更新。否则(否)ClientVersion是服务器在它回滚时丢失的版本，并且因此ClientVersion在回滚时比RecoveryVersion更加新(516)。

否则如果ClientVersion与ServerVersion不相同，则执行检查(517)以查明ServerVersion是否比RecoveryVersion更旧并且ClientVersion比RecoveryVersion更加新。如果是(是)，则结果是ClientVersion是在恢复之后对文件的第一更新，因此允许(518)UPDATE以用新ClientVersion更新服务器中的现有文件。否则(否)创建冲突文件(519)。

图5C和图5D图示了基于图5A和图5B的示例实现方式在客户端与服务器之间的示例交互。具体而言，图5C和图5D图示了在客户端具有服务器已经丢失的版本时出现的示例交互。因此，示例交互可以对于如图5A和图5B中所示的恢复PUT或者恢复UPDATE而出现。

在图5C中，用户具有三个注册的客户端。服务器在恢复点处并且尝试从客户端恢复丢失的数据。在恢复点处，文件a.txt的ServerVersion是V6，并且RecoveryVersion是V7。Client1上的文件a.txt的ClientVersion是V7，Client2是V8，并且Client3是V5。Client1与服务器通信。在图5D中，服务器从与Client1的交互认识到它具有a.txt的更旧版本，因此服务器用新版本更新它的版本。在图5D示例中，服务器创建ServerVersionV10，这是比所有其它客户端版本更高的版本，而RecoveryVersion保留作为V7。ServerVersion被设置成最高版本以处置用于在文件在客户端侧上被本地编辑而服务器仍在执行与客户端的同步时创建冲突文件的情形。虽然版本名称不会与客户端上相同，但是内容将相同。因此，ServerVersionV10具有与Client1上的V7相同的内容，并且服务器向client1发送ServerVersionV10。Client1的视图保持相同，但是文件a.txt的版本号现在是V10，虽然内容保持与先前ClientVersionV7相同。图5D图示了在客户端/服务器交互之后在客户端和服务器中的视图。

图5E和图5F图示了基于图5A的示例实现方式的在客户端与服务器之间的示例交互。具体而言，图5E和5F图示了在图5C和图5D的交互之后用于由于来自Client3的交互所致的恢复PUT的示例交互。在图5E中，Client3具有a.txt的版本5(V5)，并且Client3不具有共享的文件夹安装点“Share1”并且在“Folder2”之下没有文件。服务器视图是在来自图5D的与Client1的交互之后的视图。从该观点来看，Client3如图5E中所示与服务器交互。在图5F中，服务器认识到它具有比Client3更加新的a.txt的版本，因此服务器向Client3发送a.txt的当前服务器版本(V10)。客户端也拉取“Share1”和“Folder2”的细节以被同步到client3，从而产生如图5F中描绘的视图。

图5G和5H图示了基于图5A和图5B的示例实现方式的在客户端与服务器之间的示例交互。具体而言，图5G和图5H图示了在Client2在如图5E和图5F中所示交互之后发送后续新客户端版本时出现的示例交互。因此，示例交互可以对于如图5A和图5B中所示的恢复PUT或者恢复UPDATE而出现。

在图5G的示例中，Client2具有文件a.txt的版本8(V8)，并且Client2不具有共享文件夹安装点“Share1”。服务器视图是在来自图5F的与Client3的交互之后的视图。Client2在图5G中与服务器交互。在图5H中，服务器认识到它具有比Client2更旧的a.txt的版本，因为RecoveryVersionV7比Client2的ClientVersionV8更旧。然而，服务器已经恢复了它的数据一次(例如，由于ServerVersion被设置为V10)，因此服务器生成用于该文件的冲突。客户端向Client2拉取创建的冲突文件和a.txt的现有版本的细节。客户端也向Client2拉取待同步的“Share1”的细节。在图5H中图示了用于Client2和服务器的所得视图。

最后在计算机内的操作的算法和符号表示方面呈现具体描述的一些部分。这些算法描述和符号表示是由数据处理领域技术人员用来向本领域其他技术人员最有效地传达他们的工作实质的手段。算法是促成希望的最终状态或者结果的系类定义的步骤。在示例实现方式中，执行的步骤需要对有形数量的物理操控以用于实现有形结果。

除非如从前文讨论中清楚的那样另有具体陈述，应理解贯穿该描述，利用诸如“处理”、“计算”、“运算”、“确定”、“显示”等术语的讨论可以包括计算机系统或者其它信息处理设备的动作和过程，该计算机系统或者其它信息处理设备将在计算机系统的寄存器和存储器内表示为物理(电子)数量的数据操控和变换成在计算机系统存储器或者寄存器或者其它信息存储、传输或者显示设备内相似地表示为物理数量的其它数据。

示例实现方式也可以涉及一种用于执行这里的操作的装置。这一装置可以被具体地构造用于所需目的，或者它可以包括由一个或者多个计算机程序有选择地激活或者重新配置的一个或者多个通用计算机。这样的计算机程序可以存储于计算机可读存储介质(比如计算机可读存储介质或者计算机可读信号介质)中。计算机可读存储介质可以涉及有形介质，比如但不限于光盘、磁盘、只读存储器、随机存取存储器、固态设备和驱动或者适合用于存储电子信息的任何其它类型的有形或者非瞬态介质。计算机可读信号介质可以包括介质，比如载波。这里呈现的算法和显示未与任何特定计算机或者其它装置固有地有关。计算机程序可以涉及纯软件实现方式，这些软件实现方式涉及执行希望的实现方式的操作。

可以根据这里的示例用程序和模块使用各种通用系统，或者构造更专门化的装置以执行希望的方法步骤可以证实是便利的。此外，未参照任何特定编程语言描述示例实现方式。将认识到多种编程语言可以用来实施如这里描述的示例实现方式的教导。编程语言的指令可以由一个或者多个处理设备(例如，中央处理单元(CPU)处理器或者控制器)执行。

如在本领域中所知，以上描述的操作可以由硬件、软件或者软件和硬件的某个组合执行。可以使用电路和逻辑器件(硬件)来实施示例实现方式的各种方面，而可以使用在机器可读介质(软件)上存储的指令来实施其它方面，这些指令如果由处理器执行将使处理器执行方法以实现本申请的实现方式。另外，可以仅在硬件中执行本申请的一些示例实现方式，而可以仅在软件中实现其它示例实现方式。另外，可以在单个单元中执行或者可以用任何数目的方式跨多个部件展开描述的各种功能。在由软件执行时，方法可以基于在计算机可读介质上存储的指令由处理器(比如通用计算机)执行。如果希望，则可以在压缩和/或加密格式中在介质上存储指令。

另外，本申请的其它实现方式将从对说明书的考虑和对本申请的教导的实现中为本领域技术人员所清楚。可以单独地或者在任何组合中使用描述的示例实现方式的各种方面和/或部件。旨在于说明书和示例实现方式仅视为示例而本申请的范围和精神实质由所附权利要求指示。

Claims (12)

1.一种服务器，包括：

接口，所述接口被配置为与多个客户端设备对接；

存储器，所述存储器被配置为存储关于在恢复点处的、由所述服务器管理的第一文件的版本的信息，以及

处理器，所述处理器被配置为：

从所述多个客户端设备接收多个文件以通过使用所述多个客户端设备中的所述多个文件来恢复所述服务器中的文件，以及

对于所述多个接收的文件中的具有比在所述恢复点处的所述第一文件的所述版本更加新的版本的第二文件，将所述第二文件中的一个第二文件管理作为所述第一文件的新版本，并且将所述第二文件中的另一第二文件管理作为与所述第二文件中的所述一个第二文件的冲突文件。

2.根据权利要求1所述的服务器，其中所述处理器还被配置为在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新被存储作为针对具有与所述第一文件的所述新版本相同的版本的所述一个或者多个更新的冲突文件。

3.根据权利要求1所述的服务器，其中所述处理器还被配置为在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新被存储作为针对具有以下各项的所述一个或者多个更新的冲突文件：

与所述第一文件的所述新版本不同的版本；以及

并未比所述第一文件的所述版本更加新的版本。

4.根据权利要求1所述的服务器，其中所述处理器被配置为：

将所述多个文件中的文件存储作为针对所述多个文件的如下文件的新文件：所述文件在所述服务器中不具有所述文件的对应文件；以及

将更新存储作为针对所述更新中的如下更新的新文件：所述更新在所述服务器中不具有所述文件中的对应文件。

5.根据权利要求1所述的服务器，其中所述处理器被配置为：

在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新用来在所述第二文件中的所述一个第二文件被管理作为所述第一文件的所述新版本之前更新所述第一文件。

6.根据权利要求1所述的服务器，其中所述处理器被配置为：

从所述多个客户端设备丢弃所述多个文件中的如下接收的文件：所述接收的文件在所述服务器中具有所述文件中的比所述接收的文件更加新的版本的对应文件。

7.一种用于管理服务器的方法，包括：

存储关于在恢复点处的、由所述服务器管理的第一文件的版本的信息，

从所述多个客户端设备接收多个文件以通过使用所述多个客户端设备中的所述多个文件来恢复所述服务器中的文件，

对于所述多个接收的文件中的具有比在所述恢复点处的所述第一文件的所述版本更加新的版本的第二文件，将所述第二文件中的一个第二文件管理作为所述第一文件的新版本，并且将所述第二文件中的另一第二文件管理作为与所述第二文件中的所述一个第二文件的冲突文件。

8.根据权利要求7所述的方法，还包括在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新被存储作为针对具有与所述第一文件的所述新版本相同的版本的所述一个或者多个更新的冲突文件。

9.根据权利要求7所述的方法，还包括在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新被存储作为针对具有以下各项的所述一个或者多个更新的冲突文件：

与所述第一文件的所述新版本不同的版本；以及

并未比所述第一文件的所述版本更加新的版本。

10.根据权利要求7所述的方法，还包括将所述多个文件中的文件存储作为针对所述多个文件的如下文件的新文件：所述文件在所述服务器中不具有所述文件的对应文件；以及将更新存储作为针对所述更新中的如下更新的新文件：所述更新在所述服务器中不具有所述文件中的对应文件。

11.根据权利要求7所述的方法，还包括在从所述多个客户端设备接收多个文件之时，从所述多个客户端设备中的一个客户端设备接收对所述第一文件的一个或者多个更新，以恢复所述服务器中的文件，其中对所述第一文件的所述一个或者多个更新用来在所述第二文件中的所述一个第二文件被管理作为所述第一文件的所述新版本之前更新所述第一文件。

12.根据权利要求7所述的方法，还包括从所述多个客户端设备丢弃所述多个文件中的如下接收的文件：所述接收的文件在所述服务器中具有所述文件中的比所述接收的文件更加新的版本的对应文件。