CN116795588A - 一种备份恢复方法、装置、设备以及计算机存储介质 - Google Patents

Abstract

本申请公开了一种备份恢复方法、装置、设备以及计算机存储介质，该方法包括：通过备份模块对数据中心进行监听；在数据中心发生数据集群注册的情况下，生成一组备份容器；通过备份容器对数据集群中的业务数据进行备份处理，得到备份数据；其中，备份容器与数据集群存在关联关系；在业务数据丢失的情况下，根据备份数据恢复数据集群中的业务数据。这样，能够通过备份模块在不影响数据集群的稳定性的前提下，实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

Description

一种备份恢复方法、装置、设备以及计算机存储介质

技术领域

本申请涉及信息技术应用技术领域，尤其涉及一种备份恢复方法、装置、设备以及计算机存储介质。

背景技术

Etcd是一个高度一致的分布式键值存储集群，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。Etcd数据集群本身提供了备份的方法，当应用或者网络发生了异常，能够自适应将应用迁移到其它的节点。这些都是归功于etcd集群自身提供的消息队列、监听、分布式选主等特性。

在相关技术中，etcd集群本身提供了备份的方法，涉及到大量数据的读写，导致备份的过程会影响集群业务，且备份过程复杂效率低，运维成本高。

发明内容

本申请提出一种备份恢复方法、装置、设备以及计算机存储介质，能够实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

为达到上述目的，本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种备份恢复方法，所述方法包括：

通过备份模块对数据中心进行监听；

在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

在一些实施例中，所述备份容器包括连接容器、策略容器和同步容器；

在一些实施例中，所述通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据，包括：

通过所述连接容器将所述数据集群中业务数据发送至所述同步容器；

通过所述策略容器将所述业务数据对应的备份策略发送至所述同步容器；

所述同步容器根据所述业务数据和所述备份策略对所述业务数据进行备份处理，得到所述备份数据。

在一些实施例中，所述备份模块包括监听模块、策略模块和同步模块，所述方法还包括：

通过所述监听模块对所述数据中心的若干个数据集群对应的状态数据进行监听；

在所述状态数据产生变化时，确定策略模块对应的备份策略；

所述同步模块根据所述备份策略进行备份处理，并存储至目标文件。

在一些实施例中，所述状态数据包括期限数据和索引数据，所述在所述状态数据产生变化时，确定策略模块对应的备份策略，包括：

在所述状态数据中期限数据增大的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间；

在所述状态数据中期限数据不变，且索引数据发生变化的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间。

在一些实施例中，所述通过所述策略模块确定所述数据集群的增量数据的备份时间，包括：

根据存储类型中的最大内存和中央处理器的最大值确定第一规格阈值；

根据当前内存和当前中央处理器值确定第二规格阈值；

根据所述第一规格阈值和所述第二规格阈值确定所述备份策略对应的备份时间。

在一些实施例中，所述方法还包括：

在所述数据集群对应的场景是专有集群的情况下，对所述数据集群进行全量备份；

在所述数据集群对应的场景是托管集群的情况下，按照预设策略对所述数据集群进行增量备份。

第二方面，本申请实施例提供了一种备份恢复装置，其特征在于，所述备份恢复装置包括监听单元、生成单元、备份单元和恢复单元，其中，

所述监听单元，配置为通过备份模块对数据中心进行监听；

所述生成单元，配置为在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

所述备份单元，配置为通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

所述恢复单元，配置为在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：存储器和处理器；其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如第一方面所述的方法。

第四方面，本申请实施例提供了一种计算机存储介质，该计算机存储介质存储有备份恢复程序，所述备份恢复程序被至少一个处理器执行时实现如第一方面所述的方法。

本申请所提供的一种备份恢复方法、装置、设备以及计算机存储介质，通过备份模块对数据中心进行监听；在数据中心发生数据集群注册的情况下，生成一组备份容器；通过备份容器对数据集群中的业务数据进行备份处理，得到备份数据；其中，备份容器与数据集群存在关联关系；在业务数据丢失的情况下，根据备份数据恢复数据集群中的业务数据。这样，能够通过备份模块在不影响数据集群的稳定性的前提下，实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

附图说明

图1为本申请实施例提供的一种备份恢复方法的流程示意图；

图2为本申请实施例提供的一种备份恢复方法的详细流程示意图；

图3为本申请实施例提供的一种备份恢复方法的系统框架示意图；

图4为本申请实施例提供的一种备份恢复装置的组成结构示意图；

图5为本申请实施例提供的一种电子设备的组成结构示意图；

图6为本申请实施例提供的另一种电子设备的组成结构示意图。

具体实施方式

为了能够更加详尽地了解本申请实施例的特点与技术内容，下面结合附图对本申请实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本申请实施例。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。还需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅是用于区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

可以理解，区块链是一个分布式的共享账本和数据库，具有去中心化、不可篡改、全程留痕、可以追溯、集体维护、公开透明等特点。这些特点保证了区块链的“诚实”与“透明”，为区块链创造信任奠定基础。区块链是本质上是一个去中心化的数据库，同时作为比特币的底层技术，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次比特币网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链中的数据包含两种：账本数据和状态数据。账本数据包含有序的，不可篡改的状态转换记录即交易记录和区块链的配置记录。状态数据又叫世界状态，维护账本的当前状态。

在相关技术中，

Etcd是一个高度一致的分布式键值存储，它提供了一种可靠的方式来存储需要由分布式系统或机器集群访问的数据。在当前发展比较火热的云原生领域，如Kubernetes编排平台下，使用它作为存储后端，它能够提供可靠的应用保障，当应用或者网络发生了异常，能够自适应将应用迁移到其它的节点。这些都是归功于etcd集群自身提供的消息队列、监听、分布式选主等特性，从而才能提供平台数据的高可用、稳定性。

Etcd集群的高可用，是在集群内部遵循Raft协议，采用选主的方式工作，由主(leader)节点将请求同步发给其它节点，再统计其它节点心跳结果的方式反馈客户端，只有多数节点还在，etcd集群才能正常提供服务。很多的应用平台为了保障数据的高可用性，依赖etcd的分布式特性，上层应用数据的备份方法，依赖于在etcd的分布式下实现；在现有技术方案中，平台的容灾方案，依赖etcd分布式存储的数据，并结合其它的手段切换业务。

除此之外，对于提供容器集群产品的企业来说，etcd的部署方式不再是提前规划好节点，固定采用三节点的模式部署，而是借助etcd-operator类型的管理工具，采用了CRD(CustomResourceDefinition)的模式实现，即采用容器(pod)实例的方式，对于这种场景下的数据存储，很多企业通常依赖的是集群自身的高可用保证，即允许少量的pod异常，一旦出现异常，通常的做法是根据存储的数据重启pod实例。

etcd集群本身提供了备份的方法，但是它的突出的问题是备份的性能，备份的过程会影响集群业务，因为涉及到大量数据的读写。因此，在现有方案中，包括容灾，都是借助分布式存储的备份方案，选择集群业务相对空闲的时期，由脚本或者其它人工的方式，触发数据的备份。Etcd集群的备份时机，当前方案一般当触发了监控告警触发的备份(粒度很粗)或者定时备份的工具，一旦告警发生已经影响了业务，此时执行备份，那么现网业务不能停的情况下，无法做到完整的备份。而想要做到完整的备份，就需要暂停业务。甚至有些场景下，告警出现了异常，导致数据无法备份，备份的数据比较旧，更加不完备。如何来设计细粒度的etcd备份方案，来保障用户关心的业务不丢失，是本方案需要解决的问题。

相关技术中，etcd提供的备份服务，执行一次是全量的拷贝过程，包括所有的内容，性能较低。因为在etcd集群中，通常包含1个leader节点、2个member节点，leader节点需要向集群中member节点发送数据，并且得到响应才能反馈客户端。当数据量比较大的情况下，每次备份数据，都需要从开始到结尾，所有的数据重复备份一次，因此会造成大量的备份开销。比如(1)公有云服务提供商的托管容器集群的场景下，并没有向用户开放etcd集群，通常采用pod实例的方式部署应用，针对这种情况，用户的业务数据备份，需要靠用户自己保障，并且需要具备etcd、kubernetes相关的基础，通过其它特定脚本的方式，才可实现业务备份，备份过程复杂、不可控；并且在面向多用户，多etcd集群的场景下，运营商如何保证用户的数据不丢失，是一个重要的问题；(2)在公有云专有集群或者私有云的场景下，etcd集群部署在用户的三副本的主机上，依靠集群的高可用保证数据的完整性，但是主机通常属于同一个机架，可能因为机房的破坏，从而导致整个集群不可用，影响业务，为了实现数据备份，通常用户需要借助监控告警工具，实现对数据的监控，一旦发现异常，采用脚本或者人工方式备份整个集群数据，有了备份数据，再通过其它的节点，根据备份数据，恢复整个集群的业务，它的前提是有备份数据，备份数据的完整性无法保证，有了备份数据，再通过其它的新节点恢复的方式，恢复整个业务，它的代价是非常大的，耗时久；(3)在政务或者教育上云的行业，对于数据业务稳定性、安全性比较高的场景下，为了保障数据性能，通常需要使用高性能物理机部署业务，从而实现高可靠、高性能的业务，通常需要实时备份etcd数据，而这实时的能力会随着数据的变大，会影响业务的性能，数据备份的灵活策略，成为当前需要解决的问题之一。如何来设计一套多场景下的etcd备份恢复方案，来减少用户自我运维，是本专利需要解决的另一个问题。

基于此，本申请实施例提供了一种备份恢复方法，该方法的基本思想是：通过备份模块对数据中心进行监听；在数据中心发生数据集群注册的情况下，生成一组备份容器；通过备份容器对数据集群中的业务数据进行备份处理，得到备份数据；其中，备份容器与数据集群存在关联关系；在业务数据丢失的情况下，根据备份数据恢复数据集群中的业务数据。这样，能够通过备份模块在不影响数据集群的稳定性的前提下，实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

实施例一

本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种备份恢复方法的流程示意图。如图1所示，该方法可以包括：

S101：通过备份模块对数据中心进行监听。

需要说明的是，在本申请实施例中，本申请实施例提供的备份恢复方法可以应用于具有分布式键值数据库备份恢复需求的电子设备中。这里，电子设备可以是诸如计算机、智能手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Personal DigitalAssistant，PDA)等等。在本申请实施例中对此不作具体限定。

还需要说明的是，在本申请实施例中，数据中心包括多场景下的数据集群，针对不同类型的用户可以是1个或者多个，对于云服务提供商来说，提供的数据集群多达几百个，对于企业或者用户来说，数据集群可能是10个以内，数据集群的类型有部署在云主机上的专有集群、部署在pod实例的托管集群、私有云场景下的集群。

S102：在所述数据中心发生数据集群注册的情况下，生成一组备份容器。

需要说明的是，在本申请实施例中在对数据中心进行监听的过程中，在发现有数据集群注册时，开启一组容器pod(join、policy、sync)，用于接管对集群的备份、恢复业务，此处如果有多个数据集群，需要开启对应数量的容器组，使得备份容器和数据集群的保持一一对应的关系。

在一些实施例中，所述备份容器可以包括连接容器、策略容器和同步容器，示例性的，备份容器可以是pod(join、policy、sync)。

S103：通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系。

需要说明的是，在本申请实施例中，每一个集群数据都在各自对应的备份容器中进行备份处理，在进行备份的过程中，不会干预原本数据集群的共功能，在原本数据集群的节点之外增加了一个备份模块对数据集群进行独立备份。

在一些实施例中，所述通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据，可以包括：

通过所述连接容器将所述数据集群中业务数据发送至所述同步容器；

通过所述策略容器将所述业务数据对应的备份策略发送至所述同步容器；所述同步容器根据所述业务数据和所述备份策略对所述业务数据进行备份处理，得到所述备份数据。

需要说明的是，在本申请实施例中，在一个备份容器中包括连接容器、策略容器和同步容器，其中，连接容器将备份节点加入到对应的数据集群中，作为在leader节点和member节点之外，专门负责备份及恢复的节点，策略容器可以用于决策对业务数据进行备份的备份时间，同步容器是用于根据备份时间执行对业务数据的备份。

在一些实施例中，所述备份模块包括监听模块、策略模块和同步模块，所述方法还可以包括：

通过所述监听模块对所述数据中心的若干个数据集群对应的状态数据进行监听；

在所述状态数据产生变化时，确定策略模块对应的备份策略；

所述同步模块根据所述备份策略进行备份处理，并存储至目标文件。

需要说明的是，在本申请实施例中，在数据集群中的主节点向其他节点发送增量信息的情况下，监听模块监听数据集群的状态数据，状态数据包括Term、raftIndex、logIndex。此外，还需要收集数据集群的Leader节点的cpu数据、内存数据，这些数据需要提前输入到持久化存储模块，并按照(name、ip、cpu、ram)的结构存储。

在一些实施例中，所述状态数据包括期限数据和索引数据，所述在所述状态数据产生变化时，确定策略模块对应的备份策略，可以包括：

在所述状态数据中期限数据增大的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间；

在所述状态数据中期限数据不变，且索引数据发生变化的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间。

需要说明的是，在本申请实施例中，当期限数据发生了变化，说明leader节点发生了变更。需要检测数据集群中主节点的状态，获取最新的数据集群状态数据，如果新的期限数据小于本地持久化的期限数据，则忽略。如果新的期限数据大于本地持久化的期限数据，保存数据到持久化数据库中，触发策略模块执行，在期限数据没有变化，且索引数据(logIndex、raftIndex)发生变化的情况下，如果策略模块已经启动，无需再次加入任务。否则，需要触发策略模块，确定具体地备份时间。

在一些实施例中，所述通过所述策略模块确定所述数据集群的增量数据的备份时间，可以包括：

根据存储类型中的最大内存和中央处理器的最大值确定第一规格阈值；

根据当前内存和当前中央处理器值确定第二规格阈值；

根据所述第一规格阈值和所述第二规格阈值确定所述备份策略对应的备份时间。

需要说明的是，在本申请实施例中，策略模块在确定备份时间的时候，具体地，根据平台该类型的存储最大的类型cpu(max)*mem(max)得出平台最大的规格阈值B；用当前选定的规格，算出cpu*mem，得出当前的规格阈值C；根据B/C*f(p)*quota得出的值为策略模块调度同步模块执行备份的备份时间。

还需要说明的是，在本申请实施例中，f(p)是不同规格下同等大小性能盘的IOPS调节比率，示例性的，如2core4G的IOPS(假设2000)是32core128G的IOPS(假设10000)，那么比率就是1/50，quota需要根据平台IOPS的校准值设定，假设quota设定为1时，不考虑其它因素，执行实时备份。

S104：在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

需要说明的是，在本申请实施例中，在全新的数据集群或者业务数据丢失的情况下，可以采用备份数据对业务数据进行恢复，具体可以将备份数据发送至数据集群的主节点，然后由主节点下发给其他节点。

在一些实施例中，所述方法还可以包括：

在所述数据集群对应的场景是专有集群的情况下，对所述数据集群进行全量备份；

在所述数据集群对应的场景是托管集群的情况下，按照预设策略对所述数据集群进行增量备份。

需要说明的是，在本申请实施例中，在数据集群对应的场景是托管集群的情况下，可以根据预设策略对指定的数据进行选择性备份，具体地，备份的数据可以为全量数据、应用数据、配置数据、节点数据等等，可以按照用户对数据集群中具体地某些数据的需求进行设定，在此不作任何限定。

综上可知，本实施例提供了一种备份恢复方法，通过备份模块对数据中心进行监听；在数据中心发生数据集群注册的情况下，生成一组备份容器；通过备份容器对数据集群中的业务数据进行备份处理，得到备份数据；其中，备份容器与数据集群存在关联关系；在业务数据丢失的情况下，根据备份数据恢复数据集群中的业务数据。这样，能够通过备份模块在不影响数据集群的稳定性的前提下，实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

实施例二

基于前述实施例相同的发明构思，本申请实施例基于当前etcd集群提出了一套适用于多场景etcd集群下的备份恢复方案，etcd集群当前通常是由3节点(1主+2成员节点)组成，另外集群中只有主节点，提供请求的响应。

参见图2，其示出了本申请实施例提供的一种备份恢复方法的详细流程示意图。如图2所示，针对多种场景下的etcd集群，设计一套通用的etcd备份恢复方案。针对云服务提供商或者用户的私有集群等其它场景下，包括但不限于专有集群、托管集群、私有云、混合云等，本发明可以覆盖。图一的架构图中设计了5个要素，分别是多场景下的etcd集群、etcdBackupCluster、etcd-backup、OBJ、etcdRestoreCluster。

(1)多场景下的etcd集群，针对不同类型的用户可以是1个或者多个，对于云服务提供商来说，提供的容器集群多达几百个，对于企业或者用户来说，集群可能是10个以内。类型有部署在云主机上的专有集群、部署在pod实例的托管集群、私有云场景下的集群。

(2)为了提供统一的etcd集群自动化的备份管理能力，设计了etcdBackupCluster资源中心，用户的各种集群注册进来，就可以实现对集群的备份管理；

(3)etcd-backup模块，用于监听etcdBackupCluster中的资源，一旦发现有资源注册，开启一组pod(join、policy、sync)，用于接管对集群的备份、恢复业务，此处如果有多个集群，需要开启对应数量的pod组；

(4)备份业务触发需要将数据导入到OBJ业务中；

(5)设计了etcdRestoreCluster资源中心，根据用户的业务需求构建资源对象，一旦创建，则根据OBJ中的数据，及etcdBackupCluster注册中心的内容，恢复对应的etcd集群数据。那么这套方案是如何解决etcd备份性能问题、针对不同场景设计不同的备份策略来保证数据的完整性、多场景下的etcd集群备份方案。

在本发明方案之前，针对不同的集群，尤其是对于提供服务的运营商，在面对几百个的etcd集群备份的场景下，没有推出统一的etcd备份方案，或者由专人维护集群数据，根据集群特点，编写备份的脚本，实现定期备份。在本发明方案中，etcdBackupCluster作为资源中心对象，它的字段设计为(Id，clusterName，clusterType，namespace，conn，cert)分别表示集群id，集群名称，集群类型(这决定了集群的部署形式，主机或者pod实例)，集群所在的部署域，集群连接信息，集群证书。其它etcd集群，只需和资源中心打通网络策略，并将相关的信息，注册到资源中心，即可实现对多场景下的etcd集群的管理。注册完集群信息之后，被etcd-sync模块监控到，它立马触发kubernetes启动一组pod，包含3个服务，分别用于以etcd-sync角色节点加入etcd集群，在现有技术中etcd集群包括leader、member这样的角色，leader为用户提供服务，并且需要集群中的超过半数提供服务，etcd集群才能稳定运行，因此如果按照现有技术扩容member节点，会造成数据需要确认回复的节点更多，leader节点需要花费更多的同步开销到各member节点，因此随着member节点数量增多，etcd集群的性能反而降低，并影响etcd集群的服务性能。

在本方案中的etcd-sync角色的节点，作为etcd集群的同步节点，它仅仅拥有同步日志数据、集群信息的功能，它不参与集群的选举、投票，即它不影响原先etcd集群的服务性能。

具体做法是在etcd集群中，leader节点能够知晓这样的角色，并且给所有的角色发送集群、日志信息，但是leader节点确认消息发送成功的数量，无需考虑etcd-sync节点，因此etcd-sync能以增量的形式获取到全部etcd集群的数据。现有技术，member节点也能够收取到etcd集群的增量数据。

如果从member节点做数据备份，是不是解决了性能问题？实际上，进行备份的过程，会销毁大量的读写开销，而etcd的member节点作为集群的应答节点，如果执行备份的过程中，leader节点有大量的请求过来，就会导致无法同步应答，将影响leader节点的应答反馈，从而无法及时响应客户，影响了etcd集群的性能。如果选择从leader节点备份数据，那么将会导致集群的leader发生变化，这将严重影响etcd集群的性能。

本发明提出这类角色，能在不影响集群性能的前提下，有效避免这些问题。它既接收到了etcd的集群数据，同时又降低了对集群性能的影响，从而保障了备份的效率。除此之外，针对现有技术中提到的如何指定细粒度的备份策略，针对不同的场景，尤其是pod和云主机备份上的差异性，将在下一节来详细描述。本发明将数据备份到OBJ对象存储之后，设计了etcdRestoreCluster资源对象，一旦资源对象被创建，立马触发1组pod(restore-pod、restore-policy)，根据不同的恢复策略，由pod实例完成etcd集群业务的恢复。

下面，首先来描述一下etcd-sync模块，处理不同场景下的集群的过程，通过它的设计，解决了现有技术中的备份效率低、备份不完备的问题。

参见图3，其示出了本申请实施例提供的一种备份恢复方法的系统框架示意图，如图3所示，在现有的etcd集群基础上，除了leader角色节点、member角色节点之外组成的3个main node之外，新设计了etcd-sync角色节点，它和其他节点的区别是，不参与选举、不作为集群成员的数量统计，即它的存在不影响之前集群的选主规则。但是它具备普通成员数据接收的功能，即当集群接收到用户请求的消息，主节点需要同步到所有其它的节点，包括etcd-sync节点。它能够不断接收到增量数据，从而本发明提出的问题之一：高效实现数据的同步，不用每次在执行备份时全量备份。另外，它还包含了3个主要的模块，watch用于实现实时的数据增量备份能力；policy用于制定备份数据的策略，对于每一套使用etcd的集群来说，架构数据往往超过用户关心的数据，policy需要根据集群的性能指标，制定规则从而实现轻量级的有效数据的备份；sync用于将节点同步的增量数据，实时备份到对象存储。当etcd集群业务出现了问题，为了恢复数据，本发明根据用户关心的业务数据，从对象存储读出这些数据，批量导入到etcd集群，从而实现数据的完整恢复。通过这样的架构，即不影响原先etcd集群的使用性能，又实现了多场景下用户数据备份恢复的业务。

针对现有技术，备份数据不完备的问题，本方案是如何实现的呢？下面详细描述一下watch模块的设计。

这个模块，监听集群的Term、raftIndex、logIndex这几个集群etcd状态的数据。此外，还需要收集集群的Leader节点的cpu、内存数据，这些数据需要提前输入到持久化存储模块，并按照(name、ip、cpu、ram)的结构存储。监听的方式为etcd集群主节点发送增量信息到各节点的时候，提取其中的集群Term、raftIndex、logIndex，一旦检查到Term发生了变化或者logIndex、raftIndex发生变化或者长时间没有变化，执行如下的算法过程：

(1)当Term发生了变化，说明leader节点发生了变更。此时，etcd集群不太稳定，需要检测和etcd主节点的状态，获取最新的集群状态数据，如果获取到的Term，比本地持久化的小，则忽略。其它情况，保存数据到持久化数据库中，触发policy模块执行，policy模块将在下文介绍。policy的功能是执行备份策略。

(2)当logIndex、raftIndex发生变化，如果policy已经启动，无需再次加入任务。否则，需要直接触发policy规则，执行备份策略。

(3)当超过轮询时间戳未发生变更，尝试从leader节点获取集群状态信息，如果获取失败，则重新启动进程加入集群。如果获取成功，获取信息为(TermA，raftIndexA，logIndexA)，则对比TermA和Term。

(a)如果TermA<Term，则忽略；

(b)如果TermA>Term,则触发policy执行备份策略；

(c)如果TermA＝Term，则分别对比logIndexA与logIndex、raftIndexA与raftIndex；如果logIndex未发生变化，则忽略；反之，通过etcd-sync节点向主节点获取(logIndex，logIndexA)之间的日志数据，并触发policy执行备份策略；如果raftIndex未发生变化，则忽略；反之，将(raftIndex，raftIndexA)之间的数据，标记为提交状态(具体的结构在policy模块介绍)。

本方案设计的watch模块，需要与policy、sync模块，协调配合才能解决现有技术所有的问题。那么policy是如何来设计的呢？

policy模块，设计了有效数据的持久化结构为如下所示的结构，用表1来介绍定义及含义：

表1

另外etcd集群节点的信息统计，根据集群的类型，如果是专有集群、私有云类型，则根据etcdBackupCluster证书、连接信息，自动获取如下设计的集群信息，(name，ip，cpu，ram，size，type，quota，k8sTypes)分别表示etcd集群节点的名称、ip地址、cpu大小、内存大小，存储大小，存储类型，容量大小，备份的业务类型；如果是托管集群，由服务提供商，提供这些基本的信息。有了这些基础的设计数表，policy的策略设计为如下过程：

存储类型，代表了业务的规模及性能。存储类型分为优、中、一般，三个级别。

(i)当设定未优时，表明是实时要求高的业务，并且存储性能好，执行备份的频率最高，并且最能够保障数据的不丢失；

(ii)当设定为中时，表明是实时业务要求中等的业务，存储性能较好，执行备份的频度中等，能满足业务特点情况下，执行备份；

(iii)当设定为一般时，表明是测试环境的业务，备份业务需求较低，可丢失数据。当选定了类型之后，再根据cpu、内存大小的乘积，根据如下算法，得出执行sync过程的时间。算法具体过程为：

(1)根据平台该类型的存储最大的类型cpu(max)*mem(max)得出平台最大的规格阈值B；

(2)用当前选定的规格，算出cpu*mem，得出当前的规格阈值C；

(3)用B/C*f(p)*quota，得出的值为policy调度sync执行备份的真正时间。

(4)其中f(p)是不同规格下同等大小性能盘的IOPS调节比率，如2core4G的IOPS(假设2000)是32core128G的IOPS(假设10000)，那么比率就是1/50,则执行备份的时间，用B/C*f(p)*quota公式换算得出为一个值，这个公式设定的含义是大小一定的情况下，性能随着主机规格变大越好，但是需要调整它的基准，由IOPS性能测试结果进行校准。通常quota需要根据平台IOPS的校准值设定，选定的存储类型为优时，quota设定为1时，不考虑其它因素，执行实时备份；当选定为其它存储类型时，quota的校准，根据业务需要设定，比如对于一般的应用系统，存储的频度数据在20条备份一次，那么只需要校准出这个quota即可。

当集群类型场景是专有集群，则根据备份的策略，触发etcd集群的数据备份为all的模式，即全量备份，主要设计原则是本发明中设计了etcdRestoreCluster资源，当它查询到etcdBackupCluster的类型是专有集群，则直接尝试从原有云主机恢复业务的模式；如果恢复不成功，则从etcd的集群中创建同类型的主机节点，恢复业务(现有技术已经满足)；当集群的场景是托管集群，则备份的策略，可由用户配置，触发sync的过程。

有了上述一套计算方式，可以换算出sync的执行过程，但是在此之前，所有到达etcd-sync的数据，都需要根据设定的业务类型，进行持久化。具体过程为：平台将保存的数据划分为all、应用、配置、节点这几类。

当用户设定为all，则etcd-sync模块不需要执行上述设定的持久化过程，从etcd-sync节点，使用etcd自带的全量数据备份的方法，备份数据。其它设定，按照设定的类型，提取有效数据。一旦匹配k8sTypes，则将有效数据，按照表二中设计的格式持久化下来，用于sync的过程。那么sync的过程是如何设计的呢？

通过上述policy模块，已经准备好了有效数据，并且按照格式存储下来，只需要等到policy设定的时间到达，sync备份模块，开始生效。通过调用各厂商的对象存储业务方法，将数据按照对象的方式打包备份上去，备份的名称，采用(clusterName_k8sTypes_time)命名。如果是全量的打包方式，则在业务恢复时，按照etcd默认的恢复方法执行。其它有效数据的情况，按照批量写入etcd集群的方式恢复。这里必须要明确，恢复的数据，是指在全新的etcd集群或者是业务数据丢失的场景下，恢复有效数据。这样将大大提升数据恢复的速度及质量。

通过上述架构的实现方式的描述，引入etcd-sync的节点角色、watch模块及policy策略，针对不同的场景，来提高kubernetes场景下etcd数据不完全的情况；设计policy有效数据结构，来根据策略，高效备份有效数据，从而提升备份的性能，减少对于etcd集群的影响；提出有效数据的增量备份模式，减少无关数据备份影响。

在本申请实施例中设计了多场景下etcd增量备份kubernetes场景下的有效数据方案，提升etcd集群备份的效率、性能、一致性；提出了多场景下统一平台管理的思想，大大降低用户对于多集群数据的备份、恢复管理成本；设计了针对不同场景需求备份的策略，从而提升etcd集群备份的效益，能够应用到现实项目中；首次提出了etcd集群增量备份的方法，将etcd集群业务一致性和备份分开，实现业务稳定性、备份性能，双高效的效果

本实施例提供了一种备份恢复方法，通过上述实施例，对前述实施例的具体实现进行了详细阐述，从中可以看出，通过前述实施例的技术方案，本发明相对于现有技术中的备份方案，实现了etcd多场景下的集群业务稳定、备份实时性同时满足的场景；在现有技术方案中，尤其对于现网业务，无法区分集群的性能，针对不同的性能场景，无法制定备份策略，本发明设计了一套使用的方案，并且不影响原etcd集群的稳定性；本发明提出用户测有效数据的备份能力，能大大降低用户的自我运维难度，提升业务数据备份的效率。

实施例三

基于前述实施例相同的发明构思，参见图4，其示出了本申请实施例提供的一种备份恢复装置40的组成结构示意图。如图4所示，该备份恢复装置40可以包括：监听单元401、生成单元402、备份单元403和恢复单元404，其中，

所述监听单元401，配置为通过备份模块对数据中心进行监听；

所述生成单元402，配置为在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

所述备份单元403，配置为通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

所述恢复单元404，配置为在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。。

在一些实施例中，所述备份容器包括连接容器、策略容器和同步容器；

在一些实施例中，所述备份单元403，具体配置为通过所述连接容器将所述数据集群中业务数据发送至所述同步容器；以及通过所述策略容器将所述业务数据对应的备份策略发送至所述同步容器；以及所述同步容器根据所述业务数据和所述备份策略对所述业务数据进行备份处理，得到所述备份数据。

在一些实施例中，所述备份单元403，还配置为通过所述监听模块对所述数据中心的若干个数据集群对应的状态数据进行监听；以及在所述状态数据产生变化时，确定策略模块对应的备份策略；以及所述同步模块根据所述备份策略进行备份处理，并存储至目标文件。

在一些实施例中，所述备份单元403，具体配置为在所述状态数据中期限数据增大的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间；以及在所述状态数据中期限数据不变，且索引数据发生变化的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间。

在一些实施例中，所述备份单元403，具体配置为根据存储类型中的最大内存和中央处理器的最大值确定第一规格阈值；以及根据当前内存和当前中央处理器值确定第二规格阈值；以及根据所述第一规格阈值和所述第二规格阈值确定所述备份策略对应的备份时间。

在一些实施例中，所述备份单元403，还配置为在所述数据集群对应的场景是专有集群的情况下，对所述数据集群进行全量备份；以及在所述数据集群对应的场景是托管集群的情况下，按照预设策略对所述数据集群进行增量备份。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

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

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有备份恢复程序，所述备份恢复程序被至少一个处理器执行时实现前述实施例中任一项所述的方法的步骤。

基于上述备份恢复装置40的组成以及计算机存储介质，参见图5，其示出了本申请实施例提供的电子设备的具体硬件结构示意图。如图5所示，电子设备50可以包括：通信接口501、存储器502和处理器503；各个组件通过总线系统504耦合在一起。可理解，总线系统504用于实现这些组件之间的连接通信。总线系统504除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5中将各种总线都标为总线系统504。其中，通信接口501，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器502，用于存储能够在处理器503上运行的计算机程序；

处理器503，用于在运行所述计算机程序时，执行：

通过备份模块对数据中心进行监听；

在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

可以理解，本申请实施例中的存储器502可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本文描述的系统和方法的存储器502旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器503可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器503中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器503可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器502，处理器503读取存储器502中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器503还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

基于上述备份恢复装置40的组成以及计算机存储介质，参见图6，其示出了本申请实施例提供的另一种电子设备50的组成结构示意图。如图6所示，该电子设备50可以包括前述实施例中任一项所述的备份恢复装置40。

在本申请实施例中，对于电子设备50而言，通过备份模块对数据中心进行监听；在数据中心发生数据集群注册的情况下，生成一组备份容器；通过备份容器对数据集群中的业务数据进行备份处理，得到备份数据；其中，备份容器与数据集群存在关联关系；在业务数据丢失的情况下，根据备份数据恢复数据集群中的业务数据。这样，能够通过备份模块在不影响数据集群的稳定性的前提下，实现不同场景下多个集群数据备份和恢复的功能，提升业务数据备份的效率，降低运维难度。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种备份恢复方法，其特征在于，所述方法包括：

通过备份模块对数据中心进行监听；

在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

2.根据权利要求1所述的方法，其特征在于，所述备份容器包括连接容器、策略容器和同步容器。

3.根据权利要求2所述的方法，其特征在于，所述通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据，包括：

通过所述连接容器将所述数据集群中业务数据发送至所述同步容器；

通过所述策略容器将所述业务数据对应的备份策略发送至所述同步容器；

所述同步容器根据所述业务数据和所述备份策略对所述业务数据进行备份处理，得到所述备份数据。

4.根据权利要求1所述的方法，其特征在于，所述备份模块包括监听模块、策略模块和同步模块，所述方法还包括：

通过所述监听模块对所述数据中心的若干个数据集群对应的状态数据进行监听；

在所述状态数据产生变化时，确定策略模块对应的备份策略；

所述同步模块根据所述备份策略进行备份处理，并存储至目标文件。

5.根据权利要求4所述的方法，其特征在于，所述状态数据包括期限数据和索引数据，所述在所述状态数据产生变化时，确定策略模块对应的备份策略，包括：

在所述状态数据中期限数据增大的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间；

在所述状态数据中期限数据不变，且索引数据发生变化的情况下，通过所述策略模块确定所述数据集群的增量数据的备份时间。

6.根据权利要求1所述的方法，其特征在于，所述通过所述策略模块确定所述数据集群的增量数据的备份时间，包括：

根据存储类型中的最大内存和中央处理器的最大值确定第一规格阈值；

根据当前内存和当前中央处理器值确定第二规格阈值；

根据所述第一规格阈值和所述第二规格阈值确定所述备份策略对应的备份时间。

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

在所述数据集群对应的场景是专有集群的情况下，对所述数据集群进行全量备份；

在所述数据集群对应的场景是托管集群的情况下，按照预设策略对所述数据集群进行增量备份。

8.一种备份恢复装置，其特征在于，所述备份恢复装置包括监听单元、生成单元、备份单元和恢复单元，其中，

所述监听单元，配置为通过备份模块对数据中心进行监听；

所述生成单元，配置为在所述数据中心发生数据集群注册的情况下，生成一组备份容器；

所述备份单元，配置为通过所述备份容器对所述数据集群中的业务数据进行备份处理，得到备份数据；其中，所述备份容器与所述数据集群存在关联关系；

所述恢复单元，配置为在所述业务数据丢失的情况下，根据所述备份数据恢复所述数据集群中的所述业务数据。

9.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器；其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至7任一项所述的方法。

10.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至7任一项所述的方法。