重复数据删除产品可以显著降低对存储空间的需求，但是如何选择一个最适合你的产品却不是一件容易的事情。

　　近一段时间来，夸夸其谈的各种产品介绍、日益迅速变化的各种技术以及一些时不时出现的神论，这一切都使得重复数据删除这个新技术领域越来越让人无法捉摸和信服。但是，对于一个成功部署的重复数据删除系统来说，其所带来的收益是毋庸置疑的。

　　“我们已经发现单一实例存储（Single-Instance Storage）正在被使用到越来越多的二线存储系统以及归档存储系统当中。” Enterprise Strategy Group (ESG)的分析师Lauren Whitehouse说：“有不少重复数据删除产品甚至已经可以作用于主存储系统。”

　　这项技术正在迅速地走向成熟。“我们其实在两年前就关注过重复数据删除技术，但那时它显然并没有成什么气候。”制造数字媒体芯片的Milpitas, CA-based Magnum Semiconductor公司的IT总监John Wunder说道。就在最近，Wunder把几个厂商的产品集合起来进行了测试，包括Diligent Technologies 公司(数据重复删除技术引擎提供商), Symantec 公司的Veritas NetBackup以及 Quatrio (服务器和存储提供商)

　　将所有这些不同厂商的不同产品进行集成，需要对不同的重复数据删除技术有一个清晰的认识和理解，以及在投产之前需要进行彻底的测试，同时，还需要时刻关注对应产品的主要架构变化，比如混合型重复数据删除技术（见下文的“不同的重复数据删除技术”一节），以及全局重复数据删除技术。

　　不同的重复数据删除技术

　　不久前，重复数据删除技术还被界定为在线和后处理这两种不同的形式，但是现在厂商似乎正在将这两种形态的界定模糊化。

　　飞康公司提供了一种被其成为混合模式的重复数据删除技术。传统的后处理模式的重复数据删除的过程一般都是在整个备份工作结束之后才启动重复数据删除引擎对备份之后的磁带进行去重操作，但是混合型重复数据删除技术则让引擎在已经备份好几盘磁带之后就开始工作，此时备份工作可能尚未结束，这样就可以加速去重的过程。

　　昆腾公司提供了一种所谓自适应重复数据删除技术，引擎开始工作之初是处于在线去重模式，即随着数据的写入，去重计算同时完成。但是一旦遇到数据到达的速率远高于去重速率的时候，引擎就会分配对应的缓存，并且随着速率差异的增加而增大缓存，然后，引擎使用后处理模式对缓存中的数据进行去重处理。

　　“全局重复数据删除指的是在多种不同类型的数据和子系统之间进行全局的去重操作。”ESG的Whitehouse说道。目前每个重复数据删除设备都维护各自的去重元数据索引。全局重复数据删除系统则要求一种可以共享和兼容这些不同厂商索引的方法。（具体见下文的“全局重复数据删除”一节）

　　全局重复数据删除   

　　全局重复数据删除一般情况下能达到更高的去重比率，同时允许你来衡量输入和输出。看是针对源端还是针对目的端，全局重复数据删除过程是不同的，Whitehouse解释到。

　　目的端重复数据删除：将多个其他节点的去重索引复制到一个大容量的整合的中央索引库中，从而可以保证全局范围内只有单一的文件或者数据段被传输。

　　源端重复数据删除：从远程办公室/分部收集去重索引，然后执行去重过程，从而生成一个中央整合的索引库。   

　　存储容量优化

　　重复数据删除引擎通过检查冗余数据中的唯一重复特征来判断是否可以将冗余的部分存储为一个符号链接，从而降低数据对存储空间的需求。这个过程是一个及其消耗CPU资源的过程。

　　符号链接的指针被存放在索引中保存。每当重复数据删除引擎遇到一个特征数据段的时候，它就会检查索引中所存储的这些符号指针来查看是否当前的特征段与对应的条目相吻合。引擎所发现和归纳的特征数据段越多，那么它所能够降低的存储空间需求也就越多，虽然索引本身有时可能会变的很大。

　　重复数据删除引擎检查数据时对其分段的粒度越细，那么它所能发现的冗余数据段的几率就会越高，相应的所能够节约出来的存储容量也就越多。“真正的重复数据删除引擎会作用在Sub-File级别，在多份文件或者同一个文件的多次修改版本之间来检查冗余数据块。” GlassHouse Technologies公司数据保护部门的副经理W. Curtis Preston这样解释到。单一实例存储是重复数据删除技术的一种，它就是作用在文件级别。

　　重复数据删除技术现有观点

　　由于重复数据删除技术还算是一种比较新的技术，基于不同的技术和算法，并且产品更新升级也比较频繁，对于不同形态的技术，存在多种不同的观点。

　　在线重复数据删除相对后处理重复数据删除模式要好一些。“如果你发现你的备份速度并没有因此而拖慢，并且备份窗口依然充足，那么选择哪种方式重要么？我认为无关紧要。” Preston说道。

　　Magnum Semiconductor的Wunder说他的在线重复数据删除系统工作良好。“即使会导致延迟，那么也是非常小的，再说，我们是直接将数据写入磁盘，所以延迟几乎不会影响什么。”

　　比较现实一些的答案其实取决于你的数据特性、你的重复数据删除系统部署形态以及你所选择的设备的处理能力。“单一节点设备的在线去重模式也就这样了，” Preston说道。如果没有全局重复数据删除技术的支持，在系统中引入再多的设备节点也无济于事。当今，Preston说道，“后处理模式的重复数据删除架构好像占了一些上风，但是很可能长不了。年底，Diligent（现在已经被IBM收购），Data Domain以及其他一些厂商会相继退出全局重复数据删除产品。到那时我们就会看到一场真正的角逐了。”

　　在后处理模式的重复数据删除系统中，只有当所有的备份都完成之后，引擎才开始工作。而且引擎会等待某盘指定的磁带或者虚拟磁带不再被使用之后就会对它进行去重处理，而不是等待所有磁带都不被使用之后，Preston说道。而且去重引擎可以在备份过程中的第一盘磁带写满之后就去处理它，“当处理完之后，第二盘磁带很有可能就会写满，此时接着再处理第二盘，以此类推。”他说。

　　不少厂商都声明了它们产品的去重比率。但是真要计算出你的数据的去重比率，并非易事。厂商所公布的去重比率其实是在一种特定条件下的高人为控制因素介入之后的结果。“有厂商竟然夸张的声称可以达到400:1的比率，这种情况基本上你永远无法遇到。” Whitehouse说。所能达到的最高比率取决于你的数据类型和属性，而且还取决于在一段时间之内它们到底有多少变化。

　　“假设你对一个由500个文件组成的数据集进行去重操作，为了便于备份，每个文件1GB大小。” EMC的CTO Dan Codd说道，“第二天，有一个文件变化了，你对其进行了去重操作，这样的话，备份相当于只备份了这个变化的文件，那么此时的去重比率是多少呢？你可以说它是500:1”。

　　Grey Healthcare 公司是一家位于纽约的卫生保健行业的广告代理机构，它们需要处理很多媒体文件，有些甚至超过了2GB。公司将它们的数据存储在一个容量为13TB的EqualLogic（现在被Dell收购）的ISCSI盘阵中，而且定时将它们备份到飞康的VTL中，并最终迁移到LTO-2磁带中保存。利用飞康提供的后处理模式的重复数据删除技术，Grey Healthcare可以将4周内的数据从175TB降低到2TB。“我们算了一下，比率可以达到75:1” 其IT总监Chris Watkis说道。

　　Watkis发现，对于同一个重复数据删除过程，其结果随着你计算式所使用的时间段的不同而不同。“结果可能是40:1甚至20:1，总体来讲，我们将175TB的数据成功缩减到了2TB。”他说。

　　一些私有的技术往往可以带来较好的结果。不管是私有的还是公开的算法，它们最终都可以归于两种模式：基于Hash值的模式，即对数据段生成指针；内容识别模式，直接匹配实际内容。

　　“Hash值以及内容识别这两种技术其实早就被人所共知了，”Diligent的CTO Neville Yates说道，“不管哪种方式，其实性能都差不多。”

　　Yates说Diligent使用了一种不同的方法。他解释到，它们的算法只利用一小部分可以常驻内存的数据，即使PB级别容量的去重处理也是如此，通过这种方法，就可以提高性能。Magnum Semiconductor的Wunder是Diligent的客户，它们的系统经常要处理一些大概22KB大小的文件，Diligent的算法面对这种情况时表现出了良好的能力。他认为在这种结果下，对算法进行深挖和改进似乎已经没有必要了。

　　“我们与来自Data Domain以及ExaGrid的工程师探讨过它们的算法。但是我们真的是对它们对数据的存储形态以及如何对老数据进行恢复更加感兴趣。” 来自Adventist Health Network的IT总监Michael Aubry说。

　　飞康采用了公开算法，比如SHA-1或者MD5。飞康的技术副经理John Lallier说到：“对于去重这项工作来讲，使用私有的算法可能获得更好一些的性能，但是使用公开算法所获得性能已经足够了。”  就算是最好的算法，它依然要依赖于底层传输链路，因为链路可能导致传输过程中的数据错位或者丢位，他补充道。

　　随着重复数据删除系统容量的增长，Hash冲突导致的数据错位的比率将会增加。统计上讲，这确实是毋庸置疑的结论，但是也不要因此而大惊小怪、因噎废食。对于那些使用Hash来辨认冗余数据的重复数据删除系统来讲，这种担心确实是必要的，但是对于那些不使用Hash的去重厂商产品，或者除了使用Hash之外还使用了第二种附加算法的产品来讲，这种担心就多余了。

　　GlassHouse Technologies的Preston做了一项统计，并将结果发布到了他的博客中。他发现在95EB（95000PB/95000000TB）的数据中，产生Hash冲突的几率为0.00000000000001110223024625156540423631668090820313%。而在数据恢复的过程中需要读取到冲突Block的几率就更低了。

　　“如果你的数据量小于95EB，那么发生Hash冲突的几率将会在小数点后50位开外。”Preston说，“我想我算出的结果是没问题的。”

下一篇文章　部署重复数据删除的技巧