重复数据删除技术生存指南（第一篇）

VTL解决方案

飞康（FalconStor）、NetApp和Sepaton等VTL解决方案提供商通常会认证一系列备份应用，但是他们在数据来源和目标设备方面却不是一视同仁的。

VTL解决方案仿效的是磁带库。因此，只有支持磁带库的应用才能使用VTL，这本身就具有一定的局限性。

目前数据中心常用的设备会将数据传输到磁盘中，而且不支持磁带协议。许多数据保护功能不支持将数据复制到VTL的操作。

目前VTL解决方案在重复数据删除方面的局限性大多集中在附加的管理复杂性和in-line与post-process的争论上。总的来说，附加的虚拟磁带管理需要在磁盘上模拟磁带，这让已经就很复杂的环境更加复杂。

Post-processing还使未来日常管理工作变得更加复杂，而且对重复数据删除的时间和复制时间有负面的影响。Post-processing还需求有额外的磁盘空间来支持重复数据删除技术。

最后，更多的空间就意味着需要管理更多的磁盘、更多的能源支持、冷却设备、当然还需要更多的占地空间、购买更多磁盘。到目前为止，厂商大多是通过使用较低效的post-processing重复数据删除方式向现有的VTL产品中增加重复数据删除功能。

基于软件的重复数据删除技术和单实例

备份软件厂商开始向他们现有的功能特性中增加重复数据删除功能。除此之外，CommVault等备份软件厂商开始使用单实例等数据缩减技术，这项技术可以在备份主机接收到数据并进行文件级的比较时启动这项功能。

虽然这种方法消除了备份流程对存储空间的要求，但是却无法解决房网络带宽问题，也不能解决同样数据产生多个副本的问题（只有在某些特定应用中运行的数据才能进行冗余比较）。

单实例存储不能解决备份存储的其他问题——一段时间内变动很小的文件。

有了单实例存储，那些每天没有变化的文件被剥离备份流程。然而，在任何备份策略中，不发生变化的文件都不会成为问题，有问题的往往是那些每天都会有小变动的大型文件。

一般数据库、VMware镜像、Exchange存储每天的变动都很小。基于文件的单实例对比将把这些变动识别为不同的文件，而不是有变化同一文件。也就是说，所有这些文件都必须再保存一次。这与真正的重复数据删除技术相比数据缩减效果就差很多。显然，如果没有基于块的数据缩减就无法节约空间，尤其是对数据库文件来说，这些文件一般来说都很大，

单实例存储无法解决的另一个难题就是同一个数据组往往有多个备份来源。例如，备份管理者可能会使用备份软件的Exchange模块来对Exchange进行备份；Exchange管理者也可以用别的工具来备份Exchange保存文件。这时候不会发生数据删除，因为备份软件不能识别独立独立工具产生的备份文件。

在两种情况下（经常有小变动的应用和多个备份来源），一个以块层级运行的重复数据删除系统可以识别冗余数据块，减少备份来源不同可能带来的影响。

使用这种单实例技术的软件供应商认为，这种存储方法更适合于恢复，也就是说，重复数据删除系统在恢复方面存在性能问题。虽然一些软件提供商的重复数据删除系统存在性能问题，但是当系统配合何时的架构，那么性能问题对重复数据删除流程就不会有太大影响。

在现实世界的数据中心中，备份数据和源服务器之间存储其他瓶颈使得从通用重复数据删除系统的恢复成为一个问题。如果恢复性能需求超出了从磁盘恢复的能力范围，可以考虑使用其他例如集群或者主动目标等高可用解决方案。（主动目标是可以被浏览或者向正常文件系统一样读取的备份目标）

最后，使用单实例存储的做法大多是将一个软件应用用于所有备份、归档和其他数据管理功能。这是不实际的做法。虽然许多备份软件提供商除了备份之外还提供了其他一些附加组件，但是这些附加模块的功能性也是千差万别的。实际上大多数用户采用的是备份和归档分离的解决方案，以及针对某个特定平台（例如VMware）的应用。而且一家软件开发商在针对一个特定数据库或者操作系统的模块开发项目上的资金投入也不尽相同。

总结

通用重复数据删除系统对数据来源、协议、互连性以及数据类型一视同仁的特点使它成为存储备份和归档数据的最佳工具。谨记一点：不要只局限于备份软件内嵌的某个特定重复数据删除模式，或者只局限于VTL中只支持磁带的协议。