一种备份数据的生成方法、装置、容灾系统及电子设备

技术领域

本申请涉及数据备份技术领域，尤其是涉及一种备份数据的生成方法、装置、容灾系统及电子设备。

背景技术

随着互联网时代的发展以及大数据时代的到来，越来越多的企业将线上的企业应用由传统架构应用向容器化和微服务架构转变，微服务架构转变是企业级应用在技术架构和设计理念上的重大变革，也是支撑企业数字化转型的关键因素，而Kubernetes作为一个开源的容器编排引擎和为工业级的容器管理平台，已经成为微服务应用编排和容器自动化部署的事实标准。

Kubernetes中关于容器环境部署的应用及数据的容灾显得越来越重要，而传统架构应用的容灾方案无法很好的工作于Kubernetes容器环境，且需要全新的以云原生应用为中心的异地容灾方案。

发明内容

有鉴于此，本申请的目的在于提供一种备份数据的生成方法、装置、容灾系统及电子设备，通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

第一方面，本申请实施例提供了一种备份数据的生成方法，所述备份数据的生成方法包括：

当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表；

将所述目标对象列表中的每个目标资源按照预设顺序取出，并将每个所述目标资源以键值对的形式存储至线程安全存储库；

将存在相互关联关系的所述目标资源的主键存储至事件工作队列表中；

基于所述事件工作队列表和所述线程安全存储库，完成对所述目标资源的备份。

进一步的，所述当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表，包括：

当监听到有目标类型的目标资源被创建后，针对于每个所述目标资源，获取所述目标资源对应的获取时间；

针对于每个所述目标资源，将所述目标资源进行格式转换，生成与所述目标对象列表的格式相适配的目标资源；

根据所述获取时间，将转换格式的所述目标资源添加至所述目标类型对应的所述目标对象列表中的对应位置。

进一步的，所述将所述目标对象列表中的每个目标资源按照预设顺序取出，并将每个所述目标资源以键值对的形式存储至线程安全存储库，包括：

将所述目标对象列表中的每个所述目标资源按照排序规则进行顺序取出，确定每个所述目标资源的主键和所述主键对应的目标值；

将所述目标资源的所述主键和所述主键对应的目标值，将目标资源以键值对的形式存储至线程安全存储库。

进一步的，所述将存在相互关联关系的所述目标资源的主键存储至事件工作队列表中，包括：

根据各个所述目标资源中应用程序编程接口的身份标识，确定各个所述目标资源之间的相互关联关系；

将存在所述相互关联关系的所述目标资源的主键存储至事件工作队列表中。

进一步的，在所述基于所述事件工作队列表和所述线程安全存储库，完成对所述目标资源的备份之后，所述备份数据的生成方法还包括：

获取所述目标资源的查询请求；其中，所述查询请求中包含目标查询请求的目标身份标识；

根据所述查询请求，确定所述查询请求对应的目标应用程序编程接口；

根据所述目标应用程序编程接口，确定对应的事件工作队列表；

基于所述事件工作队列表，确定所述事件工作队列表中目标资源的主键；

根据所述主键，确定与所述主键相匹配的目标资源。

进一步的，所述备份数据的生成方法还包括：

在外部发生容灾后，将目标资源的备份经由外部存储服务库发送至Kubernetes主集群，以便所述Kubernetes主集群进行容灾后的恢复处理。

第二方面，本申请实施例还提供了一种备份数据的生成装置，所述备份数据的生成装置包括：

获取模块，用于当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表；

第一存储模块，用于当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表；

第二存储模块，用于将存在相互关联关系的所述目标资源的主键存储至事件工作队列表中；

备份模块，用于基于所述事件工作队列表和线程安全存储库，完成对所述目标资源的备份。

第三方面，本申请实施例还提供了一种备份数据的容灾系统，包括如第二方面所述的备份数据的生成装置、Kubernetes主集群、Kubernetes备集群以及外部存储服务库：

所述Kubernetes主集群，用于根据外部的容灾备份请求，将目标类型的目标资源的备份发送至所述外部存储服务库；

所述外部存储服务库，用于将所述Kubernetes主集群生成的所述目标类型的所述目标资源的备份数据发送至所述Kubernetes备集群；

所述Kubernetes备集群，用于接收所述Kubernetes主集群备份的所述目标资源，以便进行容灾处理。

本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述的备份数据的生成方法的步骤。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如上述的备份数据的生成方法的步骤。

本申请实施例提供的生成方法、装置、容灾系统以及电子设备，与现有技术中的相比，本申请提供的实施通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的一种备份数据的生成方法的流程图；

图2示出了本申请实施例所提供的一种备份数据的生成方法中一实施例的流程框图；

图3示出了本申请实施例所提供的一种备份数据的生成装置的结构示意图；

图4示出了本申请实施例所提供的一种备份数据的容灾系统的结构示意图之一；

图5示出了本申请实施例所提供的一种备份数据的容灾系统的结构示意图之二；

图6示出了本申请实施例所提供的电子设备的结构示意图。

图中：

10-备份数据的容灾系统；100-Kubernetes主集群；200-外部存储服务库；300-备份数据的生成装置；310-获取模块；320-第一存储模块；330-第二存储模块；340-备份模块；350-查询模块；360-恢复模块；400-Kubernetes备集群；600-电子设备；610-处理器；620-存储器；630-总线。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本申请保护的范围。

首先，对本申请可适用的应用场景进行介绍。经研究发现，Kubernetes中关于容器环境部署的应用及数据的容灾显得越来越重要，而传统架构应用的容灾方案无法很好的工作于Kubernetes容器环境，且需要全新的以云原生应用为中心的异地容灾方案。

且传统的容灾备份一种是通过定时任务备份存储资源数据的etcd，虽然能够实现备份，但是etcd不仅仅存放资源数据，还存放node和podip等信息，并且只能够在原集群进行还原，通过etcd还原的粒度较大，存在很多不确定性，且只能全量备份；而另一种通velero的备份方式，但是目前通过velero实现定时份时，虽然能够实现备份功能，但是实时性较差，也就是说，一旦在非备份的时间内，集群出现了不可恢复的致命性问题时，便会出现数据丢失严重的情况，且velero方式的备份需要使用者掌握Kubernetes备份的专业知识和工具，这无形中增大了使用成本。

基于此，本申请实施例提供了一种备份数据的生成方法、装置、容灾系统及电子设备，通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

请参阅图1，图1为本申请实施例所提供的一种备份数据的生成方法的流程图。所如图1中所示，本申请实施例提供的备份数据的生成方法，包括以下步骤：

S101、当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表。

该步骤中，使用反射器(Reflector)来实时监听是否有目标类型的目标资源被创建，具体为使用反射器(Reflector)来实时监听Kubernetes集群的资源变更接口(watchAPI)，当反射器(Reflector)发现Kubernetes集群的资源变更接口(watch API)处有目标类型的目标资源被创建后，将该目标类型的目标资源通过Kubernetes集群的列表调用接口(list API)获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表中。

这里，目标对象列表中可以但不限制于设置为单进单出的对象列表，且目标对象列表中可以具体但不限制于为：先进先出队列(Delta Fifo)。

上述中，目标类型用于表征适用于不同应用场景的不同类型的资源，具体可以包括各个企业的核心业务数据以及各个企业的人员构成数据，且目标资源可以为目标类型中新增的任一资源数据，也可以是目标类型中需要首次备份的资源数据，这里，目标资源具体可以为核心业务数据中新增的核心业务数据。

其中，Kubernetes集群服务采用管理节点全托管的方式，为用户提供简单易用、高可靠、功能强大的容器管理服务，且在Kubernetes集群中，可以创建容器，容器中则可以运行应用实例。

进一步的，所述S101包括以下子步骤：

子步骤1011、当监听到有目标类型的目标资源被创建后，针对于每个所述目标资源，获取所述目标资源对应的获取时间。

该步骤中，在监听到有目标类型的目标资源被创建后，针对于获取到的任一一个目标资源，首先确定该目标资源对应的获取时间，并将所述目标资源按照对应的获取时间存储至目标对象列表。

子步骤1012、针对于每个所述目标资源，将所述目标资源进行格式转换，生成与所述目标对象列表的格式相适配的目标资源。

该步骤中，在将目标资源按照对应的获取时间存储至目标对象列表后，首先会将目标资源按照目标对象列表所遵循的格式规范进行格式转换，生成与所述目标对象列表的格式相适配的目标资源。

这里，将目标资源按照目标对象列表所遵循的格式规范进行格式转换的方式可具体但不限制于使用循环测试(processLoop)的调参方法进行格式转换。

子步骤1013、根据所述获取时间，将转换格式的所述目标资源添加至所述目标类型对应的所述目标对象列表中的对应位置。

该步骤中，在将目标资源进行格式转换生成与目标对象列表的格式相适配的目标资源后，将目标资源添加至目标类型对应的所述目标对象列表中的对应位置，并且在后续的输出时，按照调整后的目标对象列表中每个目标资源所在的位置的预设顺序进行依次出列，其中，目标对象列表中的对应位置的排序是按照目标资源的获取时间进行确定的，具体可以为，获取目标资源的获取时间越靠前，则该目标资源在目标对象列表中的位置越靠前。

S102、将所述目标对象列表中的每个目标资源按照预设顺序取出，并将每个所述目标资源以键值对的形式存储至线程安全存储库。

该步骤中，从目标对象列表(Delta Fifo)中按照预设顺序依次弹出目标资源，并建立每个目标资源的索引，并以建立目标资源索引的方式对目标对象列表中每个目标资源进行存储，并存储至线程安全存储库中。

其中，建立目标资源索引的具体方式包括但不限制于为建立目标资源的键值对。

这里，从目标对象列表(Delta Fifo)中按照预设顺序依次弹出目标资源的方式是通过Kubernetes集群中的Informer机制，Informer机制是带有本地缓存和索引的缓存，其中，本地缓存的设备为本地缓存库(Store)，而索引的缓存机制为Index。

其中，本地缓存库(Store)用于存储目标资源的键(key)和键对应的值。

上述中，本地缓存库(Store)包括但不限制为数据存储器(data store)，且数据存储器(data store)中定义了一个名为MetaNamespaceKeyFunc的默认方法，可以为对象生成一个/形式的目标资源的键。且Kubernetes集群中的基础控制器(basecontroller)会通过NewIndexerInformer来创建Informer机制、Informer机制中的Index和Store。

进一步的，步骤S102中的将所述目标对象列表中的每个目标资源按照预设顺序取出，并将每个所述目标资源以键值对的形式存储至线程安全存储库，包括以下子步骤：

子步骤1021、将所述目标对象列表中的每个所述目标资源按照排序规则进行顺序取出，确定每个所述目标资源的主键和所述主键对应的目标值。

该步骤中，将目标对象列表中的每个所述目标资源按照预设关键词或字母排序规则进行顺序取出，确定每个所述目标对象的主键和所述主键对应的目标资源值。

这里，排序规则包括但不限制包括预设关键词或字母排序规则。

其中，将所述目标对象列表中的每个所述目标资源按照预设关键词进行顺序取出，包括：确定目标对象列表中的每个所述目标资源的预设关键词，将关键词按照与该目标类型的匹配程度或字母的自然顺序进行排序，确定所述目标对象的主键和所述主键对应的目标资源值。

这样，将所述目标对象列表中的每个所述目标资源按照字母排序规则，包括：

将目标对象列表中的每个所述目标资源直接按照字母的自然顺序进行排序，确定所述目标对象的主键和所述主键对应的目标资源值。

子步骤1022、将所述目标资源的所述主键和所述主键对应的目标值，以键值对的形式存储至线程安全存储库。

该步骤中，确定目标资源的所述主键和所述主键对应的目标值，并将它们以键值对存储至线程安全存储库中。

S103、将存在相互关联关系的所述目标资源的主键存储至事件工作队列表中。

该步骤中，在将目标资源从目标对象列表(Delta Fifo)中按照预设顺序依次弹出后，该目标资源会经由预设事件分发控制器，确定出存在相互关联关系的目标资源的主键，且将目标资源的主键存储至事件工作队列表中，便于后续的备份存储以及备份查找。

这里，具体的确定和筛选方法包括但不限于使用分发事件处理函数，其中，分发事件处理函数用于将所谓事件分发存在相互关联关系的目标资源进行划分，同时使用对应的函数计算将存在相互关联关系的目标资源的主键存储进事件工作队列表。

这里，预设事件分发控制器包括但不限制于：事件源处理器(Resource EventHandlers)。

其中，需要将与事件存在相互关联关系的所述目标资源进行与工作队列表的存储规范相匹配的数据转化，并在转化后存储至工作队列表中。

进一步的，所述S103包括以下子步骤：

子步骤1031、根据各个所述目标资源中应用程序编程接口的身份标识，确定各个所述目标资源之间的相互关联关系。

该步骤中，各个所述目标资源之间的相互关联关系包括但不限于根据用程序编程接口接收到的各个所述目标资源的身份标识。

这里，各个所述目标资源的身份标识包括但不限于各个所述目标资源的ID序号以及各个所述目标资源的IP地址信息等。

子步骤1032、将存在所述相互关联关系的所述目标资源的主键存储至事件工作队列表中。

S104、基于所述事件工作队列表和所述线程安全存储库，完成对所述目标资源的备份。

该步骤中，确定事件工作队列表中每个目标资源在所处事件中的进程项(ProcessItem)，并使用Kubernetes集群中的进程处理控制器来确定目标资源的处理进程，且本申请提供的实施例通过处理器对象(Handle Object)触发快照生成snapshoto，并且该快照生成的同时，完成对目标资源的备份，实现了存储和备份的同步，保证了在处于容灾环境时，对目标资源备份的一致性。

这样，使用Kubernetes集群中的进程处理控制器来确定目标资源的处理进程，需要使用线程安全存储库中的索引，及线程安全存储库中目标资源的主键来确定。

这里，进程项(Process Item)获取目标资源的主键或索引的方式可以为直接在索引库中获取，或在线程安全存储库中查找。

进一步的，所述在所述基于所述事件工作队列表和所述线程安全存储库，完成对所述目标资源的备份之后，所述备份数据的生成方法还包括：

获取所述目标资源的查询请求；其中，所述查询请求中包含目标查询请求的目标身份标识。

这里，在外部出现故障到导致需要进行容灾备份时，且在使用本申请提供的实施例进行容灾备份后，当下的Kubernetes集群想要恢复备份数据时，首先获取对备份的目标资源的查询请求。

根据所述查询请求，确定所述查询请求对应的目标应用程序编程接口。

其中，在获取到该查询请求后，确定与所述查询请求中的查询请求相适配的目标应用程序编程接口。

根据所述目标应用程序编程接口，确定对应的事件工作队列表。

这里，在查讯到了数据通讯对应的目标应用程序编程接口后，通过该目标应用程序编程接口，确定对应的事件工作队列表以及事件工作队列表中目标资源的主键，在确定了目标资源的主键后，即可以通过键值对对应查询到与所述主键相匹配的目标资源。

基于所述事件工作队列表，确定所述事件工作队列表中目标资源的主键。

根据所述主键，确定与所述主键相匹配的目标资源。

进一步的，所述备份数据的生成方法还包括：

在外部发生容灾后，将目标资源的备份经由外部存储服务库发送至Kubernetes主集群，以便所述Kubernetes主集群进行容灾后的恢复处理。

这里，在将Kubernetes集群的原始的或新增的全量数据备份或增量数据备份后，且在确定Kubernetes主集群修复完成后，将备份的数据按照自定义的需求，有选择的部分或却全部发送至Kubernetes主集群，以便所述Kubernetes主集群对核心业务中的目标资源进行容灾后的恢复处理。

本申请实施例提供的备份数据的生成方法，与现有技术中相比，本申请通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

且本申请通过将目标资源添加至目标类型对应的目标对象列表中进行键值对方式的存储，以及将具有相互关联关系的目标资源存储至事件工作队列表中，实现了对目标资源和数据的粒度更小化的实时备份按需备份并且避免了存在非备份时间下的数据丢失问题，全面满足了企业在云原生时代对核心数据的保护需求，且本申请提供的实施例在有新的目标资源添加进来时，能够直接将新增的目标资源以键值对和事件的形式进行备份，能够实现增量的备份，降低了使用成本，且本申请能够保证对目标资源备份的数据同步。

本申请提供的实施例中的备份数据的生成方法，能够解决现有技术中因为故障导致的业务中断，即保障了Kubernetes集群中核心业务的连续性，避免了因外部故障而导致的业务中断的风险，且本申请提供的实施例由于是在监听到有目标类型的目标资源被创建后，立刻将获取目标资源，并添加至目标类型对应的目标对象列表中，实现了对目标资源的实时备份，以便当外部应用环境出现变更或配置调整时，可以及时恢复任一时间点的已备份的资源，保证核心业务的目标资源的完整性。

请参阅图2，图2为本申请实施例所提供的一种备份数据的生成方法中一实施例的流程框图。

首先，反射器Reflector在监听到目标类型的目标资源被创建后，获取目标资源，并将该目标资源以添加对象的方式添加到目标类型对应的目标对象列表中。

然后，通过Informer机制从目标对象列表中获取每个目标资源，并将每个目标资源先按照Informer机制中的Index索引机制，以键值对的形式存储至线程安全存储库中，实现对目标对象列表中全部单个目标资源的备份；同时，将通过Informer机制从目标对象列表中获取每个目标资源经由事件源处理器(Resource Event Handlers)进行实践划分，并将存在相互关联关系的所述目标资源的存储至主键工作队列表中，然后在确定工作队列表中每个目标资源对应的进程项(precess ltem)时，通过处理器对象(Handle Objec)触发快照生成(snapshoto)，并且以所述快照生成的方式完成对目标资源的备份。

其中，快照生成是通过预设的定时任务进行预设时间内的快照生成，且快照生成是用于表征：将工作队列表中的目标资源的主键和，与所述主键对应的线程安全存储库中的目标值同时进行快照拍摄生成的。

本申请实施例提供的备份数据的生成方法中的具体实施例，通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

且本申请提供的实施例是通过将目标资源添加至目标类型对应的目标对象列表中进行键值对方式的存储，以及将具有相互关联关系的目标资源存储至事件工作队列表中，实现了对目标资源和数据的粒度更小化的实时备份按需备份并且避免了存在非备份时间下的数据丢失问题，全面满足了企业在云原生时代对核心数据的保护需求，且本申请提供的实施例在有新的目标资源添加进来时，能够直接将新增的目标资源以键值对和事件的形式进行备份，能够实现增量的备份，降低了使用成本，且本申请能够保证对目标资源备份的数据同步。

本申请提供的实施例中的备份数据的生成方法，能够解决现有技术中因为故障导致的业务中断，即保障了Kubernetes集群中核心业务的连续性，避免了因外部故障而导致的业务中断的风险，且本申请提供的实施例由于是在监听到有目标类型的目标资源被创建后，立刻将获取目标资源，并添加至目标类型对应的目标对象列表中，实现了对目标资源的实时备份，以便当外部应用环境出现变更或配置调整时，可以及时恢复任一时间点的已备份的资源，保证核心业务的目标资源的完整性。

图3为本申请实施例所提供的一种备份数据的容灾系统的结构示意图。如图2中所示，所述备份数据的生成装置300包括：

获取模块，用于当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表。

进一步的，所述获取模块310，具体用于：

当监听到有目标类型的目标资源被创建后，针对于每个所述目标资源，获取所述目标资源对应的获取时间。

针对于每个所述目标资源，将所述目标资源进行格式转换，生成与所述目标对象列表的格式相适配的目标资源。

根据所述获取时间，将转换格式的所述目标资源添加至所述目标类型对应的所述目标对象列表中的对应位置。

第一存储模块320，用于当监听到有目标类型的目标资源被创建后，获取所述目标资源，并将所述目标资源添加至所述目标类型对应的目标对象列表。

进一步的，所述第一存储模块320中的将所述目标对象列表中的每个目标资源按照预设顺序取出，并将每个所述目标资源以键值对的形式存储至线程安全存储库，包括：

将所述目标对象列表中的每个所述目标资源按照排序规则进行顺序取出，确定每个所述目标资源的主键和所述主键对应的目标值。

将所述目标资源的所述主键和所述主键对应的目标值，将目标资源以键值对的形式存储至线程安全存储库。

第二存储模块330，用于将存在相互关联关系的所述目标资源的主键存储至事件工作队列表中。

进一步的，所述第二存储模块330，具体用于：

根据各个所述目标资源中应用程序编程接口的身份标识，确定各个所述目标资源之间的相互关联关系。

将存在所述相互关联关系的所述目标资源的主键存储至事件工作队列表中。

备份模块340，用于基于所述事件工作队列表和所述线程安全存储库，完成对所述目标资源的备份。

查询模块350，用于获取所述目标资源的查询请求；其中，所述查询请求中包含目标查询请求的目标身份标识；根据所述查询请求，确定所述查询请求对应的目标应用程序编程接口；根据所述目标应用程序编程接口，确定对应的事件工作队列表；基于所述事件工作队列表，确定所述事件工作队列表中目标资源的主键；根据所述主键，确定与所述主键相匹配的目标资源。

恢复模块360，用于在外部发生容灾后，将目标资源的备份经由外部存储服务库200发送至Kubernetes主集群100，以便所述Kubernetes主集群100进行容灾后的恢复处理。

本申请实施例提供的备份数据的生成装置300，与现有技术中的相比，本申请提供的实施例通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

且本申请将目标资源添加至目标类型对应的目标对象列表中进行键值对方式的存储，以及将具有相互关联关系的目标资源存储至事件工作队列表中，实现了对目标资源和数据的粒度更小化的实时备份按需备份并且避免了存在非备份时间下的数据丢失问题，全面满足了企业在云原生时代对核心数据的保护需求，且本申请提供的实施例在有新的目标资源添加进来时，能够直接将新增的目标资源以键值对和事件的形式进行备份，能够实现增量的备份，降低了使用成本，且本申请能够保证对目标资源备份的数据同步，且本申请能够保证对目标资源备份的数据同步。

本申请提供的实施例中的备份数据的生成装置300，能够解决现有技术中因为故障导致的业务中断，即保障了Kubernetes集群中核心业务的连续性，避免了因外部故障而导致的业务中断的风险，且本申请提供的实施例由于是在监听到有目标类型的目标资源被创建后，立刻将获取目标资源，并添加至目标类型对应的目标对象列表中，实现了对目标资源的实时备份，以便当外部应用环境出现变更或配置调整时，可以及时恢复任一时间点的已备份的资源，保证核心业务的目标资源的完整性。

图4为本申请实施例所提供的一种备份数据的容灾系统的结构示意图之一。如图4所示，所述备份数据的容灾系统10包括备份数据的生成装置300、Kubernetes主集群100、Kubernetes备集群400以及外部存储服务库200。

所述Kubernetes主集群100，用于根据外部的容灾备份请求，将目标类型的目标资源的备份发送至所述外部存储服务库200。

上述中，Kubernetes主集群100为当前正在使用的数据备份Kubernetes集群。

所述外部存储服务库200，用于将所述Kubernetes主集群100生成的所述目标类型的所述目标资源的备份数据发送至所述Kubernetes备集群400。

其中，外部存储服务库200用于表征包括标准的对象存储协议的库，所述外部存储服务库200可以具体为S3对象存储。

所述Kubernetes备集群400，用于接收所述Kubernetes主集群100备份的所述目标资源，以便进行容灾处理。

上述中，Kubernetes备集群400用于表征在Kubernetes主集群100发送容灾事故或故障后，通过使用S3对象存储，将Kubernetes主集群100中的数据进行备份存储的一个备用集群，且所述Kubernetes备集群400的个数为至少一个。

因此，上述中，本申请实施例提供的备份数据的容灾系统10能够通过一个S3对象存储和不同的Kubernetes备集群400，避免对单一Kubernetes集群的基础捆绑，且不受厂商的捆绑限制，且由于Kubernetes主集群100可以通过S3对象存储与多个Kubernetes备集群400进行接口通信，因此，使用该容灾系统的企业无需部署和维护本地备份基础架构，可以实现轻松完成多云异构环境下数据的自由迁移，实现多地以及按需的对目标类型的目标资源的保护与应用，极大地便利了企业端到端的操作流程，并且为企业不同的容器应用提供了安全和统一的保护。

本申请实施例提供的备份数据的容灾系统10，与现有技术中的相比，本申请提供的实施例通过对目标资源的备份，可以提供应用级数据一致性保障以及可靠的故障处理机制，可以提高业务数据的安全性。

且本申请通过将目标资源添加至目标类型对应的目标对象列表中进行键值对方式的存储，以及将具有相互关联关系的目标资源存储至事件工作队列表中，实现了对目标资源和数据的粒度更小化的实时备份按需备份并且避免了存在非备份时间下的数据丢失问题，全面满足了企业在云原生时代对核心数据的保护需求，且本申请提供的实施例在有新的目标资源添加进来时，能够直接将新增的目标资源以键值对和事件的形式进行备份，能够实现增量的备份，降低了使用成本，且本申请能够保证对目标资源备份的数据同步。

本申请实施例提供的备份数据的容灾系统10，能够解决现有技术中因为故障导致的业务中断，即保障了Kubernetes集群中核心业务的连续性，避免了因外部故障而导致的业务中断的风险，且本申请提供的实施例由于是在监听到有目标类型的目标资源被创建后，立刻将获取目标资源，并添加至目标类型对应的目标对象列表中，实现了对目标资源的实时备份，以便当外部应用环境出现变更或配置调整时，可以及时恢复任一时间点的已备份的资源，保证核心业务的目标资源的完整性。

图5为本申请实施例所提供的一种备份数据的容灾系统的结构示意图之二。如图5所示的备份数据的容灾系统10中Kubernetes主集群100中的数据备份接口(API BackupControllers&CRD)和应用备份接口(PVC Backup DaemonSet)均与S3对象存储，且申请提供的Kubernetes集群的备份数据的容灾系统10中Kubernetes备集群400的数据恢复接口(APIRestore Controllers)和应用恢复接口(PVC Backup DaemonSe)均与S3对象存储。

上述中，API Backup Controllers&CRD和PVC Backup DaemonSet均单独部署于Kubernetes主集群中；API Restore Controllers和PVC Backup DaemonSe均单独部署于Kubernetes备集群中。

且API Backup Controllers&CRD中的CRD可以但不限制于：定义如Backup、Restore、podVolumeBackup、PodVolumeRestore等与备份恢复相关的操作，且本申请提供的实施例能够通过实时监听上述接口的状态变化，来确定对目标资源的全量或增量的备份，进而实现调用Kubernetes备集群的API Backup Controllers&CRD。

API Restore Controllers能够接收Kubernetes主集群中API BackupControllers&CRD的备份目标资源，且在该目标资源经由S3对象存储转换后发送至APIRestore Controllers，且Kubernetes主集群中的数据服务接口(API Server)能够实现对目标资源的创建、更新及删除等操作，且当发送外部容灾或者外部故障时，S3对象存储将目标数据由API Backup Controllers&CRD传送至API Restore Controllers。

PVC Backup DaemonSet能够发送应用级的目标资源，其实时监听上述备份任务，实现文件级别的目标资源的全量或增量的备份。

PVC Backup DaemonSe部署于Kubernetes备集群每个工作节点，且PVC BackupDaemonSe用于写入PVC Backup DaemonSet传送的目标资源的备份文件。

上述中，S3对象存储支持的Kubernetes主集群和Kubernetes备集群均为1.15版本及以上，且S3对象存储支持块存储和共享网络文件存储。

请参阅图6，图6为本申请实施例所提供的一种电子设备的结构示意图。如图6中所示，所述电子设备600包括处理器610、存储器620和总线630。

所述存储器620存储有所述处理器610可执行的机器可读指令，当电子设备600运行时，所述处理器610与所述存储器620之间通过总线630通信，所述机器可读指令被所述处理器610执行时，可以执行如上述图所示方法实施例中备份数据的生成方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图1所示方法实施例中的备份数据的生成方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。