【核心议题5】数据爆发导致的备份窗口不足，备份软件如何优化备份环境？

我觉得首先要看爆发的数据是什么样的数据，结合数据类型，在时间窗口不足的情况下，就需要提升备份性能，在有限的时间内，更多的传输备份数据，目前在提升备份性能上我觉得手段无非是从LAN切成SAN，或者从千兆变万兆；如果已经是SAN那么增加备份通道；再有就是重复数据删除的功能了。

从架构上来说，如果备份直接落到带库的话，可以考虑增加磁盘设备，之前测试VeritasNBU的一体机时候发现虽然用的是磁盘设备，但是可以走SAN备份，而且对于重复数据的备份性能较高。f

关于这个问题，我的看法是先按两种情况来分析：

第一种情况是，现有的备份架构不变，在架构内进行分析。首先， 抛开数据量大小，我们先来梳理一下影响备份速度的几个因素

A. 备份服务器的性能，也就是处理能力。备份服务器是整个备份环境的核心，备份数据的元数据索引、备份介质管理、客户端调度管理都需要服务器处理能力来支持，如果再有数据重删，远端复制等附加功能，对服务器的性能要求会更高。

B.客户端的IO处理能力。网络传输类型（san or lan），网络传输速度（lan的十百千兆速率选择，光纤2/4/8/16GB速率选择等）、IO并发度（磁盘卷或磁带机数量）等等都会影响IO速度。

C.备份对象的数据类型，是海量小文件，还是常规文件。

D.备份介质的质量。比如同样是物理磁带备份，从早期的LTO3到最新的LTO7，速度和容量差别巨大，参考以下图片（图片来做www.lto.org）

图片中的容量和速率都是按压缩后的最大值来算的。

举个例子，1个2T的数据库，如果以LTO3的单驱动器按80M/s来算，需要7个小时左右，但是如果是LTO7单驱动器按300M/s来算，只需要2个小时。如果再以多个驱动器来做多通道的话，时间都可以控制在1个小时以内。

现在大多数企业都开始使用虚拟带库，虚拟带库在速度、驱动器的并发性上更加灵活，并且在数据恢复上，有更大的性能优势。也可以结合物理带库来做d2d2t使用。

第二种情况下，数据的增长达到了一个质的增长。通过调整备份环境的软件和参数已经无法满足备份窗口。一般可以考虑如下方案

A  配合现有存储的硬件特性来做，比如IBM的fcm就可以和大多数的主流存储配合，以存储硬件快照和tsm离线保存相结合的方式来提供备份解决方案。可以把备份窗口缩短到分钟级，并且通过tsm进行管理，还可以将备份的数据存放到磁带库中。其他备份厂商也有类似的解决方案。

B 采用新的备份架构，比如飞康的cdp、veeam的备份解决方案等，在某些细分领域都做的非常好。

如果不做备份系统分离，唯一的办法就是提高并发速度了。

如果是用带库，增加驱动器；

如果是存储，那并发这个可以设置，客户端备份可以增加会话数。

如果性能压力不在后端存储或者磁带库，那就是网络以及生产系统的性能问题了；那就是升级升级

楼上几位说的都挺好。我简单说下我的想法。

1.基础架构

评估网络以及光纤传输速度，选择速度最快的方式。或者提高基础建设，从服务器性能，网卡，光纤卡，san交换机，带库方面入手，找到瓶颈，另外选择合适的备份架构，lan,lan-free, server-free, 或者使用Tivoli flashcopy 等。

2.备份优化

可以使用并发，重复数据删除，永久增量备份等方式，减少数据传输，提高备份速度。

3.应用优化

可以参考tangbin1124 的，如sql server的数据库分离等。

以及根据业务重要程序等方面考虑，合理规划备份窗口。

如果是数据库的话，这些相对好办一些，比如：

Oracle，考虑上DG

sql server，考虑allwayson

mysql，考虑主从复制

等等

如果是文件，考虑重复删除的一些备份软件

一般都是更改备份架构.一楼都说到了

主要是规划问题，好的设计会规避好多问题。

感谢高手嘉宾的分享~有个问题向追问一下，您提到的影响备份速的因素：

C.备份对象的数据类型，是海量小文件，还是常规文件。

D.备份介质的质量。比如同样是物理磁带备份，从早期的LTO3到最新的LTO7，速度和容量差别巨大

能再展开谈一下吗？

特别是C，关于海量小文件备份性能问题，这个好经典，想听听大拿意见~多谢多谢！