近两年来，磁盘备份在企业存储市场方兴未艾，已经成为继磁带备份之后另一种主流备份方式。磁盘备份由于其备份智能化、恢复速度快、对前端业务影响小等优势，资金充裕的大型企业往往优先选择磁盘备份进行关键业务数据备份。

　　但是磁盘备份就一定优于磁带备份吗？实际备份过程中，磁盘备份的效率受哪些因素的影响？企业在部署磁盘备份的时候，应该如何规避磁盘备份的瓶颈？笔者在多年的存储备份工作经验中，发现很多企业的磁盘备份系统都存在一定的规划问题，因而在整体系统中形成性能瓶颈，无法让磁盘备份系统发挥其应有的效率。下面我们将根据某大型电信运营企业的备份改造案例，分析磁盘备份的瓶颈所在，并提出切实有效的改进措施。

　　该大型电信运营企业采用D2D2T的数据备份模式，通过EMC NetWorker存储备份软件进行业务数据备份。每天对更改数据做增量备份，以三个月为周期做一次全量备份。

　　EMC NetWorker是较为成熟的存储备份管理软件，能满足复杂环境下的数据备份管理要求。在有据可查的实测环境下，NetWorker能够实现10TB/小时的备份性能。理论上，该电信运营企业的备份系统应该极为高效可靠，然而实际上，该电信运营企业备份系统长久以来一直无法满足前端业务运营带来的数据增长的压力。

　　磁盘备份面临的问题

　　该电信运营企业备份系统目前面临的问题包括：

　　1. 该电信企业采集应用的文件系统备份量比较大，有时会在规定的备份时间内无法完成备份。给数据安全和前端业务应用都带来一定的影响。

　　2. 因为数据量很大，因此恢复所需要的时间也较长。

　　3. 目前的备份模式做到了LAN free，也就是说备份数据不会占用局域网络的资源，对前端应用的网络数据传输不会造成太大影响。但是没有做到server free，也就是说，生产主机需要分配一定的运算资源来执行备份操作，因此拖慢了生产主机的性能，影响前端业务应用。

　　4. 备份数据与关键业务数据同时共享存储在一台生产中心的EMC存储系统上,然后迁移到备份中心的IBM磁带库上。虽然解决了主机备份时的容量和空间问题，但是，当生产中心机房发生灾难时，可能会导致备份数据同时丢失的隐患。要知道，容灾中心和生产中心全部依赖一套系统，一旦该系统发生问题，容灾中心也随之受到影响，不可能真正起到容灾的作用。

　　分析磁盘备份的瓶颈

　　该电信企业采用了D2D2T的数据备份模式，本身是目前较为先进的数据备份方式，在大多数备份系统环境下能获得较高的备份性能。那么为什么该电信企业的备份系统无法满足业务需求呢？

　　我们分析了该电信系统整体的备份架构，示意图如下图所示：

　　由于该电信企业文件系统的限制、磁盘接口的速度限制以及从磁盘到磁带的数据转移过程中单线程的限制，当大数据量的应用时使得磁盘的性能反而受到限制。

　　D2D2T的备份方式，本身由生产系统磁盘阵列先备份到备份磁盘阵列，再转存到磁带库，而其中，D2T（磁盘转存到磁带）这个环节采用的Stage/Clone的功能是单线程转移或克隆数据的。所以，在大数据量的条件下，无法发挥备份管理软件D2T这个环节的并发功能，造成D2T环节备份窗口的增大，恢复时间拖长，给系统的整体带来性能的瓶颈。

　　且由生产中心到远程容灾中心目前采用1Gb/s的双链路方式，不能充分发挥多个驱动器并行工作的高性能，因为在大数据量情况下会给系统整体性能带来瓶颈。与此相反，同一存储网络环境中的磁带库，因为通过多个驱动器的并行读写，反倒使得备份软件的并行技术发挥极致。

    根据该大型电信企业目前的网络状况，对各应用中的数据库、文件以及操作系统等数据的恢复过程加以统计，并在现在资源条件下和优化条件下，要求的恢复时间以及流程加以分析，提出如下几点改进意见。

　　不追加投资的系统优化措施

　　措施一：D2D方式中，备份磁盘从生产中心的EMC存储转换为备份中心的EMC存储问题：备份数据与关键业务数据同时共享存储在一台生产中心的EMC存储系统上，然后迁移到备份中心的IBM磁带库上。虽然解决了主机备份时的容量和空间问题，但是，当生产中心机房发生灾难时，可能会导致备份数据同时丢失的隐患。

　　解决办法：增加备份中心EMC存储的容量，将生产中心EMC存储上的备份服务器的配置和Oracle数据库的索引等重要信息由生产中心转存到备份中心，这样如果生产中心发生灾难，不影响整个备份系统。从根本上提高了整个系统的安全性。

　　措施二：将备份磁盘到磁带的转存方式由迁移改为克隆问题：从备份结构来讲，目前先备份到备份中心的磁盘阵列上，然后迁移到磁带库上。希望能在磁盘阵列上保留一至两个备份周期的数据，以便于数据的快速恢复。但是，目前的磁盘容量不能满足即使是一个备份周期的数据存放。

　　解决办法：数据在备份到磁盘的同时复制一份数据到磁带。这样，在备份磁盘阵列中的数据就可以随时以手动的方式进行介质回收；如果升级到目前的NetWorker7.3版本，可以将克隆时的源卷和目标卷设置不同的回收策略，很好的解决了磁盘阵列由于需要保留一至两个备份周期的数据造成的磁盘容量不足的情况。也防止由于生产中心的备份磁盘阵列损坏造成备份数据的丢失。

　　措施三：在备份磁盘阵列上建多文件系统问题：磁盘阵列的数据迁移会导致实际备份动作的延迟，而超出备份窗口。如何在有效的备份窗口内完成迁移和备份动作？

　　解决办法：通过建立多文件系统，能够使备份磁盘到磁带的迁移或克隆能够更好的利用多驱动器并行读写的高性能。从而使得从磁带恢复数据也能够发挥磁带库多驱动器的并行读写性能。

　　措施四：数据库的表级恢复问题：目前采用EMC NetWorker的备份，目前的技术使得备份的数据只有恢复后才能够使用（无法直接查询备份介质中的数据内容）。而且只能全系统恢复，而不能做到表一级的恢复（生产中心如果只损坏了数据库中的一个表，目前的备份方式无法解决）。

　　解决办法：推荐应用厂商对数据库中的重要表作逻辑导出。将逻辑导出的文件备份到磁带。这样在仅丢失一些表时可以更方便、快速的进行恢复。

　　此外，除了以上在现有存储网络架构上做的优化调整以外，为进一步提高该大型电信运营系统，还需要增加部分投资来实现更为优化的备份性能。这些措施包括：

　　追加系统投资完善备份系统

　　1. 增加生产中心到备份中心的光纤链路

　　由生产中心到远程容灾中心网通目前采用1Gb/s的双链路方式，不能充分发挥多个驱动器并行工作的高性能，因此我们推荐增加生产中心到备份中心的光纤链路，充分发挥多端到多端并行备份技术，减小数据由生产中心转移到备份中心的备份窗口。这样，我们也可以将生产中心的备份磁盘阵列或磁带库转移到备份中心，避免生产中心发生灾难导致整个系统的瘫痪。

　　我们还推荐在在业务服务器上采用双HBA卡，把生产和备份分开的方式。这样，在数据备份或数据迁移负载比较重的情况下，减少对生产服务器的压力，从而更好的安排生产与备份。

　　2. 数据采集系统增加ＮＤＭＰ备份模块，改变ＮＡＳ设备的备份方式

　　如上图所示，目前，数据采集服务器采集的数据是存储在NAS设备上，备份采集的数据需要从NAS先读出到采集服务器，然后再通过SAN备份到指定的备份存储设备。由于采集的话单数据都是小文件，按文件方式逐个进行备份的速度极慢，往往在一个备份周期内不能完成备份任务，即影响备份的可靠性，也过多占用业务主机和存储设备，进而影响整个备份系统性能。

　　我们推荐采用NDMP（网络数据管理协议）备份方式，以解决数据备份时间长、过多占用网络资源的问题。数据直接从NAS以数据块方式直接备份到指定的备份设备，不受小文件频繁打开、读写、关闭的性能影响，可以大大提高备份速度。

　　在现有的系统环境下，由于NAS专用网络与其他业务服务器处在物理隔离的网络，而EMC NetWorker的控制信息是通过IP网络传输，所以目前的环境不能与其他业务服务器共用一套备份管理软件。我们推荐在NAS专用网络增加一套新的EMC NetWorker备份管理软件，这样通过这个单独的备份管理控制端控制整个备份的进程；同时，IBM 3584磁带库具备磁带库分区的功能，我们可以将其分成两个磁带库给不同的备份管理软件使用。也可以在单独采购一台更高性能、更可靠的大型磁带库。

　　3.实现磁带库与磁带库间的并行复制

　　在原有系统基础上，在生产中心增加高可靠性、高性能磁带库设备的方式，如选用高端SUN/StorageTek的SL8500磁带库。通过多驱动器的并行读写，备份和恢复速度可以提高至少2倍，在选用更好的驱动器和磁带，备份和恢复速度将有大幅度提高。如果由生产中心到备份中心的光纤链路4条以上，我们可以将生产中心的磁带库放置在备份中心。增加一台新磁带库也用以防止由于IBM3584磁带库的硬件故障造成备份系统的瘫痪。

　　4.增加NetWorker PowerSnap模块实现ServerFree备份方式

　　增加NetWorker PowerSnap模块实现ServerFree备份方式，NetWorker PowerSnap Module可以在应用服务器上与磁盘阵列的快照功能通讯，触发指定磁盘卷的快照，然后自动将快照挂接到指定的NetWorker Proxy 服务器上，进而从NetWorker Proxy 服务器通过快照对磁盘卷上的数据进行备份。这样备份既对生产主机没有任何性能影响，又大幅的提高备份系统的整体性能。如果从生产磁盘中的读数据速度足够快得话，整体性能将提高3-4倍。

　　总结：备份规划最重要

　　经过调整后，我们重新分析了从以上各种架构的数据备份所需的备份与恢复时间。我们可以看到，如果不追加投资，在现有资源基础下进行系统优化，数据恢复时间要比目前系统的恢复时间缩短50%-60%。

　　如果追加部分投资，新增一台磁带库的方式，将大数据量的全备份连续写入到磁带库中，将逻辑日志以增量的方式备份到磁盘阵列中，这样不仅解决了由于物理磁带库的机械故障导致备份系统崩溃的问题，又在现有资源条件优化后的基础上缩短备份时间50%。

　　我们可以看出，新增一台磁带库的方式，的确能够很好的解决目前该电信企业备份系统所发现的问题。磁盘备份目前而言被公认为较为先进的一种备份模式，很多企业都会优先采用磁盘备份，认为备份效率理所应当快于磁带备份。但是往往会像该电信企业一样，因为事前未对整体备份数据流作充分的分析，整体系统中存在瓶颈，因而无法获得应有的备份性能。笔者发现电信行业很多公司的备份系统都存在类似的弊病，而另外一些大型企业的磁盘备份系统，也或多或少存在一些因规划不充分而导致的性能瓶颈。

　　真正合理的备份系统重点不在于采用何种备份技术与架构，必须考虑整个系统每个环节的运行效率，否则极有可能在某一环节产生瓶颈，拖慢整个系统的运行效率。选择何种备份架构，必须对整体备份数据流做详细地分析后，才能做好规划。