企业备份系统运维管理关键问题讨论

【摘要】：对于每一个企业来讲，数据备份恢复是企业 IT 运维当中非常重要的一部分。如何保障必要的数据在必要的时间完成必要模式的备份，并且能在需要的时刻将正确的数据在正确的位置恢复，这是数据备份恢复运维工作必然的考核指标。本文通过大量的运维实践总结出备份系统运维工作当中遇到的一些关键问题，并且按照实际解决方案提炼解决思路。希望能给企业日常的备份系统运维带来一些启示和帮助。

【关键字】：备份介质 ；备份作业；备份系统

1. 如何解决平衡数据库归档频度和数据恢复完整性

1.1 数据库恢复的基本原理

对于数据库的恢复来说有很多种，我们只讨论需要介质恢复的情况。在这种场合下，首先我们需要找到一个最近时刻点的全量备份进行恢复；然后需要从备份介质上找到这个时刻点之后的重做日志进行数据追平，最后我们需要找到本地没有丢失的重做日志进行再次追平直到没有可用日志。如下图所示：

图 4.1 数据库恢复原理示意图

如图所示，在时刻 A ，我们开始做在线全库备份，在 B 时刻全库备份结束。当数据库运行到 E 时刻之后数据库发生了重大介质故障，只能通过介质恢复。那么在 A~C 时间段内，大部分 REDO 日志文件都已经归档到备份介质池当中，服务器本地存储目录当中只剩下 C~E （小于一个归档备份时间间隔）的归档日志和没有来得及归档的 REDO 日志文件。假设发生的故障严重到服务器本地存储目录也无法恢复的时候，那么相当于在 C-E 这段时间产生的重做日志就丢失掉了。相当在这种极端场合下，数据丢失的最大窗口就是一个归档间隔时间段。当然如果把这个间隔设置的足够小的话，那么另外的问题就产生了，备份作业随着系统增加会呈爆发式并发启动状态，最终会影响到整个备份系统的健康运行导致归档无法及时转储，最终还是可能会导致数据库的宕机。这就是一个矛盾，需要我们去很好的平衡。

1.2 平衡数据库归档频率的方法

数据库归档备份的频率是指一天 24 小时内间隔多长时间进行一次归档日志的备份，一方面是要保障增量数据备份的完整性，另外一方面是要避免因为恢复空间不足导致数据库的宕机时间。要平衡这个频率窗口需要采集以下几类数据：

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

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

2） 业务系统类型。

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

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

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

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

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

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

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

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

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

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

图 4.2 数据库归档频率规划分析案例

2. 如何评估数据库全量备份的策略

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

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

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

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

3. 如何解决备份作业分布合理性问题

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

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

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

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

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

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

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

图 4.2 备份作业分布定性分析案例

以上案例仅仅是一个相对粗略的分析方式，仅仅是一个基于某一特定案例的分析思路。我们可以根据业务系统特点结合更好的专业工具进行更加细节的分析。但是总体目标是让我们的备份作业分布达到一定范围内的平衡，另外在某些特定的业务场合或者特定的设备场合下，可能会有一些特殊的时间窗口需要和备份作业适当分割开来，比如说基于文件系统技术实现的备份介质存储池，由于我们的周期性归档配置，它会定期去做文件系统的清理作业，而且时间段比较长，耗费资源比较高。我们尽量要讲备份作业的分布策略与这些时间段保持适当的分割。这样才会保证备份系统运行的长久安全稳定。

4. 如何解决业务发展与备份系统有限性瓶颈

所谓的业务发展在备份体系建设过程中包括几个方面的影响。一方面业务量的增长会导致备份作业的不断增加，另外一方面业务量的增长会导致现有备份作业负载的不断加剧，再有就是各种新业务的增加会带来新型模式数据备份的挑战。这几方面的因素不但会对现有备份系统的负载扩展能力提出巨大挑战，也会对现有备份系统功能扩展能力提出巨大挑战。

解决以上问题，本文认为唯一可行的方法就是从单一传统的备份系统逐渐过渡到完善的备份体系。传统的备份软件形成的格局只是这个体系的一个元素，基于快照的备份接口、基于软件加速的接口、基于异构平台转储的模块儿都应该成为这个体系当中的扩展元素；同时备份介质也应该从单一的带库、 DD 等传统备份介质扩展到由现有备份介质池和分布式存储池、对象存储池、云端备份池等多种元素组成的广义备份介质池；单一的备份恢复模式也应该转换为多级数据一体化模式，既包括多级数据的转储归档机制，又包括数据自动化下沉和上浮的机制，数据流向实现自动化平滑轨迹。

目前可以实现以上体系的软硬件产品组合有很多，各家都有各家的特点和局限。关键是要靠规划者根据自己的业务特点和长远的发展预测来选择和集成合适的解决方案。