CN118132331A - 一种基于快照的数据恢复方法 - Google Patents

Abstract

本申请提供了一种基于快照的数据恢复方法、文件管理系统及相关设备，其中，方法包括：RocksDB存储引擎使用快照目录加载目标快照中的文件，其中目标快照是对历史的本地文件系统的文件所做的快照；文件处理模块基于目标快照中待恢复的目标文件，在当前的本地文件系统中或者目标快照中识别与目标文件关联的文件；文件处理模块基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件。该方法可以实现故障场景下不受数据量影响的秒级数据恢复。

Description

一种基于快照的数据恢复方法

技术领域

本申请涉及数据库技术领域，尤其涉及一种基于快照的数据恢复方法、文件管理系统以及计算设备集群、计算机可读存储介质、计算机程序产品。

背景技术

数据库运行过程中会存在像数据丢失、客户误删除数据、存储引擎元数据损坏、存储文件损坏等故障场景，这些故障场景下业务的快速恢复能力是衡量数据库性能的一个重要指标，如果短期内无法修复故障，则数据库将无法正常提供服务，进而对业务产生较大的影响。

发明内容

本申请提供了一种基于快照的数据恢复方法，能够实现数据丢失、客户误删除数据、存储引擎元数据损坏、存储文件损坏等数据库故障场景下节点业务的秒级快速恢复。本申请还提供了对应的文件管理系统、计算设备集群、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种基于快照的数据恢复方法。该方法可以应用于数据库系统的节点，该数据库系统可以包括多个采用RocksDB存储引擎的节点。

本申请提供的一种基于快照的数据恢复方法，包括：RocksDB存储引擎使用快照目录加载目标快照中的文件，其中目标快照是对历史的本地文件系统的文件所做的快照；文件处理模块基于目标快照中待恢复的目标文件，在当前的本地文件系统中或者目标快照中识别与目标文件关联的文件；文件处理模块基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件。

该方法通过利用本地快照与本地目录数据相结合的方式进行本地快速恢复，避免了常规备份恢复方式中从云端下载数据时恢复速度对数据量的依赖，同时通过后台压缩动作(compaction)将快照里面的数据恢复到本地，减少了将文件从快照目录复制到本地目录的时间，前台业务无感知，最终可以实现数据丢失、用户误删数据、RocksDB元数据损坏、存储文件损坏等故障场景下不受数据量影响的秒级数据恢复。

本申请所示的方案中，RocksDB存储引擎使用快照目录加载目标快照中的文件时，是以只读方式加载目标快照中的文件。

一种可能的实施方式中，使用快照目录加载目标快照中的文件时，仅加载目标快照中待恢复的目标文件；同时，使用本地可写目录加载本地可复用的文件。

上述方式，通过使用快照目录和本地可写目录分别加载待恢复的目标文件和本地可复用的文件的双目录加载方式，实现了本地快速恢复，避免了常规备份恢复方式从云端下载数据的流程，同时恢复时长不受数据量影响。

本申请所示的方案中，在文件处理模块基于目标快照中待恢复的目标文件，在当前的本地文件系统或者目标快照中识别与目标文件关联的文件之前，还包括：文件处理模块基于当前的本地文件系统中的文件和目标快照中的文件，在目标快照中识别出待恢复的目标文件。

一种可能的实施方式中，可以通过快照diff动作，对比当前文件系统状态和快照的差异，实现在目标快照中识别出待恢复的目标文件。

本申请所示的方案中，文件处理模块基于所述目标文件和与所述目标文件关联的文件，在当前的本地文件系统中生成新文件，有以下可能的实现方式：

一种可能的实施方式中，文件处理模块基于目标快照中的目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件；

另一种可能的实施方式中，文件处理模块基于目标快照中的目标文件和目标快照中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

具体地，文件处理模块可以通过文件级别的压缩操作(compaction)，在当前的本地文件系统中生成同目标文件和与目标文件关联的文件对应的新文件。其中，该新文件包含有目标文件和与目标文件关联的文件的全部数据。

一种可能的实施方式中，在确定文件处理模块对所有待恢复的目标文件执行完compaction操作后，RocksDB存储引擎可以清理目标快照。

本申请所示的方案中，文件处理模块对目标文件和与目标文件关联的文件执行文件级别的compaction操作可以是后台异步任务。

上述方式，通过将“搬移”待恢复的目标文件的工作即compaction操作下沉到后台异步任务，前台业务完全无感知，可以达到秒级快速恢复的效果。

第二方面，本申请提供了一种文件管理系统，该文件管理系统包括RocksDB存储引擎和文件处理模块，其中：

RocksDB存储引擎，用于使用快照目录加载目标快照中的文件，所述目标快照为对历史的本地文件系统的文件所做的快照；

文件处理模块，用于基于所述目标快照中待恢复的目标文件，在当前的本地文件系统或者所述目标快照中识别与所述目标文件关联的文件；

文件处理模块，用于基于所述目标文件和与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

一种可能的实现方式中，RocksDB存储引擎使用快照目录加载目标快照中的文件时，包括：以只读方式加载目标快照中的文件；仅加载所述目标快照中待恢复的目标文件。

具体实现中，上述文件处理模块还用于，基于当前的本地文件系统中的文件和目标快照中的文件，在目标快照中识别待恢复的目标文件。

一种可能的实现方式中，RocksDB存储引擎还用于，删除当前的本地文件系统中与目标文件关联的文件。

一种可能的实现方式中，RocksDB存储引擎还用于，删除当前的本地文件系统中与目标快照不同的文件。

一种可能的实现方式中，文件处理模块用于基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件时，具体包括：

文件处理模块用于，基于目标快照中的目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

一种可能的实现方式中，文件处理模块用于基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件时，具体包括：

文件处理模块用于，基于目标快照中的目标文件和目标快照中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

一种可能的实现方式中，RocksDB存储引擎还用于，清理目标快照。

第三方面，本申请提供了一种计算设备集群，包括至少一个计算设备，每个计算设备包括处理器和存储器；该至少一个计算设备的处理器用于执行该至少一个计算设备的存储器中存储的指令，以使得该计算设备集群执行如上述第一方面或第一方面中任一种可能的实现方式所提供的基于快照的数据恢复方法。

第四方面，本申请提供了一种包含指令的计算机程序产品，当该指令被计算设备集群运行时，使得该计算设备集群执行如上述第一方面或第一方面中任一种可能的实现方式所提供的基于快照的数据恢复方法。

第五方面，本申请提供了一种计算机可读存储介质，包括计算机程序指令，当该计算机程序指令由计算设备集群执行时，该计算设备集群执行如上述第一方面或第一方面中任一种可能的实现方式所提供的基于快照的数据恢复方法。

附图说明

图1是本申请涉及的一种数据库系统的架构示意图。

图2是本申请实施例提供的一种基于快照的数据恢复方法的流程图。

图3是本申请实施例提供的一种需要进行数据恢复的故障场景示意图。

图4是本申请实施例提供的一种基于快照对故障场景进行数据恢复的过程示意图。

图5是本申请实施例提供的一种故障场景中完成数据恢复后的本地文件系统的状态图。

图6是本申请实施例提供的一种文件管理系统的结构示意图。

图7是本申请实施例提供的一种计算设备的结构示意图。

图8是本申请实施例提供的一种计算设备集群的结构示意图。

图9是本申请实施例提供的一种计算设备集群的实现方式示意图。

具体实施方式

下面将结合附图，对本申请提供的技术方案进行详细描述。

首先对本申请实施例涉及的应用场景进行简要说明。

本申请提供一种基于快照的数据恢复方法，可以用于数据库运行过程中故障场景的恢复。图1给出了一种数据库系统的架构示意图，该数据库系统包括多个节点，每个节点采用RocksDB存储引擎访问存储池中的数据，每个节点可以有一个或多个RocksDB存储引擎。其中，节点用于部署数据库实例，一个数据库实例对应一个数据库，用户可通过数据库实例对数据库进行操作。节点可以是计算机等物理节点，或者是计算机上的逻辑节点。计算机包括但不限于终端或服务器等设备。计算机上的逻辑节点可以通过虚拟化方式得到，例如计算机上的逻辑节点可以为计算机上的虚拟机或容器。

在一种可能的实施例中，该数据库系统采用共享存储架构，多个RocksDB存储引擎构成了共享存储引擎，数据库系统的每个节点可以通过共享存储引擎中的任意一个RocksDB存储引擎访问存储池中的数据，存储池中的数据为所有节点共享。

在数据库运行过程中，会存在数据丢失、用户误删数据、RocksDB元数据损坏、存储文件损坏等故障场景，当这些故障发生时，进行数据恢复的手段通常有两种：备份恢复和灾备恢复。备份恢复方法中，通过定期将数据备份到云端，当数据库出现故障无法恢复时，节点将云端的备份数据下载到本地进行恢复，恢复时间主要取决于数据下载速度，但该方法的恢复时间与数据规模强相关，下载速度受带宽限制，当恢复百万兆字节的数据量时，恢复时间是无法接受的。灾备恢复方法中，通过在节点中部署主备实例，备实例基于复制方式实时同步主实例的数据，当主实例发生故障时，直接由备实例接管业务，降低故障场景对业务的影响，但该方法不适用于用户误删数据的故障场景，且灾备成本较高。

为此，本申请提供了一种基于快照的数据恢复方法，通过利用本地快照与本地目录数据相结合的方式进行本地快速恢复，避免了常规备份恢复方式中从云端下载数据时恢复速度对数据量的依赖，同时通过后台压缩操作(compaction)将快照里面的数据恢复到本地，减少了将文件从快照目录复制到本地目录的时间，业务无感知，最终可以实现数据丢失、用户误删数据、RocksDB元数据损坏、存储文件损坏等故障场景下不受数据量影响的秒级数据恢复。

如图2所示是本申请提供的一种基于快照的数据恢复方法的流程图，该方法具体包括如下步骤201至步骤203。

步骤201、RocksDB存储引擎使用快照目录加载目标快照中的文件。

本申请实施例中，数据库会为其本地文件系统定期维护一个本地快照，本地快照记录了本地文件系统在故障发生前某一时间点的状态。当数据库发生数据丢失、客户误删除数据、RocksDB元数据损坏、存储文件损坏等故障时，可选取最近时间点的快照进行数据恢复。本步骤中的目标快照即为故障场景发生前某时刻对历史的本地文件系统的文件所做的快照，故障场景发生后，需要将文件系统的文件恢复到目标快照中的状态。

图3示例性地给出了一种需要进行数据恢复的可能的故障场景。如图3所示，左侧目标快照显示了历史的本地文件系统的状态：包括文件301至文件306这6个文件；右侧显示了发生故障后当前本地文件系统的状态：包括文件303至文件307这7个文件。

具体地，RocksDB存储引擎使用快照目录加载目标快照中的文件时，是以只读方式加载目标快照中的文件。

一种可能的实施方式中，使用快照目录加载目标快照中的文件时，仅加载目标快照中待恢复的目标文件；同时，使用本地可写目录加载本地可复用的文件。如图3所示，与目标快照相比，当前本地文件系统缺失了文件301和文件302，而文件303至文件306在目标快照和当前本地文件系统中同时存在，为使当前本地文件系统恢复到目标快照中的状态，文件301和文件302即为待恢复的目标文件，文件303至文件306则为本地可复用的文件。于是，该故障场景发生后，RocksDB存储引擎使用快照目录加载文件301和文件302，使用本地可写目录加载文件303至文件306。

通过使用快照目录和本地可写目录分别加载待恢复的目标文件和本地可复用的文件的双目录加载方式，实现了本地快速恢复，避免了常规备份恢复方式从云端下载数据的流程，同时恢复时长不受数据量影响。

实际应用中，为使当前本地文件系统恢复到目标快照中的状态，还需要RocksDB存储引擎删除当前的本地文件系统中与所述目标快照不同的文件，即图3所示当前本地文件系统中的文件307。

步骤202、文件处理模块基于目标快照中待恢复的目标文件，在当前的本地文件系统或者目标快照中识别与目标文件关联的文件。

为使当前本地文件系统恢复到目标快照中的状态，文件处理模块需将待恢复的目标文件“搬移”至当前本地文件系统。一种可能的实施方式中，“搬移”待恢复的目标文件至当前本地文件系统时，需将与待恢复的目标文件关联的文件一同“搬移”。因此，将待恢复的目标文件“搬移”至当前本地文件系统前，需先识别与目标文件关联的文件，而与目标文件关联的文件可以在当前的本地文件系统中，也可以在目标快照中。

本申请实施例中，在执行步骤202之前，文件处理模块需基于当前的本地文件系统中的文件和所述目标快照中的文件，在目标快照中识别出待恢复的目标文件。具体地，可以通过快照diff动作，对比当前文件系统状态和快照的差异，在目标快照中识别出待恢复的目标文件。

步骤203、文件处理模块基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件。

一种可能的实施方式中，文件处理模块基于目标快照中的目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件；

另一种可能的实施方式中，文件处理模块基于目标快照中的目标文件和目标快照中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

具体地，文件处理模块可以通过文件级别的压缩操作(compaction)，在当前的本地文件系统中生成同目标文件和与目标文件关联的文件对应的新文件。其中，该新文件包含有目标文件和与目标文件关联的文件的全部数据。

压缩(compaction)是RocksDB存储引擎常用的一种文件处理策略，可以对文件进行合并。该操作的具体原理是先从待合并的文件中依次读出键-值数据(Key-Value数据)，再由小到大排序后写入一个新的文件中，之后用新生成的文件代替合并之前的文件对外提供服务。

图4示例性地给出了文件处理模块基于目标快照中的目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件的过程示意图。该示例中，与待恢复的目标文件301和文件302关联的文件为文件303和文件305，文件处理模块对目标快照中的文件301、文件302和当前的本地文件系统中的文件303、文件305执行文件级别的compaction操作后，在当前本地文件系统生成了文件308和文件309，文件308和文件309包含了文件301、文件302、文件303和文件305的全部数据，从而实现了将待恢复的目标文件“搬移”至当前本地文件系统，即目标文件301和目标文件302在本地文件系统的恢复。

实际应用中，待恢复的目标文件可能有很多，文件处理模块可通过一次或多次compaction操作来完成将快照中的所有目标文件“搬移”到本地文件系统，图4仅给出了只有两个待恢复的目标文件、通过一次compaction操作完成所有目标文件的“搬移”的情形。本申请实施例中，文件处理模块对目标文件和与目标文件关联的文件执行文件级别的compaction操作时，可以控制每次compaction操作中目标文件的数量以及连续两次compaction操作之间的时间间隔。

一种可能的实施方式中，在确定文件处理模块对所有待恢复的目标文件执行完compaction操作后，RocksDB存储引擎可以清理目标快照。具体地，可以通过遍历versionset下所有CF的所有version，确保没有指向快照目录的sst文件，来确定文件处理模块对所有待恢复的目标文件执行完了compaction操作。

本申请实施例中，文件处理模块对目标文件和与目标文件关联的文件执行文件级别的compaction操作可以是后台异步任务，此时步骤203和步骤201并行处理。

通过将“搬移”待恢复的目标文件的工作即compaction操作下沉到后台异步任务，前台业务完全无感知，可以达到秒级快速恢复的效果。

一种可能的实施方式中，在文件处理模块基于目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件后，RocksDB存储引擎可以删除当前的本地文件系统中与目标文件关联的文件。此时，采用本申请提供的一种基于快照的数据恢复方法完成图4所示故障场景的数据恢复后，最终得到的本地文件系统的状态图如图5所示。

本申请还提供一种文件管理系统，该文件管理系统包括RocksDB存储引擎和文件处理模块，应用于图1所示的数据库系统故障场景下的数据恢复。该文件管理系统部署在图1所示数据库系统的节点上，其中RocksDB存储引擎和文件处理模块可以部署在同一节点，也可以分别部署在不同的节点，本申请不对其进行限制。实际应用中，可以为图1所示数据库系统的每个节点各配置一套该文件管理系统；或者为整个数据库系统配置一套该文件管理系统，该文件管理系统本本身包含了多个RocksDB存储引擎和多个文件处理模块。

如图6所示，示例性给出了一种文件管理系统的结构示意图，该文件管理系统包括：

RocksDB存储引擎，用于使用快照目录加载目标快照中的文件，所述目标快照为对历史的本地文件系统的文件所做的快照；

文件处理模块，用于基于所述目标快照中待恢复的目标文件，在当前的本地文件系统或者所述目标快照中识别与所述目标文件关联的文件；

文件处理模块，用于基于所述目标文件和与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

一种可能的实现方式中，RocksDB存储引擎使用快照目录加载目标快照中的文件时，包括：以只读方式加载目标快照中的文件；仅加载所述目标快照中待恢复的目标文件。

具体实现中，上述文件处理模块还用于，基于当前的本地文件系统中的文件和目标快照中的文件，在目标快照中识别待恢复的目标文件。

一种可能的实现方式中，RocksDB存储引擎还用于，删除当前的本地文件系统中与目标文件关联的文件。

一种可能的实现方式中，RocksDB存储引擎还用于，删除当前的本地文件系统中与目标快照不同的文件。

一种可能的实现方式中，文件处理模块用于基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件时，具体包括：

文件处理模块用于，基于目标快照中的目标文件和当前的本地文件系统中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

一种可能的实现方式中，文件处理模块用于基于目标文件和与目标文件关联的文件，在当前的本地文件系统中生成新文件时，具体包括：

文件处理模块用于，基于目标快照中的目标文件和目标快照中与目标文件关联的文件，在当前的本地文件系统中生成新文件。

一种可能的实现方式中，RocksDB存储引擎还用于，清理目标快照。

本申请还提供一种计算设备700，图7是计算设备700的结构示意图。该计算设备700可以是上述实施例中的主节点或备节点，包括：总线702、处理器704、存储器706和通信接口708。处理器704、存储器706和通信接口708之间通过总线702通信。计算设备700可以是服务器或终端设备。应理解，本申请不限定计算设备700中的处理器和存储器的个数。

总线702可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线702可包括在计算设备700各个部件(例如，存储器706、处理器704、通信接口708)之间传送信息的通路。

处理器704可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

存储器706可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。存储器706还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器706中存储有可执行的程序代码，处理器704执行该可执行的程序代码以实现前述文件管理系统的功能，从而实现基于快照的数据恢复方法。也即，存储器706上存有用于执行基于快照的数据恢复方法的指令。

通信接口708使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备700与其他设备或通信网络之间的通信。

本申请还提供了一种计算设备集群，图8是该计算设备集群的示意图，该计算设备集群可实现上述实施例中的文件管理系统。如图8所示，该计算设备集群包括至少一台如图7所示的计算设备700，该计算设备700可以是服务器，例如是中心服务器、边缘服务器，或者是本地数据中心中的本地服务器。在一些实施例中，计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。

计算设备集群中的一个或多个计算设备700中的存储器706中可以存有用于执行基于快照的数据恢复方法的指令。当计算设备集群中至少一个计算设备执行该指令时，可以使该计算设备集群实现如实施例所述的基于快照的数据恢复方法。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备700的存储器706中也可以分别存有用于执行基于快照的数据恢复方法的部分指令。换言之，一个或多个计算设备700的组合可以共同执行用于执行基于快照的数据恢复方法的指令。

需要说明的是，计算设备集群中的不同的计算设备700中的存储器706可以存储不同的指令，分别用于执行文件管理系统的部分功能。也即，不同的计算设备700中的存储器706存储的指令可以实现文件管理系统中RocksDB存储引擎或文件处理模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，所述网络可以是广域网或局域网等等。图9示出了一种可能的实现方式。如图9所示，两个计算设备700A和700B之间通过网络进行连接。具体地，通过各个计算设备中的通信接口与所述网络进行连接。在这一类可能的实现方式中，计算设备700A中的存储器706中存有执行文件管理系统的RocksDB存储引擎的功能的指令；同时，计算设备700B中的存储器706中存有执行文件管理系统的文件处理模块的功能的指令。

应理解，图9中示出的计算设备700A的功能也可以由多个计算设备700完成。同样，计算设备700B的功能也可以由多个计算设备700完成。

本申请还提供了一种包含指令的计算机程序产品。所述计算机程序产品可以是包含指令的，能够运行在计算设备上或被储存在任何可用介质中的软件或程序产品。当所述计算机程序产品在至少一个计算设备上运行时，使得至少一个计算设备执行基于快照的数据恢复方法。

本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。该计算机可读存储介质包括指令，所述指令指示计算设备执行基于快照的数据恢复方法，或指示计算设备执行基于快照的数据恢复方法。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的保护范围。

Claims (19)

1.一种基于快照的数据恢复方法，其特征在于，所述方法包括：

RocksDB存储引擎使用快照目录加载目标快照中的文件，所述目标快照为对历史的本地文件系统的文件所做的快照；

文件处理模块基于所述目标快照中待恢复的目标文件，在当前的本地文件系统或者所述目标快照中识别与所述目标文件关联的文件；

所述文件处理模块基于所述目标文件和与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

2.根据权利要求1所述的方法，其特征在于，所述方法包括：

所述文件处理模块基于所述当前的本地文件系统中的文件和所述目标快照中的文件，在所述目标快照中识别所述待恢复的目标文件。

3.根据权利要求1或2所述的方法，其特征在于，所述RocksDB存储引擎使用快照目录加载目标快照中的文件，包括：

所述RocksDB存储引擎使用快照目录以只读方式加载目标快照中的文件。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述RocksDB存储引擎使用快照目录加载目标快照中的文件中，仅加载所述目标快照中待恢复的目标文件。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述方法包括：

所述RocksDB存储引擎删除所述当前的本地文件系统中与所述目标文件关联的文件。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述方法包括：

所述RocksDB存储引擎删除所述当前的本地文件系统中与所述目标快照不同的文件。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述文件处理模块基于所述目标文件和与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件，包括：

所述文件处理模块基于所述目标快照中的所述目标文件和所述当前的本地文件系统中与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件；

或者，所述文件处理模块基于所述目标快照中的所述目标文件和所述目标快照中与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

8.根据权利要求1至4任一项所述的方法，其特征在于，所述方法包括：

所述RocksDB存储引擎清理所述目标快照。

9.一种文件管理系统，其特征在于，所述文件管理系统包括：

RocksDB存储引擎，用于使用快照目录加载目标快照中的文件，所述目标快照为对历史的本地文件系统的文件所做的快照；

文件处理模块，用于基于所述目标快照中待恢复的目标文件，在当前的本地文件系统或者所述目标快照中识别与所述目标文件关联的文件；

所述文件处理模块，用于基于所述目标文件和与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

10.根据权利9所述的文件管理系统，其特征在于，所述文件处理模块用于基于所述当前的本地文件系统中的文件和所述目标快照中的文件，在所述目标快照中识别所述待恢复的目标文件。

11.根据权利要求9或10所述的文件管理系统，其特征在于，所述RocksDB存储引擎用于使用快照目录以只读方式加载目标快照中的文件。

12.根据权利要求9至11任一项所述的文件管理系统，其特征在于，所述RocksDB存储引擎使用快照目录加载目标快照中的文件时，仅加载所述目标快照中待恢复的目标文件。

13.根据权利要求9至12任一项所述的文件管理系统，其特征在于，所述RocksDB存储引擎用于删除所述当前的本地文件系统中与所述目标文件关联的文件。

14.根据权利要求9至13任一项所述的文件管理系统，其特征在于，所述RocksDB存储引擎用于删除所述当前的本地文件系统中与所述目标快照不同的文件。

15.根据权利要求9至14任一项所述的文件管理系统，其特征在于，所述文件处理模块具体用于：

所述文件处理模块基于所述目标快照中的所述目标文件和所述当前的本地文件系统中与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件；

或者，所述文件处理模块基于所述目标快照中的所述目标文件和所述目标快照中与所述目标文件关联的文件，在所述当前的本地文件系统中生成新文件。

16.根据权利要求9至12任一项所述的文件管理系统，其特征在于，所述RocksDB存储引擎用于清理所述目标快照。

17.一种计算设备集群，其特征在于，包括至少一个计算设备，每个计算设备包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行如权利要求1至8所述的基于快照的数据恢复方法。

18.一种包含指令的计算机程序产品，其特征在于，当所述指令被计算设备集群运行时，使得所述计算设备集群执行如权利要求1至8所述的基于快照的数据恢复方法。

19.一种计算机可读存储介质，其特征在于，包括计算机程序指令，当所述计算机程序指令由计算设备集群执行时，所述计算设备集群执行如权利要求1至8所述的基于快照的数据恢复方法。