CN115858086A - 数据恢复方法、数据恢复系统、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种数据恢复方法、数据恢复系统、设备及存储介质。其中，方法包括如下的步骤：获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。本申请实施例提供的数据恢复方案用于降低数据恢复操作的复杂性，缩短故障恢复时间。

Description

数据恢复方法、数据恢复系统、设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种数据恢复方法、数据恢复系统、设备及存储介质。

背景技术

容器集群管理系统Kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制。

在Kubernetes平台上，有状态应用会将数据保存在存储卷上，若用户进行误操作后，例如将重要数据删除，能否恢复数据就显得非常重要，且数据恢复操作的复杂性也直接影响着应用的故障恢复时间(Mean Time To Repair，MTTR)，故障恢复时间越长，应用停止服务的时间就越久，影响用户使用。

目前，Kubernetes平台提供的存储快照方案是基于快照重新创建新的存储卷，并重新配置应用使用新创建的存储卷，该数据恢复操作较为复杂，故障恢复时间长。

发明内容

本申请实施例提出了一种数据恢复方法、数据恢复系统、设备及存储介质，用于降低数据恢复操作的复杂性，缩短故障恢复时间。

于是，在本申请的一个实施例中，提供了一种数据恢复方法，其中，包括：

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

在本申请的又一个实施例中，提供了一种数据恢复方法，其中，包括：

获取用户创建的数据恢复资源声明；所述数据恢复资源声明中包括：待恢复存储卷的卷标识以及所述待恢复存储卷对应的第一目标快照的快照标识；

根据所述卷标识，确定所述待恢复存储卷所在的目标工作节点；

根据所述卷标识以及所述快照标识，请求所述目标工作节点执行数据恢复操作；

其中，所述数据恢复操作包括：获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照在本申请的又一实施例中，提供了一种数据恢复系统，其中，包括：容器集群；所述容器集群中包括第一节点；

所述第一节点，用于：

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照

在本申请的又一实施例中，提供了一种电子设备。该电子设备，包括：存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现上述任一项所述的数据恢复方法。

在本申请的又一实施例中，提供了一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述任一项所述的数据恢复方法。

本申请实施例提供的技术方案中，将使用待恢复存储卷的至少一个容器组删除之后，根据第一目标快照修改待恢复存储卷，以恢复待恢复存储卷的数据；重建至少一个容器组的过程中，将恢复好的待恢复存储卷重新挂载到至少一个容器组中。可见，本申请实施例提供的技术方案中无需重新创建新的存储卷，直接基于快照对源存储卷进行修改即可。现有技术中，用户不仅需要创建新的存储卷，还需要管理新创建的存储卷的生命周期以及重新配置应用使用新的存储卷。与现有技术相比，本方案可降低用户操作复杂性，进而缩短故障恢复时间。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的数据恢复系统的示意图一；

图2为本申请一实施例提供的数据恢复系统的示意图二；

图3a为本申请一实施例提供的数据恢复方法的流程示意图；

图3b为本申请又一实施例提供的数据恢复方法的流程示意图；

图4为本申请一实施例提供的数据恢复示例图一；

图5为本申请一实施例提供的容器组创建过程示例图；

图6为本申请一实施例提供的数据恢复示例图二；

图7为本申请一实施例提供的逻辑卷示例图；

图8为本申请一实施例提供的电子设备的结构框图。

具体实施方式

目前，Kubernetes平台所提供的数据恢复方案，是基于快照资源创建新的存储卷，新的存储卷中的数据是源存储卷在快照时间点的数据。该方案的缺点是：用户不仅需要创建新的存储卷，还需要管理新创建的存储卷的生命周期以及重新配置应用的有关存储卷的配置(将应用配置中的原存储卷名称修改为新的存储卷名称)。可见，现有方案存在用户操作复杂的问题，用户操作复杂必然导致故障恢复时间长。

通常，一个存储卷会对应多个快照。若用户想要查看这多个快照，需要新创建多次存储卷；并且在每次创建一个新的存储卷后，用户还需要管理新的存储卷的生命周期并配置应用使用该新的存储卷。最后在确定使用某个快照后，还需要删除多余的新建的存储卷，以免造成存储资源的浪费。

为了使本技术领域的人员更好地理解本申请方案，下面将根据本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

此外，在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来执行或并行执行。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

在对本申请实施例提供的数据恢复方法进行介绍之前，对本申请实施例提供的数据恢复方法所涉及的系统架构进行介绍。如图1所示，所述数据恢复系统包括：容器集群。所述容器集群包括多个节点10；所述多个节点10中包括：中心节点101和多个计算节点102；

所述计算节点102，用于：

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照

本申请实施例提供的技术方案中，将使用待恢复存储卷的至少一个容器组删除之后，根据第一目标快照修改待恢复存储卷，以恢复待恢复存储卷的数据；重建至少一个容器组的过程中，将恢复好的待恢复存储卷重新挂载到至少一个容器组中。可见，本申请实施例提供的技术方案中无需重新创建新的存储卷，直接基于快照对源存储卷进行修改即可。现有技术中，不仅需要创建新的存储卷，还需要管理新创建的存储卷的生命周期以及重新配置应用使用新的存储卷。与现有技术相比，本方案可降低运维成本，降低数据恢复操作的复杂性，缩短故障恢复时间。

上述至少一个容器组可部署在容器集群中的一个计算节点102或多个计算节点102上。

以所述容器集群为Kubernetes集群为例，如图2所示，每个计算节点102上可运行有多个容器组21，至少一个容器组21对应挂载有存储卷22，存储卷22对应有多个快照23。每个计算节点102上还设有Kubelet组件(核心组件)24和Agent组件(代理组件)25。其中，Kubelet组件24用来处理中心节点下发到本计算节点的任务，管理容器组和容器组中的容器；Agent组件25负责逻辑卷的创建、删除、挂载、卸载等操作；负责存储卷快照创建、删除等操作；负责数据恢复操作(具体操作内容将在下述各实施例中介绍)。

中心节点101上可设有API(Application Program Interface，应用程序编程接口)服务组件27和Scheduler组件(调度组件)28。API服务组件27也即API server。APIserver是Kubernetes的重要核心组件，主要提供以下的功能∶提供集群管理的API(Application Program Interface，应用程序编程接口)接口，包括认证授权、数据校验以及集群状态变更等；提供其他模块(或称组件)之间的数据交互和通信的枢纽。Scheduler组件28用于：将容器组调度到合适的计算节点上。

容器集群中中心节点101或某一个计算节点102上还可设有Operator组件(管控组件)26。Operator组件是由Kubernetes自定义资源(CRD，Custom Resource Definition)和控制器(Controller)构成的云原生扩展服务。Operator组件26与上述Agent组件25相互配合，以实现本申请实施例所提供的数据恢复方案。

本申请实施例中各节点、各节点之间以及各组件的具体实现过程将在下述各实施例中相应介绍。

图3a示出了本申请一实施例提供的数据恢复方法的流程示意图。如图2所示，该方法的执行主体可以是上述计算节点102上所运行的Agent组件25。下面以待恢复存储卷所在的工作节点102上的Agent组件25作为数据恢复方法的执行主体为例，对本申请实施例提供的数据恢复方法进行详细介绍。如图3a所示，该方法包括：

301、获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照。

302、在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点。

303、在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

上述301中，实际应用中，上述待恢复存储卷以及待恢复存储卷对应的第一目标快照可由用户来指定。可根据用户指定的卷标识和快照标识，获取所述卷标识所标识的待恢复存储卷以及所述快照标识所标识的第一目标快照。具体地，可根据用户指定的卷标识和快照标识，在本地节点中查找所述卷标识所标识的待恢复存储卷以及所述快照标识所标识的第一目标快照。待恢复存储卷的卷标识可包括待恢复存储卷的卷名称；第一目标快照的快照标识可包括第一目标快照的快照名称。待恢复存储卷具体可以是持久卷(PersistentVolume，PV)。

在一实例中，图2中的Operator组件26可根据由用户创建的数据恢复资源声明，获取待恢复存储卷的卷标识以及所述待恢复存储卷对应的第一目标快照的快照标识；Operator组件26将待恢复存储卷的卷标识以及所述待恢复存储卷对应的第一目标快照的快照标识发送给待恢复存储卷所在的工作节点102上的Agent组件25。其中，数据恢复资源声明中包括：待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的快照标识。待恢复存储卷所在的工作节点102上的Agent组件25根据该卷标识和快照标识，查找待恢复存储卷以及所述待恢复存储卷对应的第一目标快照。

实际应用中，如图2所示，用户可在其终端创建数据恢复资源声明，数据恢复资源声明中包括：待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的快照标识；终端将数据恢复资源声明发送给中心节点101上的API服务组件27，中心节点101上上的API服务组件27可发布用户创建的数据恢复资源声明，计算节点102上的Operator组件26与API服务组件27通信连接，Operator组件26可实时检测API服务组件27是否发布有新的数据恢复资源声明。这样，在API服务组件27发布上述数据恢复资源声明之后，Operator组件26即可：从API服务组件27上获取到该数据恢复资源声明；并根据该数据恢复资源声明，确定出待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的快照标识；将待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的快照标识发送给待恢复存储卷所在的工作节点102上的Agent组件25。待恢复存储卷所在的工作节点102上的Agent组件25根据待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的快照标识，在本地节点上查找待恢复存储卷以及待恢复存储卷对应的第一目标快照。

上述待恢复存储卷可对应有多个快照，快照本质上也是一个存储卷，可称为快照卷。所述多个快照中包括所述第一目标快照。

上述302中，使用待恢复存储卷的至少一个容器组也即是挂载所述待恢复存储卷的至少一个容器组。也就是说，一个存储卷可挂载在一个容器组或多个容器组上。

在使用所述待恢复存储卷的至少一个容器组均被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点。实际应用中，只有使用待恢复存储卷的至少一个容器组均被删除之后，才能确保待恢复存储卷在恢复过程中不被容器组修改，从而保证数据恢复的有效性。

上述第一快照时间点指的是第一目标快照的创建时刻。

上述303中，一个容器组的创建过程是包含存储卷挂载操作的，也就是说，存储卷挂载操作完成之后，该容器组才会被创建。

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

本申请实施例提供的技术方案中，将使用待恢复存储卷的至少一个容器组删除之后，根据第一目标快照修改待恢复存储卷，以恢复待恢复存储卷的数据；重建至少一个容器组的过程中，将恢复好的待恢复存储卷重新挂载到至少一个容器组中。可见，本申请实施例提供的技术方案中无需重新创建新的存储卷，直接基于快照对源存储卷进行修改即可。现有技术中，用户不仅需要创建新的存储卷，还需要管理新创建的存储卷的生命周期以及重新配置应用使用新的存储卷。与现有技术相比，本方案可降低用户操作复杂性，进而缩短故障恢复时间。

在K8s中，应用服务(或应用程序)都是以工作负载(workload)的形式存在。工作负载是对一组容器组(Pod)的抽象模型。工作负载由工作负载声明来定义，工作负载声明中可包括：副本数、各容器组所挂载的存储卷的卷标识。其中，副本数指的是工作负载所包含的容器组数量；卷标识可包括：存储卷名称。

当工作负载的容器组被删除时，由于该工作负载对应的工作负载声明中副本数未更改，K8s系统会在该容器组被删除之后立马启动对该容器组的重建操作。该重建操作包含：将待恢复存储卷重新挂载在该容器组上。若在待恢复存储卷恢复至第一目标快照的第一快照时间点之前，就将待恢复存储卷重新挂载在该容器组上，就会导致数据恢复失败。为了避免在待恢复存储卷恢复至第一目标快照的第一快照时间点之前，将待恢复存储卷重新挂载到容器组上，上述方法还包括：

304、在删除所述至少一个容器组之前，将所述待恢复存储卷设置为不可重新挂载状态。

305、在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态。

将待恢复存储卷设置为不可重新挂载状态，具体地，可对待恢复存储卷添加指定标签。当待恢复存储卷添加有指定标签时，待恢复存储卷处于不可重新挂载状态；当待恢复存储卷未添加有指定标签时，待恢复存储卷处于可重新挂载状态。上述指定标签可根据实际需要来设计，本申请实施例对此不作具体限定。

这样，就算K8s系统在容器组被删除之后立马启动对该被删除的容器组的重建过程，由于此时待恢复存储卷处于不可重新挂载状态，该重建过程将会卡在重新挂载存储卷这一步，只有当待恢复存储卷恢复成可重新挂载状态之后，该重建过程中将待恢复存储卷重新挂载在该容器组上的步骤才能够被执行。这样，可提高数据恢复的有效性和成功率。

在一实例中，上述303中“在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上”，可采用如下步骤来实现：

3031、在重建所述至少一个容器组的过程中，当检测到所述待恢复存储卷为可重新挂载状态时，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

可选地，上述方法，还可包括：

306、在重建所述至少一个容器组的过程中，当检测到所述待恢复存储卷为不可重新挂载状态时，等待针对所述待恢复存储卷的下一次状态检测。

在重建所述至少一个容器组的过程中，可每隔预设时间间隔检测一次所述待恢复存储卷的状态。上述预设时间间隔可根据实际需要来设置，本申请实施例对此不作具体限定。检测待恢复存储卷的状态，也即是检测待恢复存储卷是否添加有指定标签。

可选地，上述方法，还可包括：

307、将所述待恢复存储卷设置为不可重新挂载状态之后，请求删除所述至少一个容器组。

Agent组件在将所述待恢复存储卷设置为不可重新挂载状态之后，向Operator组件发送容器组删除指令；Operator组件接收到容器组删除指令后，将该容器组删除指令发送给API服务组件，以由API服务组件执行容器组删除指令。API服务组件在执行容器组删除指令的过程中，会调用Agent组件将待恢复存储卷从所述至少一个容器组上卸载下来。

当待恢复存储卷及其快照是基于逻辑卷管理技术(Logical Volume Manager，LVM)来实现的时，将第一目标快照合并至待恢复存储卷之后，该第一目标快照就会消失。若待恢复存储卷存在多个快照，用户将待恢复存储卷恢复至第一目标快照的第一快照时间点后，还想看看另一个快照的数据，则需要基于另一个快照对待恢复存储卷进行进一步的数据恢复。恢复完之后，发现这个快照的数据不如第一目标快照的数据，想要将待恢复存储卷恢复至第一快照时间点，但是由于第一目标快照在将第一目标快照合并至待恢复存储卷之后就消失了，导致无法再次将待恢复存储卷恢复至第一快照时间点。为了解决上述问题，上述方法，还可包括：

306、针对恢复至所述第一目标快照的第一快照时间点的所述待恢复存储卷，创建用于替代所述第一目标快照的替代快照。

该替代快照的快照时间点虽然晚于上述第一快照时间点，但是在该替换快照的快照时间点与在第一快照时间点，待恢复存储卷内的数据相同。该替代快照的快照标识可与第一目标快照的快照标识相同。

因此，后续就算待恢复存储卷恢复至其他快照时间点之后，还可基于替代快照将待恢复存储卷恢复至第一快照时间点。

基于本申请实施例提供的技术方案，用户可在待恢复存储卷的多个快照之间来回切换，以查看不同的快照数据。

进一步的，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述工作负载的所述第一容器组上之后，上述方法还可包括：

307、从所述多个快照中除所述第一目标快照以外的其他快照中确定出第二目标快照。

308、在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第二目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第二目标快照的第二快照时间点；

309、在重建所述至少一个容器组的过程中，将恢复至所述第二快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

在本实施例中，基于第二目标快照对待恢复存储卷的数据恢复操作的过程可参照上述各实施例中相应内容，在此不再详述。

进一步的，上述305中“在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态”，可采用如下步骤来实现：

3051、在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点且所述替代快照成功创建之后，将所述待恢复存储卷恢复为可重新挂载状态。

这样，即可确保创建的替代快照代表的是待恢复存储卷在第一快照时间点的状态。

在一种可实现的方案中，所述第一目标快照为写时复制(Copy-on-write，COW)快照。COW机制，即对原始存储卷的数据内容进行更改时，原始存储卷中被更改位置的原始数据会被拷贝到写时复制快照中，新的数据则写入到原始存储卷中相应位置。这样原始存储卷中保存着最新的全量数据，而写时复制快照中则保存着已更改的原始数据。

相应的，上述302中“在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点”，可采用如下步骤来实现：

3021、使用所述待恢复存储卷的至少一个容器组被删除之后，将所述待恢复存储卷中的待恢复数据替换为所述第一目标快照中的数据，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点。

其中，所述待恢复数据在所述待恢复存储卷中的位置与所述数据在所述第一目标快照中的位置相互对应。其中，所述待恢复数据在所述待恢复存储卷中的位置与所述数据在所述第一目标快照中的位置相互对应。

实际应用是，可将第一目标快照合并至待恢复存储卷中，以将待恢复存储卷中的待恢复数据替换为第一目标快照中的数据。

需要说明的是，将待恢复存储卷中的待恢复数据替换为第一目标快照中的数据的步骤本质上是在更改待恢复存储卷。由于COW机制的存在，将待恢复存储卷中的待恢复数据替换为第一目标快照中的数据的步骤有可能会触发待恢复存储卷对应的多个快照内的数据更新。

可选地，上述方法，还可包括：

310、向Operator组件返回数据恢复操作的结果。

所述结果包括：成功结果和失败结果；失败结果中包括失败原因。

具体地，当Agent组件在本地节点未查找到待恢复存储卷和第一目标快照中的任意一个时，向Operator组件返回失败结果。

当未能成功为待恢复存储卷添加指定标签时，向Operator组件返回失败结果。

当待恢复存储卷未能成功恢复到第一快照时间点时，向Operator组件返回失败结果。

当替代快照未能成功创建时，向Operator组件返回失败结果。

当未能成功删除待恢复存储卷的指定标签时，向Operator组件返回失败结果。

当成功删除待恢复存储卷的指定标签时，向Operator组件返回成功结果。

Operator组件接收到上述结果后，请求API服务组件更新数据恢复资源声明中的状态。当结果为成功结果时，将其状态修改为成功；当结果为失败结果时，将其状态修改为失败及其失败原因。这样，用户即可获知本次数据恢复操作的成功与否。

在一种可实现的方案中，数据恢复资源声明中可包括：资源类型、资源名称、待恢复存储卷的卷标识、第一目标快照的快照标识、有关恢复失败原因的第一预留字段、有关恢复状态的第二预留字段。

API服务组件可填写其所发布的数据恢复资源声明中第一预留字段和第二预留字段。当数据恢复操作成功时，API服务组件可将第二预留字段置为成功；当数据恢复失败时，API服务组件可将第二预留字段置为失败，且将第一预留字段置为数据恢复失败的原因。这样，用户通过读取API服务组件所发布的数据恢复资源声明即可了解恢复情况以及失败原因。

注：本申请实施例提供的待恢复存储卷及其对应的多个快照均为本地存储卷。

图3b示出了本申请又一实施例提供的数据恢复方法的流程示意图。如图2所示，该方法的执行主体可以是上述计算节点102上所运行的Operator组件26。下面以工作节点102上的Operator组件26作为数据恢复方法的执行主体为例，对本申请实施例提供的数据恢复方法进行详细介绍。如图3b所示，该方法包括：

S11、获取用户创建的数据恢复资源声明。

其中，所述数据恢复资源声明中包括：待恢复存储卷的卷标识以及所述待恢复存储卷对应的第一目标快照的快照标识。

S12、根据所述卷标识，确定所述待恢复存储卷所在的目标工作节点。

S13、根据所述卷标识以及所述快照标识，请求所述目标工作节点执行数据恢复操作。

其中，所述数据恢复操作包括：获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

上述S11中，Operator组件可每隔预设时间间隔去查询API服务组件是否发布有新的数据恢复资源声明；若查询到API服务组件是否发布有新的数据恢复资源声明，则去获取这个新的数据恢复资源声明。

上述S12中，实际应用中，上述Operator组件可从API服务组件处获取待恢复存储卷对应的存储卷声明；其中，该存储卷声明中包括但不限于：存储容量、存储卷名称、所在节点的节点信息；根据待恢复存储卷对应的存储卷声明中的节点信息，确定待恢复存储卷所在的目标工作节点。待恢复存储卷及其对应的多个快照均位于目标工作节点上。注：本申请实施例提供的待恢复存储卷及其对应的多个快照均为本地存储卷。

上述S13中，当目标工作节点不是本地节点时，可向目标工作节点发送数据恢复请求，数据恢复请求中包括：所述卷标识以及所述快照标识。当目标工作节点是本地节点时，请求本地节点执行数据恢复操作，具体地，Operator组件请求本地节点上的Agent组件执行数据恢复操作。

本申请实施例提供的技术方案中，将使用待恢复存储卷的至少一个容器组删除之后，根据第一目标快照修改待恢复存储卷，以恢复待恢复存储卷的数据；重建至少一个容器组的过程中，将恢复好的待恢复存储卷重新挂载到至少一个容器组中。可见，本申请实施例提供的技术方案中无需重新创建新的存储卷，直接基于快照对源存储卷进行修改即可。现有技术中，用户不仅需要创建新的存储卷，还需要管理新创建的存储卷的生命周期以及重新配置应用使用新的存储卷。与现有技术相比，本方案可降低用户操作复杂性，进而缩短故障恢复时间。

可选地，所述数据恢复操作还包括：在删除所述至少一个容器组之前，将所述待恢复存储卷设置为不可重新挂载状态；在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态。所述方法，还可包括：

S14、在所述待恢复存储卷被设置为不可重新挂载状态之后，请求删除所述至少一个容器组。

Operator组件可请求API服务组件删除所述至少一个容器组，具体地，Operator组件可向API服务组件发送容器组删除指令；API服务组件执行容器组删除指令，以删除所述至少一个容器组。

下面将结合图4对本申请实施例提供的数据恢复方法进行详细介绍：

实际应用中，Agent组件在接收到Operator组件发来的待恢复存储卷的卷标识以及待恢复存储卷对应的第一目标快照的卷标识后，执行如下步骤：

401、查看本地节点是否存储有待恢复存储卷以及待恢复存储卷对应的第一目标快照。

若本地节点不存在待恢复存储卷和第一目标快照中的一个，则执行下述步骤411；若本地同时存在上述待恢复存储卷和所述第一目标快照，则执行下述步骤402。

402、为待恢复存储卷添加指定标签。

若添加成功，则执行步骤403和406；若添加失败，则执行步骤411。

403、在Kubelet组件的调用下，将待恢复存储卷从至少一个容器组上卸载下来。

404、在Kubelet组件的调用下，判断待恢复存储卷是否有指定标签。

若没有，则执行步骤405；若有，则间隔第一预设时间间隔后返回执行步骤404。

405、在重建至少一个容器组的过程中，将待恢复存储卷重新挂载到至少一个容器组上。

406、判断使用待恢复存储卷的至少一个容器组是否都已卸载。

若是，则执行步骤407；若否，则间隔第二预设时间间隔后返回执行步骤406。

407、将待恢复存储卷恢复至第一目标快照的第一快照时间点。

若恢复成功，则执行步骤408；若恢复失败，则执行步骤411。

408、针对待恢复存储卷，创建用于替代第一目标快找的替代快照。

若创建成功，则执行步骤409；若创建失败，则执行步骤411。

409、删除待恢复存储卷的指定标签。

若删除成功，则执行步骤410；若删除失败，则执行步骤411。

410、通知Operator组件数据恢复成功。

411、通知Operator组件数据恢复失败及其原因。

在一种具体实现方案中，所述待恢复存储卷以及所述第一目标快照是基于逻辑卷管理技术来实现的。也即上述待恢复存储卷具体为LVM物理逻辑卷，快照具体为LVM快照卷。LVM是Linux下对磁盘进行管理的一种机制。用户可将若干个物理磁盘或磁盘分区连接为一个整块的卷组701(volume group)，形成一个存储池。管理员可以在卷组上创建逻辑卷702(logical volume)，并进一步在逻辑卷上创建文件系统，磁盘与LVM存储池的关系如图7所示。

LVM支持在逻辑卷上创建快照卷，LVM快照卷采用COW机制(Copy on Write，写时复制)，即对原始逻辑卷数据内容进行更改时，原始卷中对应位置的数据会被拷贝到快照卷中，新的数据则写入到原始卷对应位置。这样原始卷中保存着最新的全量数据，而快照卷中则保存着已更改的原始数据。

当想要将逻辑卷数据还原到某一快照点时，通过数据合并能力(Merge能力)，即可将逻辑卷数据和指定快照卷数据进行融合，原始逻辑卷中的新数据被快照卷中的旧数据覆盖，这样逻辑卷中的数据即为快照点时刻的数据。不过，执行合并后，已合并的LVM快照卷随之消失。但同一逻辑卷的其他快照卷不会消失，依然可以通过数据合并方式将逻辑卷数据还原到其他快照时间点。

此外，K8s作为容器编排系统，将存储、网络交由开发者去实现。对于存储而言，K8s提供了一套CSI(Container Storage Interface，容器存储接口)标准，即将容器组Pod挂载存储卷的操作抽象为通用的接口，由各开发者实现各自的存储逻辑。CSI接口可包括：创建存储卷；删除存储卷；将存储卷格式化并挂载至目标容器目录、将存储卷从目标容器目录卸载、创建快照、删除快照等接口。

为灵活支持各个开发者在K8s上开发应用，K8s支持自定义资源声明。本申请自定义数据恢复资源声明，其作用是告诉系统将指定存储卷数据还原到指定快照时刻。该数据恢复资源声明所包含的内容可参加上述各实施例中相应内容。

采用本申请实施例提供的技术方案可实现将存储卷的数据快速恢复至某个秒级的时间点。下面将详细介绍本申请实施例提供的技术方案所依赖的两个组件：Agent组件和Operator组件，下面将详细介绍。

K8s的所有节点上都部署有Agent组件，其负责如下操作：

1、负责LVM逻辑卷的创建/删除/挂载/卸载等操作。

当K8s调度容器组Pod到某一节点，若该容器组Pod对应的容器组声明中声明有存储卷，则该节点上的Kubelet组件会通过调用创建存储卷接口，以请求本节点的Agent组件创建一个LVM逻辑卷，以作为容器组的存储卷，并挂载到容器组中的容器中。

2、负责存储卷快照创建/删除操作。

当上述节点上的Kubelet组件调用创建快照接口时，存储卷所在节点上的Agent组件会在本节点创建一个LVM快照卷作为存储卷的快照。

3、负责数据恢复操作。

当收到执行数据恢复指令后，Agent会合并LVM逻辑卷和快照卷；数据合并后快照卷会消失，Agent会基于合并后的存储卷创建一个快照卷，这样保证原快照资源不丢失。

K8s上的某一个节点上部署有Operator组件，其负责如下操作：

时刻观察Kubernetes平台上是否有数据恢复资源声明被创建；

从数据恢复资源声明中获取存储卷、存储快照等信息；

获取数据恢复资源声明中的指定存储卷对应的工作负载的信息；

获取使用指定存储卷的所有容器组信息，容器组可能来自于不同的工作负载，并通知API服务组件重启这些容器组；其中，重启容器组包括：删除容器组和重建容器组。

调用指定存储卷所在节点上的Agent组件，由Agent组件执行数据合并操作；

Agent组件执行完毕后返回信息，Operator组件会更新数据恢复资源声明中的相关字段；

观察容器组是否重启成功，若成功则数据恢复完成。

图5示出了存储卷的创建过程：

501、用户创建Pod资源声明和存储卷资源声明。

502、Scheduler组件发现有Pod创建并将其调度到合适的工作节点。

503、Kubelet组件发现有新的Pod调度到本节点，执行Pod创建工作。

504、Kubelet组件调用Agent以创建/格式化/挂载存储卷。

505、Kubelet组件通知API服务组件Pod创建完毕。

506、流程完毕。

图6示出了数据恢复过程：

601、用户创建Flashback资源(也即上文中的数据恢复资源声明)

602、Operator组件发现有新的Flashback资源创建。

603、Operator组件调用存储卷对应节点上的Agent组件，传递Flashback资源中声明的存储卷信息和快照信息，要求Agent组件执行数据闪回操作(也即上文中的数据恢复操作)

604、Operator组件查询有哪些Pod使用到Flashback资源中声明的存储卷，并要求重启这些Pod。

605、Agent组件通知Operator组件数据闪回操作已完毕，告知其成功或失败及其原因。

606、Operator组件请求更新Flashback资源的状态为成功或失败。

607、数据闪回完毕。

本申请实施例提供的数据恢复方法可以在以下场景中迅速恢复数据：人为误操作、应用程序漏洞造成的数据损坏、存储系统漏洞造成的数据损坏。实际应用中，可定期进行数据备份，按照设定的周期，每日、每周或每月自动执行快照策略对数据进行备份，和/或应用更新等系统临时变更时，为防止操作错误，在执行变更前手动创建快照对系统进行备份。

以人为误操作为例，用户误操作某一存储卷(也即待恢复存储卷)的数据之后，用户只需要通过API服务组件创建数据恢复资源声明即可，后续由系统按照上述各实施例提供的方法自动完成整个数据恢复过程。这样，就可以将数据恢复到人为误操作之前的状态，实现了数据恢复。

可见，本申请实施例提供的技术方案中，用户只需要执行一步数据恢复资源声明的创建操作即可完成整个数据恢复过程，不仅能够降低人工运维成本，还能够缩短故障恢复时间。

综上所述，本申请实施例提供的数据恢复方案中用户可以在同一个存储卷上进行历史数据的快速还原，无需创建新存储卷，因此，无需更改应用配置，这样带来的好处是：

低运维成本：相比K8s原生提供的数据还原方式，本方案不需要创建新存储卷，也就不需要更改工作负载的配置，直接还原存储卷数据到某历史时刻即可；

易操作：本方案提供了自定义资源声明——数据恢复资源声明，使用者仅需创建该资源声明，系统组件Operator和Agent会执行一些列操作对数据进行恢复。本方案针对K8s存储卷还原能力的天生缺点进行改进，改善K8s下应用的MTTR指标，降低因应用停服时间长导致的损失。

图8示出了本申请一实施例提供的电子设备的结构示意图。如图8所示，所述电子设备包括存储器1101以及处理器1102。存储器1101可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令。存储器1101可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器，电可擦除可编程只读存储器，可擦除可编程只读存储器，可编程只读存储器，只读存储器，磁存储器，快闪存储器，磁盘或光盘。

所述存储器1101，用于存储程序；

所述处理器1102，与所述存储器1101耦合，用于执行所述存储器1101中存储的所述程序，以实现上述各方法实施例提供的数据恢复方法。

进一步，如图8所示，电子设备还包括：通信组件1103、显示器1104、电源组件1105、音频组件1106等其它组件。图8中仅示意性给出部分组件，并不意味着电子设备只包括图8所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各方法实施例提供的数据恢复方法的步骤或功能。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如只读存储器/随机存取存储器、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (13)

1.一种数据恢复方法，其中，包括：

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

2.根据权利要求1所述的方法，其中，还包括：

在删除所述至少一个容器组之前，将所述待恢复存储卷设置为不可重新挂载状态；

在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态。

3.根据权利要求2所述的方法，其中，在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上，包括：

在重建所述至少一个容器组的过程中，当检测到所述待恢复存储卷为可重新挂载状态时，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

4.根据权利要求3所述的方法，其中，还包括：

在重建所述至少一个容器组的过程中，当检测到所述待恢复存储卷为不可重新挂载状态时，等待针对所述待恢复存储卷的下一次状态检测。

5.根据权利要求2至4中任一项所述的方法，其中，还包括：

将所述待恢复存储卷设置为不可重新挂载状态之后，请求删除所述至少一个容器组。

6.根据权利要求2至4中任一项所述的方法，其中，还包括：

针对恢复至所述第一目标快照的第一快照时间点的所述待恢复存储卷，创建用于替代所述第一目标快照的替代快照。

7.根据权利要求6所述的方法，其中，在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态，包括：

在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点且所述替代快照成功创建之后，将所述待恢复存储卷恢复为可重新挂载状态。

8.根据权利要求1至4中任一项所述的方法，其中，所述第一目标快照为写时复制快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点，包括：

使用所述待恢复存储卷的至少一个容器组被删除之后，将所述待恢复存储卷中的待恢复数据替换为所述第一目标快照中的数据，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；所述待恢复数据在所述待恢复存储卷中的位置与所述数据在所述第一目标快照中的位置相互对应。

9.一种数据恢复方法，其中，包括：

获取用户创建的数据恢复资源声明；所述数据恢复资源声明中包括：待恢复存储卷的卷标识以及所述待恢复存储卷对应的第一目标快照的快照标识；

根据所述卷标识，确定所述待恢复存储卷所在的目标工作节点；

根据所述卷标识以及所述快照标识，请求所述目标工作节点执行数据恢复操作；

其中，所述数据恢复操作包括：获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

10.根据权利要求9所述的方法，其中，所述数据恢复操作还包括：在删除所述至少一个容器组之前，将所述待恢复存储卷设置为不可重新挂载状态；在所述待恢复存储卷成功恢复至所述第一目标快照的第一快照时间点之后，将所述待恢复存储卷恢复为可重新挂载状态；

所述方法，还包括：

在所述待恢复存储卷被设置为不可重新挂载状态之后，请求删除所述至少一个容器组。

11.一种数据恢复系统，其中，包括：容器集群；所述容器集群中包括计算节点；

所述计算节点，用于：

获取待恢复存储卷以及所述待恢复存储卷对应的第一目标快照；

在使用所述待恢复存储卷的至少一个容器组被删除之后，根据所述第一目标快照，修改所述待恢复存储卷，以将所述待恢复存储卷恢复至所述第一目标快照的第一快照时间点；

在重建所述至少一个容器组的过程中，将恢复至所述第一快照时间点的所述待恢复存储卷重新挂载在所述至少一个容器组上。

12.一种电子设备，其中，包括：存储器和处理器，其中，

所述存储器，用于存储程序；

所述处理器，与所述存储器耦合，用于执行所述存储器中存储的所述程序，以实现权利要求1至10中任一项所述的方法。

13.一种存储有计算机程序的计算机可读存储介质，其中，所述计算机程序被计算机执行时能够实现权利要求1至10中任一项所述的方法。

Images