企业备份系统建设运维五大难点如何应对？

1、关于企业数据特点分析和企业备份系统选择

典型难点问题：

如何对企业数据进行分级之后选择合适的备份策略？如何选择虚拟机的备份方式？如何选择海量图片数据的备份工具？

近些年来，企业的数据逐渐呈现多元化格局，从数据的模型层面可以分为结构化数据、半结构化数据、非结构化数据。从企业IT功能层面又可以将常见数据列为如下几类：

Ø 关系型数据库中保存的二维表数据。

Ø 非关系型数据库中的文档、JSON、键值等类型数据。

Ø 以文字方式记录的文本、PDF、XML等文件形式的数据。

Ø 以二进制方式记录形成的图片、网页等数据。

Ø 以视频流方式记录形成的媒体类数据。

作为企业来讲，确定备份哪些数据对象，需要从数据重要性、数据量、数据特点等若干方面去评估。从企业业务角度评估的话，那么数据库保存的数据一定是最重要的，尤其是关系型数据库里面的二维表数据。其次需要根据行业特点以及具体的业务系统重要性来评估非结构化数据的重要性。比如对于金融行业来讲，记录业务过程的一些影像类数据可能在业务审核过程中经常被调出查阅，这些数据虽然没有结构化数据那么重要但是也是业务环节当中比不可少的元素，其重要性相对业务视频类以及安防类视频数据会高很多。但是如果是媒体行业的话，那么视频类数据的重要性恰恰是支撑其业务的核心数据，其重要程度不言而喻。那么如何来决定哪些数据需要备份，以什么样的策略备份？

首先，我们需要确定数据的重要性程度。通过结果导向的思路从以下维度来分析企业数据的重要性，最终决定哪些数据需要备份，哪些数据可以不备份，哪些数据需要根据企业的实际投资战略情况来决定。

首先我们假定一个结果，那就是某个应用系统的某类型数据由于硬件故障或者其他原因导致数据丢失掉了。那么就看企业对该结果的容忍程度，假设不能容忍，那么就没什么好商量的了，肯定要做备份。接下来，最重要的事情是我们如何定义数据备份的策略，包括备份的频度、备份的模式、归档的档期等等一系列备份作业元素。这部分内容需要考虑到数据本身的量级、数据的具体类型、极端条件下对数据恢复时间及数据丢失量的容忍程度、数据备份系统以及备份介质本身的性能特性、业务发展的规模及趋势判断等等。从以下几个原则来进行评估：

Ø 数据库的备份既要有全量备份也要有归档日志的备份，全量备份可以根据数据量及重要程度以天为单位进行频度调整；归档备份可以根据数据库恢复区空间预留、归档增长趋势、数据恢复时间要求、业务系统归档特点等多方面来进行以小时为单位的频度调整和作业发起调用。

Ø 文件类型数据可以根据具体数据量来选择是否利用传统的文件复制方式来实现其备份，对于数据量大的情况可以采用存储快照方式进行卷级别的复制代替以文件为单位的扫描复制方式。

Ø 系统备份作业的分布以及备份时间需要结合具体的备份窗口来进行合理调整，关键业务系统的备份作业不能影响到正常的业务，需要有强制的约束条件来约束备份作业时间跨度。尤其是全量备份，随着业务不断发展，数据量会与日俱增，如果对备份作业不进行任何调整，那么很有可能原有备份作业会超越备份窗口影响到业务性能。

Ø 根据具体的数据类型和业务重要性对所有备份作业进行分级管理。有些数据需要持续备份，有些数据可能只需要在特殊变更日进行备份即可，例如虚拟化的VMDK文件数据，完全没有必要进行持续备份，只需要在变更后进行备份即可。

以上是对备份对象的确定以及如何把握具体的备份策略的分析和描述，具体细节及关键方法可以参考文章：

企业备份系统规划过程中必然遇到的七个关键问题

▶▶▶

虚拟机数据算是近些年来比较典型的一类型数据。

首先，需要判断虚拟机在整个架构策略当中的体系结构是怎样的，是否有必要频繁备份。假设我们的虚拟机高可用策略足够，对于一个应用池可能会有N多虚拟机去提供同样的服务，那么虚拟机的备份就变得没那么重要了。同样如果我们能将应用打包发布实现自动化和标准化，那么完全没有必要去频繁备份虚拟机。

其次，虚拟化平台可能都会有自己的备份模块儿，例如VMware的VDP软件模块儿。关键是看第三方备份软件和虚拟机平台本身的备份模块儿是否有接口。如果是VDP的话，那么很多备份软件都可以调用其VDP模块儿。再有，如果要用虚拟化平台本身的备份模块儿，那么还得看其与备份介质以及备份环境的兼容性如何。尤其是从备份性能上来考量。有些备份协议的速度会远远超过正常的复制速度，这是我们应该采用的渠道。

▶▶▶

海量的非结构化图片数据或者是小视频数据也是近些年来比较典型的一类型数据。对于它的备份，最大的问题在于对数据的扫描。如果用传统的备份软件模式，由于细碎图片文件的剧增，光扫描就会花费非常多的时间。

解决这个问题大概有两种思路：第一种，利用存储卷本身的快照技术做备份。这样的在线数据，我们一般采用NAS卷来存储，利用存储卷本身的快照技术可以避免备份时的大量耗费时间的扫描。第二种，利用对象存储技术。对象存储技术利用键值方式来代替传统的文件目录方式来实现文件的检索，同样可以必秒大量的扫描时间。

2、如何去决策系统建设的复杂度和规模？

大多数同业朋友认为企业的备份系统建设，首先要对企业的数据进行分析，对其的重要性、特点、数据量、在线离线特点等多个维度进行全方位分析。

如果数据非常重要，那么我们一定需要一个科学合理的备份恢复系统来保障企业的数据完整性；

如果数据特点多样化，既有结构化的数据存储在数据库中，又有很多非结构化的图片、视频、文本等数据，那么我们的备份系统就应该是一个多元化的因素组合；

如果我们的数据量增长速度非常快，量级非常大，那么我们的备份方法一定是需要进行技术革新，突破传统备份方法的瓶颈。例如对象存储的引入，快照技术的引入、云存储技术的引入等。

如果我们的数据生命周期呈现出多个阶段，那么我们就要考虑数据在线离线的各个不同阶段需要有不同的存储介质，并且利用不同的方法和架构。这就是一个完备体系的建设问题了。

3、关于临时性的备份问题

典型难点问题：

在机房的搬迁过程中，在系统的迁移过程中，在系统的切割项目过程中，我们如何保障数据的备份和恢复机制？

这个问题其实是很多企业都会遇到的问题。在这种场合下，我们可能仅仅需要对移动数据进行一个临时的备份以防在项目执行过程中的数据意外。但是企业又不愿意为这种事情投入很多资金去购置新的设备。

根据大家的经验探讨，很多企业采用了租赁的方式来解决备份介质的问题，采用数据库复制技术或者是备份软件复制技术来实现临时备份。随着云计算技术的发展，其实很多备份软件以及数据库技术都可以很容易实现与云存储的接口调用。所以如果将我们的备份系统规划的相对比较健全的情况下，我们可以利用云存储来实现临时备份数据的存放。所以在建设过程中，云存储的利用也应该归入备份系统建设规划元素序列当中。

4、关于备份恢复环境的建设问题

典型难点问题：

如何选型备份系统架构问题？如何备份环境和异机恢复环境建设合理性问题？如何选择备份系统的高可用以及容灾架构？

首先，从架构建设层面考虑，我们可能会遇到以下三个方面的考虑：

1）. 备份系统涉及到的关键对象

所谓备份系统中的一些关键对象包括：备份软件、备份介质、备份管理服务器、备份作业服务器、备份路径等。这些关键元素共同组成了一个完成的备份系统。

Ø 备份软件：常用的备份软件包括IBM TSM、EMC Networker、SYMANTIC NBU等。

Ø 备份介质：常用的备份介质包括带库、EMC DATADomain、常规存储等。

Ø 备份管理服务器：对备份作业进行配置调度并且保存备份元数据的集中管理节点。

Ø 备份作业服务器：具体执行备份作业的备份服务器。

Ø 备份路径：每一个备份作业从客户端采集数据到备份介质的整个路径。

2）. 基于容灾功能的备份架构

一般的企业可能只需要进行本地备份即可，但是对于某些行业尤其是金融行业，备份要求比较高，需要采用主数据中心和备数据中心联动的高可用备份架构。具体如下图所示：

整体架构从上到下分为三层：备份客户端层、备份控制层以及数据存储层。中间通过网络（以太网络或者是光纤网络）相连接。红色线表示控制信息流向，蓝色线表示备份过程中的数据流向。

Ø 备份客户端层，图中最上面的部分既是。备份客户端是我们要备份的数据对象存放的服务器，例如数据库服务器、虚拟化平台的VCenter、NAS服务器等。一般需要备份软件的客户端AGENT安装到备份对象服务器上实现备份目标与备份服务器的通讯。

Ø 备份控制层，图中中间的部分既是。主要包括备份主服务器和备份作业服务器，主服务器根据配置好的调度策略以及整体架构中的备份元素发送作业调度指令，并且将存储片的元数据存储到主服务器上的数据库当中。然后作业服务器可以通过与客户端的交互完成具体备份作业。元数据是具体备份片的索引信息、而真正的备份片数据会通过作业服务器送入备份介质当中，当我们对数据进行恢复时，首先需要对备份数据的元数据分析才能知道具体的数据备份位置及组合信息等，然后才能通过元数据的组织和具体备份片的恢复完成一个业务数据的完整恢复。

Ø 数据存储层，图中对下面的部分既是。实际上就是备份数据最终要存储的地方，可以通过光纤网络或者以太网络实现其与备份控制层的连接。传统模式一般会是光纤网络和虚拟带库的组合模式，其优点在于备份速度和容量的性价比上。但是近些年来随着以太网技术的发展，利用高速网络实现的备份数据传输同样可以保障其备份速度，同时具备更好的灵活性。所以近些年来利用万兆以太网和DDBoast组合的方式也越来越多。

3）. 备份架构高可用性分析

整个备份系统的高可用性是由每一个部分服务的高可用配置来保障的，主要包括备份控制层、备份存储介质层以及跨数据中心级别的高可用架构配置。下面我们分别来做剖析：

Ø 主备份服务器是整个备份系统的集中控制节点，其保存的元数据也是备份得以恢复的关键数据，因此为了保障主服务器的不间断工作，需要保障主服务器为主备或者更高级别的高可用架构，元数据为所有本地主服务器共享，如图2.2中所示的HA模式。

Ø 作业服务器是所有备份作业的执行者，必须将其组成一个备份作业服务器池，由这个备份作业服务器池向客户端提供统一备份作业服务才能保障备份作业的不间断性以及备份作业并发执行的性能，备份作业可以分布在不同的作业服务器节点上进行作业，如图2.2中所示的负载均衡资源池模式。

Ø 从备份存储介质层面上来看，为了保障备份作业无中断目标，我们需要将两个或者多个存储介质设备绑定为一个虚拟的存储介质池，当存储介质发生故障时可以自动切换存储介质设备，至少可以手动切换存储介质设备。

Ø 容灾角度来看，如图2.2所示：两个备份域之间备份介质可以通过光纤网络层或者是以太网络实现数据的异步复制，这样可以保障真正的备份数据可以跨地域实现数据保护，但是光有这些数据我们无法实施数据恢复，因为数据恢复过程中最主要的是要根据元数据记录的备份片索引及结构目录找到真正的数据备份片实现完整的数据恢复。所以主备份服务器也要实现跨域界别的元数据复制。

▶▶▶

关于异机恢复的问题，其实这个也是很多企业都面临的问题。因为我们可能会有很多的测试、验证等业务需求需要用到这些历史数据。

首先，我们需要将其进行恢复，恢复到某一个需求时刻点。

然后，我们需要将数据进行脱敏。

最后，才能提供给测试或者验证类业务需求。

但是往往备份环境与生产环境是相通的，但是测试环境或者是业务验证环境跟我们的生产环境是物理隔离的。这样的话就会造成这类型需求处理的复杂性，尤其是在数据量非常大的情况下。所以我们需要构建一个桥梁点，这个点可以将备份数据共享并且仅仅给恢复环境，当然这个需要在安全策略和防火墙端口控制上去严格把控，把安全风险排除出去。

5、关于备份作业的调度问题

典型难点问题：

有限的备份时间窗口期内，如何实现多备份任务的时间均衡？如何平衡数据库备份的各种策略？例如归档备份的频度？全量备份的频度和时间分布？面对不断增加的备份作业，如何平衡等问题？

首先，对于频繁调度的增量备份作业来讲，尤其是数据库的归档日志备份。一方面是要保障增量数据备份的完整性，另外一方面是要避免因为恢复空间不足导致数据库的宕机时间。要平衡这个频率窗口需要采集以下几类数据：

1）单位时间内不同数据库系统平均的归档日志量。

采集这个数据的目的在于详细分析不同业务系统在不同时间段的写操作频繁程度。对于日志归档速度较快的系统，我们需要提高其恢复区的空间大小，同时加快归档备份的频率，使得数据库既能处于安全运行状态又能保障极端故障场合下数据丢失的量在较小范围之内。

2）业务系统类型。

所谓业务系统类型即OLTP或者是OLAP，因为对于OLAP来讲，每次的读写操作都会是批量的执行，它的归档速度是正常OLAP系统的几十倍甚至上百倍。最麻烦的是两者皆有的业务系统，比如说银行业中的交易系统，白天跑联机交易，晚上跑核算批量，白天和晚上的日志归档速度有着巨大的反差。那么我们就需要在批量作业时间段内将备份频率调快，将恢复区空间设置提高。

3）备份系统可以容忍的最大并发量。

备份系统可以容忍的最大并发Jobs，不仅仅取决于备份软件系统可以并发调度的作业数目和备份作业服务器的数目，还要取决于备份介质池可以容忍的资源消耗限制。及时我们可以同时调度几百个作业，但是当几十个作业同时写入备份介质池时就会把备份介质池的计算资源或者是IO资源使用殆尽。那么最终整个备份系统的并发数取决于短板因素。

4）不同数据库系统恢复区能够支撑最小时间窗口。

这个最小时间窗口是我们用数据库的恢复区可用空间大小/单位时间内的最大归档速度来估算出来的时间窗口。因为我们在安装数据库或者是做变更的时候不可能按照每一个系统的特点详细计算出其日志存储空间的大小，只能按照有限的几个规格来做初始规划。

有了以上数据之后，我们需要根据以下几个原则来详细设计我们的归档作业频率。

首先，根据4当中采集到的数据，将时间窗口较小的几个系统进行存储空间调整，使其日志存储空间能够满足我们期望的最小时间标准。

然后，将一天24小时定义为几个时间段，批量业务集中的时间段、联机业务集中的时间段、特殊任务集中的时间段等。当然这个定义主要是根据1&2中采集到的详细数据来定义的。

接着，我们需要根据1中数据估算出一个归档作业大概持续的时间长度。为保障每一个时刻点的并发执行备份作业数目远小于3中估算出来的数据。

最后，需要把备份作业的频度根据不同的时间段特点调整到以上条件都满足的状态，并在此前提条件下可以为了保障极端情况下的数据完整性而适当调快归档作业的备份频率。下图是一个根据以上采集数据进行多维分析的实例，仅仅是一个方法示意，归档频率根据数据重要性分级、归档速度、业务时间段分类等前提进行的粗略分析，最下面的一行数字表示每一个时刻点并发的归档备份数目，其目标在于平衡每一个时间间隔内的平均备份作业数。实际情况会比以下情况复杂很多，我们可以将时间间隔划分的更小，涉及的因素更多，分析的更加细致。

▶▶▶

对于全量备份作业来讲，随着数据量的不断增加，其备份作业耗费的时间也就会越长，耗费的数据库资源也越多，对在线业务的影响也就越大。另外同一个时间段内发起的全量备份越多，那么其占用的备份系统整体资源（备份服务器、备份介质池、链路带宽等）也就会越多，其影响范围也会越广。

首先，这个问题是一个需要不断优化的问题。对于每一个应用系统来讲，根据业务服务的特点，其备份的时间窗口也是不同的。可能初期备份作业能够在备份窗口内完成，但是随着数据量的增长，后期的备份作业就会超过备份时间窗口。所以我们需要定期监控数据库的全量备份作业时间，在事件窗口范围内尽量通过调整合适的调度时间来完成全量备份。但是当数据量增长到完全没办法在备份窗口完成的时候，那么我们就需要进行调整全量备份的频度和具体调度时间点了。

其次，这个问题是一个跟业务特点密切相关的的问题。有些人喜欢把所有的业务系统都按照一个标准去定义其数据库全量备份的策略。比如说TB以下的数据库，每天一次全量备份；比如说业务等级属于重要的系统，每天一次全量备份；比如说只要能备份的系统，全部进行每天一次的全量备份等等策略。这些都是不科学的策略。应该从业务系统的数据重要性去评估数据库全量备分的频率，在现有备份系统有限的处理能力内保障数据重要性高的系统完成相应的全量备份。

最后，这个问题是一个需要从各个方面着手去解决的问题。从备份网络的带宽和隔离性考虑，应该用单独的告诉备份网络，备份客户端应该设置区分于业务的单独网络通道及配置。从备份作业服务器的配置层面，我们应该配置相对合理的资源（内存、磁盘）来保障备份片在作业服务器层没有瓶颈。从备份介质池层面，我们需要保障备份介质的IO处理能力不能成为备份作业底端的性能瓶颈。

▶▶▶

对于作业的平衡性问题，其目的就是要保障备份时间窗口内调度起来以及运行过程中的备份作业处于一种平衡状态，不能使其作业调用或者是并发运行过于集中。但是当系统数目非常多，系统特点复杂，数据重要性级别有很多种，数据量以及数据增速各不相同时，这个问题就变得比较复杂。我们很难有一种精确的计算方法来实现其做到绝对，但是我们可以根据以下的方法进行定性的分析和调整。

假设我们定义一个系统的备份作业在备份体系当中必须具备的属性为：

P1 - 应用系统数据的重要性级别属性，可以通过业务分析划分为有限的几个级别。

P2 - 应用系统在不同时间段内的数据增量属性，需要通过梳理历史数据来评估。

P3 - 应用系统当前的备份作业的时间长度属性，需要通过历史数据结合数据量来评估。

P4 - 应用系统是否是具备双重业务特性，比如兼备批量和联机业务特性。

通过以上几个属性的加权计算或者其他方法的定性分析，计算出每一个系统的不同备份作业的定性矢量，然后我们可以将这些矢量根据其具体备份窗口设置初始的调度时间点，然后分析其具体分布图是否均衡稳定并且进行微调。

本文由社区专家赵海根据社区交流归纳总结整理。