数据备份方法、装置、计算机设备和存储介质与流程

1.本技术涉及人工智能技术领域，特别是涉及一种数据备份方法、装置、计算机设备和存储介质。


背景技术：

2.随着计算机技术的发展，每个公司都存在大量的用户数据、用户行为数据以及日志数据等数据，为了保证该些数据的安全，一般的公司会建设数据库备份系统，实现对数据的备份。
3.传统技术中，通常采用单台引擎运行数据库备份系统的架构方式来实现数据备份。
4.然而，当要备份的数据库数量较多时或者某个数据库数据量较大时，数据库备份系统的稳定性和可用性就会受到挑战，对内表现为服务器资源会被占满，cpu、内存等性能指标接近100％。对外表现为卡住、响应慢，甚至出现宕机无法对外服务等现象。


技术实现要素：

5.基于此，有必要针对上述技术问题，提供一种能够保证服务正常进行的数据备份方法、装置、计算机设备和存储介质。
6.第一方面，本技术提供了一种数据备份方法，所述方法包括：
7.获取各个备份引擎的负载情况；
8.当存在所述备份引擎的负载情况不满足要求时，获取新的备份引擎；
9.通过新的所述备份引擎对所述负载情况不满足要求的备份引擎进行负载分担。
10.在其中一个实施例中，所述通过新的所述备份引擎对所述负载情况不满足要求的备份引擎进行负载分担，包括：
11.获取所述备份引擎对应的备份数据的数据编号范围；
12.查询所述数据编号范围所对应的备份引擎的数量；
13.根据所述数据编号范围以及所述备份引擎的数量，确定所述备份数据对应的备份引擎；
14.通过所述备份引擎对对应的备份数据进行备份。
15.在其中一个实施例中，所述根据所述数据编号范围以及所述备份引擎的数量，确定所述备份数据对应的备份引擎，包括：
16.计算所述数据编号范围对所述备份引擎的数量的余数；
17.根据所述余数确定所述备份数据对应的备份引擎。
18.在其中一个实施例中，所述获取各个备份引擎的负载情况，包括：
19.获取引擎表，并获取所述引擎表中的各个备份引擎的负载情况；
20.所述获取新的备份引擎，包括：
21.从引擎池中获取新的备份引擎，并将所述新的备份引擎增加至所述引擎表中。
22.在其中一个实施例中，所述获取各个备份引擎的负载情况，包括：
23.周期性地获取各个备份引擎的负载情况。
24.在其中一个实施例中，所述通过新的所述备份引擎对所述负载情况不满足要求的备份引擎进行负载分担之后，还包括：
25.输出预警信息。
26.第二方面，本技术提供了一种数据备份装置，所述装置包括：
27.负载情况获取模块，用于获取各个备份引擎的负载情况；
28.备份引擎获取模块，用于当存在所述备份引擎的负载情况不满足要求时，获取新的备份引擎；
29.负载分担模块，用于通过新的所述备份引擎对所述负载情况不满足要求的备份引擎进行负载分担。
30.在其中一个实施例中，所述负载分担模块包括：
31.数据编号范围获取单元，用于获取所述备份引擎对应的备份数据的数据编号范围；
32.引擎数据获取单元，用于查询所述数据编号范围所对应的备份引擎的数量；
33.备份引擎确定单元，用于根据所述数据编号范围以及所述备份引擎的数量，确定所述备份数据对应的备份引擎；
34.备份单元，用于通过所述备份引擎对对应的备份数据进行备份。
35.第三方面，本技术提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述任意一个实施例中的方法的步骤。
36.第四方面，本技术提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一个实施例中的方法的步骤。
37.第五方面，本技术提供了一种计算机程序产品，所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述任意一个实施例中的方法的步骤。
38.上述数据备份方法、装置、计算机设备和存储介质，根据各个备份引擎的负载情况，以判断是否需要横向扩展，若是，则获取新的备份引擎以进行负载分担，这样在单台服务器遭遇到性能瓶颈时，弹性扩展引擎，分摊负载压力，确保数据库备份系统稳定性与高可用性。
附图说明
39.图1为一个实施例中数据备份方法的流程示意图；
40.图2为另一个实施例中数据备份方法的流程示意图；
41.图3为一个实施例中各备份任务的执行结果示意图；
42.图4为另一个实施例中报警界面的示意图；
43.图5为一个实施例中数据备份装置的结构框图；
44.图6为一个实施例中计算机设备的内部结构图。
具体实施方式
45.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
46.在一个实施例中，如图1所示，提供了一种数据备份方法，本实施例以该方法应用于服务器进行举例说明，可以理解的是，该方法也可以应用于终端，还可以应用于包括终端和服务器的系统，并通过终端和服务器的交互实现。本实施例中，该方法包括以下步骤：
47.s102：获取各个备份引擎的负载情况。
48.具体地，备份引擎是用于将数据备份的引擎，例如将数据读取，并存储至备份存储系统中。例如服务器中增量获取到待备份的数据的索引，然后备份引擎读取索引以读取待备份的数据，并将待备份的数据存储至备份数据库中。其中可选地，备份引擎可以是通过定时工具等触发主程序以实现数据备份。其中需要说明的一点是备份引擎可以是通过集群的方式存在的，即在一个集群中存在多个备份引擎，多个备份引擎共同工作以实现数据的备份。其中备份引擎及时将服务器所获取的待备份的数据存储至对应的备份数据库的执行机。需要说明的是在本实施例中，并不对备份引擎的物理型号等进行限制。优选地，各个备份引擎的性能相同，以方便管理。
49.其中待备份的数据是从主数据库中获取的，待备份的数据可以是增量数据，在开始时，待备份的数据是整个主数据库中存储的数据，后续对主数据库中的数据进行存储时，待备份的数据则可以是增量数据。其中可选地，待备份的数据可以是周期性获取的，例如在预设时间间隔内获取的新增的数据以及前序各个预设时间间隔内备份失败的数据。因此服务器获取的待备份的数据可以是携带有数据的备份状态的，服务器根据数据的备份状态确定该数据是否备份成功，若是备份成功，则修改数据的备份状态为备份成功，否则数据的备份状态仍为未备份状态，这样服务器周期性获取待备份的数据时，可以先获取到本预设时间间隔内需要备份的数据，以及历史的预设时间间隔内未备份成功的数据，可选地，在历史的预设时间间隔内的数据均备份成功时，则可以标注该历史的预设时间间隔内的数据备份成功。在其他的实施例中，服务器获取到待备份的数据时，还可以获取到待备份的数据的备份次数，例如备份次数大于预设值，则输出该待备份的数据，而不再进行自动备份，以便于人工进行手动备份。在其他的实施例中，服务器可以根据预设的时间间隔的数量来确定备份次数，例如前5个预设时间间隔，则一定备份了5次了，因此服务器在获取待备份的数据时，在获取当前预设时间间隔内的待备份数据后，仅根据预设的备份次数向前再获取到预设数量的预设时间间隔中的待备份数据作为最终的待备份数据，而服务器还可以在其他的线程中根据预设的备份次数向前获取到其他的预设时间间隔中的待备份数据，并输出，以提示用户该些数据备份失败，从而用户可以进行手动备份等等。
50.负载情况是指备份引擎的负载情况，其包括但不限于备份引擎的cpu、内存等性能指标。在其中一个可选的实施例中，可以选择其中一个性能指标作为负载情况，或者是选择多个性能指标作为负载情况。在选择多个性能指标作为负载情况时，可以选择当前性能指标最差的一个指标作为备份引擎的负载情况，或者是根据预先设置的规则等综合多个性能指标得到负载情况，例如预先给各个性能指标配置权重，最后通过加权的方式计算得到负载情况。其中权重的配置可以是用户预先配置的，例如根据业务经验来确定性能指标的影
响，根据影响来衡量各个性能指标的权重。在其他的实施例中，服务器还可以通过模型训练等方式来实现权重的配置，例如通过人工智能模型等方式，更具体地，通过神经网络等等，在此不对具体的模型进行限定。
51.在其中一个实施例中，获取各个备份引擎的负载情况，包括：周期性地获取各个备份引擎的负载情况。例如，主机a每隔10分钟调起一次采集脚本，采集数据库引擎表中所列引擎的cpu、内存等性能指标，并计算出表征引擎运行情况的负载情况。其中采集脚本即是获取备份引擎的负载情况的脚本，该脚本有两个职责，一方面负责监测各引擎的负载情况，另一方面负责扩展引擎的实施。
52.在其中一个实施例中，备份引擎是存在多个的，这里的获取负载情况的备份引擎是指正在执行备份操作的引擎的负载情况，例如服务器中可以设置有引擎表或者是其他形式的引擎存储，只有执行备份任务的备份引擎才会被存储至该引擎表中，其他备份引擎则存储在其他位置。或者是所有的备份引擎都存储至该引擎表中，但是该表中设置有引擎状态标识，用于标识备份引擎是否正在执行数据备份任务。
53.s104：当存在备份引擎的负载情况不满足要求时，获取新的备份引擎。
54.具体地，负载情况不满足要求是指备份引擎的负载较大，即备份引擎此时的任务量较大，很容易导致宕机等。新的备份引擎是指未执行备份任务的备份引擎或者是指执行备份任务但是负载情况满足要求的备份引擎。
55.s106：通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担。
56.具体地，负载分担可以采用负载均衡的思路，即通过至少两个备份引擎来完成对应的数据备份。
57.其中需要说明的是，对于同一批数据在第一个备份引擎的负载情况不满足要求时，可以扩展一个新的备份引擎，共同实现该批数据的备份，但是当两个备份引擎在备份的时候，仍存在至少一个备份引擎的负载情况不满足要求时，则可以对负载情况不满足要求的备份引擎继续进行引擎扩展，直至所有的执行备份任务的备份引擎的负载情况满足要求。
58.其中需要说明的是，若一个负载不满足要求的备份引擎仅执行一批数据的备份任务，则直接通过新的备份引擎分担该一个备份任务即可。若是一个负载不满足要求的备份引擎执行至少一批数据的备份任务，例如同时执行两个备份任务，则可以选择备份任务中任务量最大的一个进行负载分担。
59.在实际应用中，当某个引擎的负载情况大于90时(满分100)，表示当前负荷量过高，此时采集脚本会从引擎ip预备池中选择一个ip作为引擎2，并复制引擎1的主程序至引擎2，启动引擎2上的主程序，从而分摊当前数据库备份系统的负载压力。
60.上述数据备份方法，根据各个备份引擎的负载情况，以判断是否需要横向扩展，若是，则获取新的备份引擎以进行负载分担，这样在单台服务器遭遇到性能瓶颈时，弹性扩展引擎，分摊负载压力，确保数据库备份系统稳定性与高可用性。
61.在其中一个实施例中，通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担，包括：获取备份引擎对应的备份数据的数据编号范围；查询数据编号范围所对应的备份引擎的数量；根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎；通过备份引擎对对应的备份数据进行备份。
62.具体地，备份数据的数据编号范围可以是预先生成的，例如一个时间周期内所产生的增量数据其是按照一定规则增量编号的，该些编号的范围即为备份数据的数据编号范围，在一个优选的实施例中，该数据编号范围可以看做是索引值范围。在其中一个实施例中，该索引值范围可以是预先存储在一张表中的，例如此处称为策略表，该策略表中存储需要备份的数据的索引值范围。
63.在其中一个实施例中，备份数据是批量出现的，每一批备份数据中至少包括一个数据，也就是说每一批备份数据包括多个索引值，这里成为数据编号范围，不同的数量编号范围的备份数据对应一个备份任务，备份引擎用于获取该些备份任务并执行。因此服务器查询数据编号范围所对应的备份引擎的数量即可以确定执行该备份任务的备份引擎的数量。
64.这样服务器根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎。
65.在一个优选的实施例中，根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎，包括：计算数据编号范围对备份引擎的数量的余数；根据余数确定备份数据对应的备份引擎。也就是说通过数据编号范围中每一个编号以及备份引擎的数量进行取余即可以确定对应的备份引擎。
66.数据库备份系统扩展区中各引擎运行着相同的数据库备份系统主程序，该主程序会根据引擎选择机制来决定某条备份数据所执行的备份引擎，非本备份引擎所执行的策略会被跳过。该引擎选择机制具体为：先从数据库策略表和引擎表读取出每条策略的编号(该编号唯一且自增)和当前使用的引擎总数，再用策略的编号对引擎总数取余，则为该策略对应的备份引擎的编号，其中备份引擎的编号可以根据备份引擎先后执行该备份任务的顺序来进行编号，并存储至备份引擎表中，其中不同的备份任务所对应的备份引擎的编号可以相同。
67.上述实施例中，在同一备份任务存在多个备份引擎时，通过引擎选择机制来实现备份数据对应的备份引擎的选择，避免备份任务被多个备份引擎执行。
68.在其中一个实施例中，获取各个备份引擎的负载情况，包括：获取引擎表，并获取引擎表中的各个备份引擎的负载情况；获取新的备份引擎，包括：从引擎池中获取新的备份引擎，并将新的备份引擎增加至引擎表中。
69.具体地，本实施例中的引擎表中存储的是正在执行备份任务的备份引擎，而在引擎池中存储的则是未执行备份任务的备份引擎，这样在计算负载情况的时候，服务器直接获取到引擎表中的各个备份引擎的负载情况即可。参见下表，数据库涉及两张表，引擎表和策略表，新增的引擎表用于记录备份系统中所使用的引擎，数据结构如表1所示。
70.引擎编号引擎ip1109.6.45.2112109.6.13.168......
71.而在获取新的备份引擎的时候，则直接从引擎池中选取即可，简化了计算机的操作。
72.在其中一个实施例中，通过新的备份引擎对负载情况不满足要求的备份引擎进行
负载分担之后，还包括：输出预警信息。
73.具体地，在判断负载情况不满足要求是，服务器也会同时将此备份引擎，例如备份引擎的ip地址记录到数据库引擎表，并以短信或邮件等方式报警通知系统管理员，发送提示预警信息。
74.在其中一个实施例中，参见图2所示，图2为另一个实施例中，数据备份方法的流程图，在该实施例中，其中该数据备份方法所处的系统包括数据库、性能检测模块和数据库备份系统扩展区。其中，数据库中存储有两张表，引擎表和策略表，其中引擎表是用于存储正在执行备份任务的备份引擎，策略表则用于存储待备份的备份数据，其中每一条备份数据均存在有编号，且一批备份数据对应一个备份任务。性能检测模块核心为部署在服务器主机a上的性能采集脚本，该脚本有两个职责，一方面负责监测各引擎的负载情况，另一方面负责扩展引擎的实施。主机a会每隔10分钟调起一次该采集脚本，采集数据库引擎表中所列引擎的cpu、内存等性能指标，并计算出表征引擎运行情况的总负荷。当某个引擎的负载情况大于90时(满分100)，表示当前负荷量过高，此时采集脚本会从引擎ip预备池中选择一个ip作为引擎2，并复制引擎1的主程序至引擎2，启动引擎2上的主程序，从而分摊当前数据库备份系统的负载压力。
75.数据库备份系统扩展区中各引擎运行着相同的数据库备份系统主程序，该主程序会根据引擎选择机制来决定某条备份策略所执行的引擎，非本引擎所执行的策略会被跳过。该引擎选择机制具体为：先从数据库策略表和引擎表读取出每条策略的编号(该编号唯一且自增)和当前使用的引擎总数，再用策略的编号对引擎总数取余，则为该策略对应的引擎。
76.在实际应用中，以某机构的oracle数据库备份系统，根据用户在前台展示系统中录入的备份策略，每天晚上18点开始对其下辖13个地区的上百台云数据库进行备份。系统初始上线是只有单台服务器引擎供备份使用，随着个录入的应用数据库增多，单台引擎出现慢、卡等现象，所以急需横向扩展一台引擎。
77.具体地，首先在数据库中存储有一个引擎表，记录着引擎1的编号与ip地址。一个支持横向扩展的oracle数据库备份系统，运行在引擎1上。一个性能采集脚本，部署在服务器主机a上，使用crontab每十分钟执行一次。
78.其中保证在单引擎下的数据库备份系统正常运行。oracle数据库备份系统运行在引擎1上，性能采集脚本，部署在服务器主机a上，在用户界面新增多条体量较大的数据库备份策略(这些策略会入库到数据库策略表)，直到触发引擎1的性能阈值。具体可以参见图3所示。
79.当主机a上的性能采集脚本检测到总负荷大于90时，系统管理员会受到邮件报警，查看cpu指标数据居高不下，具体可以参见图4所示。
80.服务器自动扩展引擎2后，检查数据库引擎表发现已新增一条引擎2信息，且引擎2上数据库备份系统正常分摊系统备份任务，产生备份文件。且引擎1上的cup、内存等指标已下降，有所缓解，顺利横向扩展引擎。
81.上述实施例中，可自动横向扩展数据库备份系统的引擎，解决了因单服务器引擎性能瓶颈问题导致数据库备份系统响应慢、宕机等问题，保证了系统的稳定性与高可用性。
82.应该理解的是，虽然图1和图2的流程图中的各个步骤按照箭头的指示依次显示，
但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1和图2中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
83.在一个实施例中，如图5所示，提供了一种数据备份装置，包括：负载情况获取模块501、备份引擎获取模块502和负载分担模块503，其中：
84.负载情况获取模块501，用于获取各个备份引擎的负载情况。
85.具体地，备份引擎是用于将数据备份的引擎，例如将数据读取，并存储至备份存储系统中。例如服务器中增量获取到待备份的数据的索引，然后备份引擎读取索引以读取待备份的数据，并将待备份的数据存储至备份数据库中。其中可选地，备份引擎可以是通过定时工具等触发主程序以实现数据备份。其中需要说明的一点是备份引擎可以是通过集群的方式存在的，即在一个集群中存在多个备份引擎，多个备份引擎共同工作以实现数据的备份。其中备份引擎及时将服务器所获取的待备份的数据存储至对应的备份数据库的执行机。需要说明的是在本实施例中，并不对备份引擎的物理型号等进行限制。优选地，各个备份引擎的性能相同，以方便管理。
86.其中待备份的数据是从主数据库中获取的，待备份的数据可以是增量数据，在开始时，待备份的数据是整个主数据库中存储的数据，后续对主数据库中的数据进行存储时，待备份的数据则可以是增量数据。其中可选地，待备份的数据可以是周期性获取的，例如在预设时间间隔内获取的新增的数据以及前序各个预设时间间隔内备份失败的数据。因此服务器获取的待备份的数据可以是携带有数据的备份状态的，服务器根据数据的备份状态确定该数据是否备份成功，若是备份成功，则修改数据的备份状态为备份成功，否则数据的备份状态仍为未备份状态，这样服务器周期性获取待备份的数据时，可以先获取到本预设时间间隔内需要备份的数据，以及历史的预设时间间隔内未备份成功的数据，可选地，在历史的预设时间间隔内的数据均备份成功时，则可以标注该历史的预设时间间隔内的数据备份成功。在其他的实施例中，服务器获取到待备份的数据时，还可以获取到待备份的数据的备份次数，例如备份次数大于预设值，则输出该待备份的数据，而不再进行自动备份，以便于人工进行手动备份。在其他的实施例中，服务器可以根据预设的时间间隔的数量来确定备份次数，例如前5个预设时间间隔，则一定备份了5次了，因此服务器在获取待备份的数据时，在获取当前预设时间间隔内的待备份数据后，仅根据预设的备份次数向前再获取到预设数量的预设时间间隔中的待备份数据作为最终的待备份数据，而服务器还可以在其他的线程中根据预设的备份次数向前获取到其他的预设时间间隔中的待备份数据，并输出，以提示用户该些数据备份失败，从而用户可以进行手动备份等等。
87.负载情况是指备份引擎的负载情况，其包括但不限于备份引擎的cpu、内存等性能指标。在其中一个可选的实施例中，可以选择其中一个性能指标作为负载情况，或者是选择多个性能指标作为负载情况。在选择多个性能指标作为负载情况时，可以选择当前性能指标最差的一个指标作为备份引擎的负载情况，或者是根据预先设置的规则等综合多个性能指标得到负载情况，例如预先给各个性能指标配置权重，最后通过加权的方式计算得到负
载情况。其中权重的配置可以是用户预先配置的，例如根据业务经验来确定性能指标的影响，根据影响来衡量各个性能指标的权重。在其他的实施例中，服务器还可以通过模型训练等方式来实现权重的配置，例如通过人工智能模型等方式，更具体地，通过神经网络等等，在此不对具体的模型进行限定。
88.在其中一个实施例中，获取各个备份引擎的负载情况，包括：周期性地获取各个备份引擎的负载情况。例如，主机a每隔10分钟调起一次采集脚本，采集数据库引擎表中所列引擎的cpu、内存等性能指标，并计算出表征引擎运行情况的负载情况。其中采集脚本即是获取备份引擎的负载情况的脚本，该脚本有两个职责，一方面负责监测各引擎的负载情况，另一方面负责扩展引擎的实施。
89.在其中一个实施例中，备份引擎是存在多个的，这里的获取负载情况的备份引擎是指正在执行备份操作的引擎的负载情况，例如服务器中可以设置有引擎表或者是其他形式的引擎存储，只有执行备份任务的备份引擎才会被存储至该引擎表中，其他备份引擎则存储在其他位置。或者是所有的备份引擎都存储至该引擎表中，但是该表中设置有引擎状态标识，用于标识备份引擎是否正在执行数据备份任务。
90.备份引擎获取模块502，用于当存在备份引擎的负载情况不满足要求时，获取新的备份引擎。
91.具体地，负载情况不满足要求是指备份引擎的负载较大，即备份引擎此时的任务量较大，很容易导致宕机等。新的备份引擎是指未执行备份任务的备份引擎或者是指执行备份任务但是负载情况满足要求的备份引擎。
92.负载分担模块503，用于通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担。
93.具体地，负载分担可以采用负载均衡的思路，即通过至少两个备份引擎来完成对应的数据备份。
94.其中需要说明的是，对于同一批数据在第一个备份引擎的负载情况不满足要求时，可以扩展一个新的备份引擎，共同实现该批数据的备份，但是当两个备份引擎在备份的时候，仍存在至少一个备份引擎的负载情况不满足要求时，则可以对负载情况不满足要求的备份引擎继续进行引擎扩展，直至所有的执行备份任务的备份引擎的负载情况满足要求。
95.其中需要说明的是，若一个负载不满足要求的备份引擎仅执行一批数据的备份任务，则直接通过新的备份引擎分担该一个备份任务即可。若是一个负载不满足要求的备份引擎执行至少一批数据的备份任务，例如同时执行两个备份任务，则可以选择备份任务中任务量最大的一个进行负载分担。
96.在实际应用中，当某个引擎的负载情况大于90时(满分100)，表示当前负荷量过高，此时采集脚本会从引擎ip预备池中选择一个ip作为引擎2，并复制引擎1的主程序至引擎2，启动引擎2上的主程序，从而分摊当前数据库备份系统的负载压力。
97.上述数据备份装置，根据各个备份引擎的负载情况，以判断是否需要横向扩展，若是，则获取新的备份引擎以进行负载分担，这样在单台服务器遭遇到性能瓶颈时，弹性扩展引擎，分摊负载压力，确保数据库备份系统稳定性与高可用性。
98.在其中一个实施例中，负载分担模块503可以包括：
99.数据编号范围获取单元，用于获取备份引擎对应的备份数据的数据编号范围；
100.引擎数据获取单元，用于查询数据编号范围所对应的备份引擎的数量；
101.备份引擎确定单元，用于根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎；
102.备份单元，用于通过备份引擎对对应的备份数据进行备份。
103.具体地，备份数据的数据编号范围可以是预先生成的，例如一个时间周期内所产生的增量数据其是按照一定规则增量编号的，该些编号的范围即为备份数据的数据编号范围，在一个优选的实施例中，该数据编号范围可以看做是索引值范围。在其中一个实施例中，该索引值范围可以是预先存储在一张表中的，例如此处称为策略表，该策略表中存储需要备份的数据的索引值范围。
104.在其中一个实施例中，备份数据是批量出现的，每一批备份数据中至少包括一个数据，也就是说每一批备份数据包括多个索引值，这里成为数据编号范围，不同的数量编号范围的备份数据对应一个备份任务，备份引擎用于获取该些备份任务并执行。因此服务器查询数据编号范围所对应的备份引擎的数量即可以确定执行该备份任务的备份引擎的数量。
105.这样服务器根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎。
106.在其中一个实施例中，备份引擎确定单元包括：
107.计算子单元，用于计算数据编号范围对备份引擎的数量的余数；
108.备份引擎确定子单元，用于根据余数确定备份数据对应的备份引擎。
109.数据库备份系统扩展区中各引擎运行着相同的数据库备份系统主程序，该主程序会根据引擎选择机制来决定某条备份数据所执行的备份引擎，非本备份引擎所执行的策略会被跳过。该引擎选择机制具体为：先从数据库策略表和引擎表读取出每条策略的编号(该编号唯一且自增)和当前使用的引擎总数，再用策略的编号对引擎总数取余，则为该策略对应的备份引擎的编号，其中备份引擎的编号可以根据备份引擎先后执行该备份任务的顺序来进行编号，并存储至备份引擎表中，其中不同的备份任务所对应的备份引擎的编号可以相同。
110.上述实施例中，在同一备份任务存在多个备份引擎时，通过引擎选择机制来实现备份数据对应的备份引擎的选择，避免备份任务被多个备份引擎执行。
111.在其中一个实施例中，上述负载情况获取模块501用于获取引擎表，并获取引擎表中的各个备份引擎的负载情况。
112.上述备份引擎获取模块502用于从引擎池中获取新的备份引擎，并将新的备份引擎增加至引擎表中。
113.具体地，本实施例中的引擎表中存储的是正在执行备份任务的备份引擎，而在引擎池中存储的则是未执行备份任务的备份引擎，这样在计算负载情况的时候，服务器直接获取到引擎表中的各个备份引擎的负载情况即可。参见下表，数据库涉及两张表，引擎表和策略表，新增的引擎表用于记录备份系统中所使用的引擎，数据结构如表1所示。
114.引擎编号引擎ip1109.6.45.211
2109.6.13.168......
115.而在获取新的备份引擎的时候，则直接从引擎池中选取即可，简化了计算机的操作。
116.在其中一个实施例中，上述负载情况获取模块501用于周期性地获取各个备份引擎的负载情况。
117.在其中一个实施例中，上述装置还包括：
118.输出模块，用于输出预警信息。
119.具体地，在判断负载情况不满足要求是，服务器也会同时将此备份引擎，例如备份引擎的ip地址记录到数据库引擎表，并以短信或邮件等方式报警通知系统管理员，发送提示预警信息。
120.关于数据备份装置的具体限定可以参见上文中对于数据备份方法的限定，在此不再赘述。上述数据备份装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
121.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储引擎信息和备份数据的信息。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种数据备份方法。
122.本领域技术人员可以理解，图6中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
123.在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：获取各个备份引擎的负载情况；当存在备份引擎的负载情况不满足要求时，获取新的备份引擎；通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担。
124.在一个实施例中，处理器执行计算机程序时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担，包括：获取备份引擎对应的备份数据的数据编号范围；查询数据编号范围所对应的备份引擎的数量；根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎；通过备份引擎对对应的备份数据进行备份。
125.在一个实施例中，处理器执行计算机程序时所实现的根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎，包括：计算数据编号范围对备份引擎的数量的余数；根据余数确定备份数据对应的备份引擎。
126.在一个实施例中，处理器执行计算机程序时所实现的获取各个备份引擎的负载情况，包括：获取引擎表，并获取引擎表中的各个备份引擎的负载情况；处理器执行计算机程序时所实现的获取新的备份引擎，包括：从引擎池中获取新的备份引擎，并将新的备份引擎
增加至引擎表中。
127.在一个实施例中，处理器执行计算机程序时所实现的获取各个备份引擎的负载情况，包括：周期性地获取各个备份引擎的负载情况。
128.在一个实施例中，处理器执行计算机程序时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担之后，还包括：输出预警信息。
129.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：获取各个备份引擎的负载情况；当存在备份引擎的负载情况不满足要求时，获取新的备份引擎；通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担。
130.在一个实施例中，计算机程序被处理器执行时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担，包括：获取备份引擎对应的备份数据的数据编号范围；查询数据编号范围所对应的备份引擎的数量；根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎；通过备份引擎对对应的备份数据进行备份。
131.在一个实施例中，计算机程序被处理器执行时所实现的根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎，包括：计算数据编号范围对备份引擎的数量的余数；根据余数确定备份数据对应的备份引擎。
132.在一个实施例中，计算机程序被处理器执行时所实现的获取各个备份引擎的负载情况，包括：获取引擎表，并获取引擎表中的各个备份引擎的负载情况；计算机程序被处理器执行时所实现的获取新的备份引擎，包括：从引擎池中获取新的备份引擎，并将新的备份引擎增加至引擎表中。
133.在一个实施例中，计算机程序被处理器执行时所实现的获取各个备份引擎的负载情况，包括：周期性地获取各个备份引擎的负载情况。
134.在一个实施例中，计算机程序被处理器执行时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担之后，还包括：输出预警信息。
135.在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：获取各个备份引擎的负载情况；当存在备份引擎的负载情况不满足要求时，获取新的备份引擎；通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担。
136.在一个实施例中，计算机程序被处理器执行时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担，包括：获取备份引擎对应的备份数据的数据编号范围；查询数据编号范围所对应的备份引擎的数量；根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎；通过备份引擎对对应的备份数据进行备份。
137.在一个实施例中，计算机程序被处理器执行时所实现的根据数据编号范围以及备份引擎的数量，确定备份数据对应的备份引擎，包括：计算数据编号范围对备份引擎的数量的余数；根据余数确定备份数据对应的备份引擎。
138.在一个实施例中，计算机程序被处理器执行时所实现的获取各个备份引擎的负载情况，包括：获取引擎表，并获取引擎表中的各个备份引擎的负载情况；计算机程序被处理器执行时所实现的获取新的备份引擎，包括：从引擎池中获取新的备份引擎，并将新的备份引擎增加至引擎表中。
139.在一个实施例中，计算机程序被处理器执行时所实现的获取各个备份引擎的负载情况，包括：周期性地获取各个备份引擎的负载情况。
140.在一个实施例中，计算机程序被处理器执行时所实现的通过新的备份引擎对负载情况不满足要求的备份引擎进行负载分担之后，还包括：输出预警信息。
141.需要说明的是，本公开数据备份方法、装置、计算机设备和存储介质可用于金融领域，在其他的实施例中，也可用于除金融领域之外的任意领域，本公开数据备份方法、装置、计算机设备和存储介质的应用领域不做限定。
142.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。
143.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
144.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。