分析磁盘备份的瓶颈

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[1] [2] 下一页  

【责编:Chuan】