Data De-duplication 技术简介

EMC中国研究院 杨子夜

本文对重复数据删除(data de-duplication )技术作简要的介绍。由于笔者非此方面的专家，故有些方面的阐述难免以偏概全，望各位读者海涵。此外，文中所述仅表明个人观点，而不代表公司观点。

正文

什么是data De-duplication？

维基百科上这么解释重复数据删除(简称DEDUPE)[1]：一种可粗粒度去除冗余数据的特殊数据压缩技术。开宗名义的解释了DEDUPE和数据压缩之间的联系。通俗的讲，数据压缩[2]一般通过字符串(string) 或者比特(Bit)级的一些操作来去除冗余数据，常用的无损数据压缩算法有lempel_Ziv [3], Huffman coding[4], rangeencoding[5]等。例如Gzip[6]使用的DEFLATE[7]算法就基于lempel和huffman算法。然而DEDUPE判断数据冗余的粒度较大，一般是文件级别，或者块(block)级别的匹配，希望达到性能和去重复比例的一个平衡。

我们为何需要DEDUPE？根据Gartner[8]提供的报告，对大企业来讲，数据快速增长是数据中心最大的挑战。显而易见，爆炸式的数据增长会消耗巨大的存储空间，迫使数据提供商去购买更多的存储，然而却未必能赶上数据的增长速度。这里有几个相关问题值得考虑： 产生的数据是不是都被生产系统循环使用？如果不是，是不是可以把这些数据放到廉价的存储系统中？怎么让数据备份消耗的存储更低？ 怎么让备份的时间更快？数据备份后，能保存的时间有多久(物理介质原因)？备份后的数据的能不能正常取出？

在现实情况中，和生产系统连接的备份系统一般每隔一段时间会对生产系统做一次主备份，意即备份生产系统中的所有内容。然后在两次主备份之间有很多增量式(minor)备份。生产系统和备份系统的工作时间是一般来讲是互斥的。当然如果生产系统需要持续运行，那么备份系统则需要工作在生产系统相对闲的时间。 也就是说，备份系统的工作时间是有限制的，一般这个时间被称为备份窗口。需要被备份的数据必须在这个时间全部被迁移到备份系统，这就对备份系统的吞吐率(Throughput)有需求。那么怎么提高吞吐率呢？纯粹更换硬件是一种方法。例如，在10年前，主流的备份系统用的是磁带(tape)。对于磁带来讲，局限在于吞吐率不够以及只支持顺序读写。于是现在的备份系统的后端存储开始采用磁盘，以提高吞吐率方面的需求。此外我们是不是可以从数据来源或者从软件的角度考虑问题？用于备份的数据，或者多次备份过来的数据可能是相似的，如果我们不是机械化地去备份那些数据，而是有意识地识别其中冗余的数据，然后对相同的数据，只备份一份或者少数几份(出于数据可靠性方面的考虑)。那么这样的方法不仅仅减少了备份系统所需要的容量，甚至可以减少备份时候对带宽的使用。举个现实的例子，邮件系统中有很多群发邮件，内容相同，特别是附件。试问邮件备份系统中需要对用户的相同附件都保存一份吗？答案显然是没必要。从邮件系统的例子中，我们可以看出DEDUPE的作用，不过邮件系统所用的DEDUPE比较简单，主要针对相同的文件。

聪明的看官一定会发现文件级别的DEDUPE，也就是单实例存储(Single instance store)，有很大的局限性。最浅显的问题就是： 如果文件内容略微有些不同，那怎么怎样进行数据去重复呢？换句话说文件级别的粒度太大；而粒度太小就变成了常用数据压缩技术，也不太合适。所以我们需要的是块级别的，比如大小平均在8K左右（经验值）。这样的数据去重复，兼顾空间（数据去重复比率）和时间（备份性能）达到一个最佳的平衡点。

综上所述，DEDUPE一般用于备份系统中（或者二级存储，对于其他系统先不作讨论）。所以衡量一个应用DEDUPE的备份系统是不是优秀，有以下几个特征(可能有遗漏，请各位指正)：

数据去重复比。数据去重复比例越大，就会减少备份系统存储方面的压力。同时在二次或者多次数据备份的时候，减少网络带宽的使用。吞吐率。使用了相关数据去重复技术后，备份时间是否显著缩短。根据前面所说的，对于诸多生产系统来讲，备份窗口时间有限。如果数据吞吐率不高，即使再高的数据压缩比，也很难被采用。数据的可靠性。这个是指经过DEDUPE处理后的数据，在进行灾难恢复时，数据能否被正常恢复，因为除重后的数据已经不是原来的数据。这一点往往被外行人所忽略，但是一个好的数据备份厂商，一定会重视这个问题。试想如果通过去重复后，数据在某些情况下，不能被正常恢复，那又何必应用DEDUPE做数据备份。备份过程的安全性。 这一点现在被考虑的比较少，如果对于企业内部或者私有云，基本上默认在数据备份过程中不会出现一些安全方面的问题，例如数据窃取。但是一旦DEDUPE技术作为一个由三方提供的服务，则这个问题需要被重视。

 

DEDUPE的分类

上一部分简单介绍了DEDUPE技术，这一部分我们稍微谈一下DEDUPE的主流分类，使得读者能够更好的理解DEDUPE。

分类一

第一种根据应用DEDUPE的位置：源端(Source)或者目标端(target)。源端指备份数据的来源；目标端是指备份系统。在这里，我们稍微提一下怎么判断一块数据是否被备份系统存储。一般来讲，每一块数据都会保留一个“指纹”(fingerprint),为了保证指纹的唯一性，可以使用一些比较好的Hash算法[9]。所谓源端去重复，是指判断数据重复的工作在源端进行。比如，用户在上传某数据的时候，可以进行以下的步骤：

(a)   使用单向函数(某些hash算法)生成需要上传的数据的指纹。

(b)  把指纹发送到备份系统，等待确认。

(c)   位于目标端的备份系统，判断是否存在相似的数据。给源端返回数据是否存在的信息。

(d)  源端接收到信息后，决定是否上传数据。

 源端数据去重复的好处显而易见，如果数据已经被备份过了，则不需要数据再传送给备份系统。当然源端数据去重复，性能未必一定高，在确认数据交换的时候，需要传送大量的指纹，也是不小的开销。此外如果源端是不可信的，可能将引起某些安全问题。弊病的原因在于用户能感知某些文件在备份系统中的存在性，这样可进行某种安全攻击。试想以下应用场景：假设一个备份系统中存有很多用户的工资信息，每个用户都有一个工资单，工资单的模板都是一样。那么某些用户可以去探测其他人的工资信息。假设工资单中只含有以下信息<用户姓名，工号，工资>。如果一个用户A知道用户B的姓名，工号，要猜测对方的工资，可以在源端生成相关文件，然后上传给备份系统，一旦发现生成的文件没有被上传，就可以确定B的工资。当然这种攻击是非常耗时的，但是在理论上完全存在这种可能性。

和源端应用DEDUPE相对应的是在目标端应用DEDUPE，在这种情况下，源端只要上传把数据上传给位于目标端的备份系统即可，源端甚至感受不到DEDUPE技术的存在。所有的数据都会通过网络或者其他传输机制交给备份系统。备份系统对接收到的数据做统一地应用DEDUPE。相比源端DEDUPE，虽然传输数据的网络带宽占据较大，但是也有很多好处：(a) 客户端完全透明，去除了安全方面的隐患，也不用对客户端做维护工作，例如版本升级(b)去重复数据都在目标端，使得管理集中，可进行全局的去重复，可称为一个相对独立的系统。

分类二

第二种分类基于数据在备份系统中进行DEDUPE的时间发生点，有离线(post-process) 和在线(inline)两种。 离线(后续)DEDUPE是这样的，在用户数据上传的过程中，数据去重复并不会发生，而是直接写到存储设备上。当用户数据上传完全结束后，再进行相关的数据去重复。这样的方式，可以理解成某些有很多胃的食草动物（例如牛），先把食物吃到胃中，然后在某个时间点再进行“反刍”，以完全消化食物。在食草动物的例子中，可以看到有反刍能力的动物一般具备很多胃。对应到备份系统中，就是至少需要有两个存储设备。试想如下的场景：用户的备份数据是1PB， 那么备份系统需要的存储至少要大于1PB。其中第一个存储设备大小为1PB 用于存储用户上传的数据，另外一个存储设备大小为X（X是指应用DEDUPE后的数据大小，在0和1PB之间）。这样的去重复手段，读者一定会看出其中的问题：为了确保DEDUPE能正常进行，最差的情况下有100%的额外存储资源消耗。

为了解决这个问题，在线DEDUPE技术应运而生。所谓在线，就是在用户数据通过网络上传到备份系统的时候，数据去重复就会发生。用户的数据，会被DEDUPE子系统分成不同的部分，每个部分视为一个chunk（块或者切片），每个chunk会被计算一个相应的指纹，然后通过指纹去查找相关chunk存在的可能性，一旦存在，这个chunk就不会被写入真实的存储设备。在这一过程中，对CPU和内存的消耗是非常高的。虽然存储某个数据，需要先查找块是否存在，但是如果能找到，则避免了大量外部存储写操作，避免了过多的存储(磁盘I/O)的操作时间，反而提高了备份的速度。另外由于多次备份的内容存在很大的相似性，则带来的好处是非常可观的，这样看来，在线DEDUPE同时压榨CPU，内存，网络，存储I/O等模块，使得整个系统的资源能被更好的利用，和离线DEDUPE相比是一个不小的进步。

当然DEDUPE还有很多其他分类，例如根据目标端的备份系统可分为：单机或者分布式模式。在这里，将不一一赘述。

 

深入了解DEDUPE

在这一部分，我们将略微深入地讨论一下DEDUPE，以帮助读者了解DEDUPE 是怎么应用到备份系统中的，使得备份吞吐率，去重复比率，数据的完整和安全性都能得到满足。

数据切片算法

开始的时候，我们就谈到DEDUPE只是一种“块”(chunk)级别的特殊数据压缩技术。一般来讲，数据切成chunk有两种分类： 定长(fixedsize) 和变长(variable size)。 所谓定长就是把一个接收到的数据流或者文件按照相同的大小切分，每个chunk都有一个独立的“指纹”。从实现角度来讲，定长文件的切片实现和管理比较简单，但是数据去重复的比率比较低。这个也是容易理解的，因为每个chunk在文件中都有固定的便宜。但是在最坏情况下，如果一个文件在文件开始新增加或者减少一个字符，将导致所有chunk的“指纹”发生变化。最差结果是： 备份两个仅差一个字符的文件，导致重复数据删除率等于零。这个显然是不可接受的。为此变长chunk技术应运而生，不是简单地根据文件偏移来划分chunk，而是根据“anchor”(某个标记)来对数据分片。由于找的是特殊的标记，而不是数据的偏移，则能完美的解决定长chunk中由于数据偏移略有变化而导致的低数据去重复比率。例如图1(来自[10]，PPT第22页)生动的给出了同一文件修改了小部分内容，定长和变长分片算法的优劣。其中Venti[11] 系统采用的定长数据分片，插入新数据后，影响后面所有的chunk。LBFS[12] 和datadomain的DDFS[13]使用的是变长数据划分，由于划分chunk的依据是“Anchor”，即使插入了某些数据，也不影响后面大多数的chunk。

Figure 1 定长和变长数据切片比较

谈到这边，读者要问变长切片中的“Anchor”究竟是怎么确定的？一般使用基于内容的分片(content defined chunking，简称CDC)算法，使用滑动窗口技术(Sliding window algorithm)，窗口的大小一般是12-48个字节[12,14,15]。根据经验值，分片大小在8K bytes对数据去重复是比较有效的。最常用的数据切片算法是利用rabin hash[15] 计算滑动窗口的指纹进行切片。如果活得的指纹满足预先设定的条件，则这个窗口的位置是一个切分点，两个切分点之间的数据被认为是一个切片。Rabinhash有很多开源实现，比较早的rabin hash的应用在MITPdos研究组的Pastwatch[16] project中,有相应的源码下载 。这里附上一般CDC算法的伪代码，如图2 [17]所示。举个实际的例子，假设滑动窗口的大小是48bytes，预先定义好的magic_value 是0x12，chunk_mask的值是0x1fff。当窗口每移动一个字节的时候，把rabinhash应用在大小48bytes的窗口后，得到一个值，然后取最低13位(实际是和chunk_mask做&操作)。如果得到的值是预先一定好的magic_value(0x12), 就说明我们找到了一个切分点。随着窗口在整个文件中滑动，我们能找到所有的切分点，这样所有的切片就被确定了。在给出的例子中，根据概率的期望值， 切片大小应该是8192 bytes。

Figure 2 常用CDC算法[17]

当然rabin hash也是有局限性的，理想情况下， 使用rabin hash产生的切片大小（按照数学期望）是比较均匀，但是现实往往不是这样。所以会导致以下的问题：(1)很多小切片，导致管理数据分片的代价变大 (一般使用树状索引)。(2) 数据切片太大，影响数据去重复的效果。为了解决这两个问题，很多研究人员提出了一些改进的方法，例如在NEC的一篇文章[14]中, 作者提出了双峰算法，其主要思想是:进行二次切片。对于一些大的数据切片，可能采取一些继续分片操作(Breaking-apart),对于大的切片可能采取切片合并操作(chunk amalgamation)。此外HP 实验室也提供了一个框架来分析一些常用的CDC算法，并且提出了一个新的CDC算法： TTTD[18](TwoThresholds, Two Divisors Algorithm)。 所谓Two Thresholds： 就是规定切片的大小只能在上下界限之间， 所谓Two divisors： 是指使用rabin hash 来确定分界的时候，有两个值可选，一个值称为主divisor，另外一个作为backup divisor。当使用主divisor时，如果找不到分界点， 则backupdivisor的条件能不能被满足。具体的伪代码请见HP所写技术报告的附录。此外在NEC美国实验室发表的文章[17]中还提出了一种fingerdiff的新切片算法，大家如有兴趣可阅读原文。

高效重复数据删除

数据切片算法是DEDUPE技术中比较重要的一部分，但只依赖于数据切片算法是远远不够的。前面我们提到衡量一个数据去重复有两个重要指标：数据去重复率和吞吐率。很多研究表明[13,19,20,21,22]数据切片如果越小，去重复率越大，但是会导致低吞吐率；反之，数据切片越大，去重复率降低，但是吞吐率会提高，如图3所示。为此要求应用DEDUPE的系统必须选择合适的切片大小，以在去重复率和吞吐率之间达到一个动态平衡。

Figure 3 chunk大小对数据去重复比率和吞吐率的影响[23]

在线 DEDUPE中，怎样在数据切片后，根据数据切片的指纹高效率地在数据切片管理系统中查询或者建立新的数据切片索引是提高吞吐率的关键所在。一般来讲，数据是从网络过来的，然后指纹的计算会利用大量的CPU， 指纹的查询会利用大量的内存和进行过多的磁盘操作。为此整个在线去重复系统就是高效利用网络，CPU，内存和磁盘这4个组件。

例如DDFS[13] 采用了以下技术来提高数据的吞吐率:(1) Summary vector：对于分片的指纹查询使用引入Bloom Filter[24]技术，Bloom Filter的好处在于没有falsenegative. 凡是在bloom Filter中找不到的，就直接就说明这个指纹不存在。(2)SISL(streaming informed segment layout)：这个假设的前提对于一些数据流，有可能备份过一次后，会出现一些非常相似的数据流。 那么对于某个数据流，应该作为一个整体来考虑，和一个数据流相关的分片和相关的指纹，应该尽量集中放置在某几个容器(container)中。在DDFS中，每个container大小定长，存储了数据切片和相关的指纹(metadata)。(3)  LPC(locality preserved cache)： 把数据切片的指纹和container维护一个mapping关系。这样的好处在于，如果备份的数据流是有空间局部性的，那么把一个数据指纹加载到内存（segmentcache）中的时候，和这个数据指纹位于同一个container中的指纹会一起被load到内存中，那么后续数据切片的指纹就能直接在内存中找到，避免了不必要的外部I/O操作。此外segment cache使用LRU算法管理container。总的来说在DDFS中，切片(segment)的查找使用以下的步骤：

首先在segment cache中检测segment是否已经存在。如果能找到，说明相关索引已经存在。如果不存在，则跳到2.在summary vector中使用Bloom Filter检测segment是否存在。如果不存在，说明是一个new segment，就把这个segment写入当前的container中。如果存在, 则跳到3.在segment的索引中，查找segment所对应的container ID。 如果在index中能知道，说明是一个重复的segment。这个时候，我们需要把这个container中的segment相关的信息加载到segment cache中。当然如果这个时候segment cache已经满了，需要使用LRU 算法把某些container 从cache中去除，并且同步到外部存储；如果在找不到，说明这是一个新的segment，需要把这个segment相关的信息写入当然的container中。

客观来讲，DDFS所使用的策略，是非常有效的，使得整个数据重复删除的效率非常高，为此在工业界，datadomain的产品在目前来讲领先于其他同类产品，占据了很大的市场份额。当然这不是说DDFS的技术已然是无可挑剔，从学术的角度来讲，还是有很多优化的事情可做。例如，在2011年的ATC会议上，有篇文章[22]对切片指纹的查找提出了进一步的优化，此篇论文中提到DDFS这样的系统只从locality方面来考虑高效的切片指纹查找，但是仅仅依靠locality是不够。对于全备份(full backup )来讲，所备份的数据流是具有很高的locality。但是对于那些增量式备份(incremental backup)的数据流，locality则比较差，为此必须考虑另外一个因素similarity(“相似性”)。所用的策略是比较简单。就是把很多紧密相关的小文件分为一组，放入一个切片(segment)中，或者把一些大文件划分成更多独立的小切片(segment)来挖掘相似性。同时利用locality和similarity，作者提出了一个新的系统SiLo，能够更好的去重复，并且在占据内存较小的情况下，达到比较高的吞吐率，而其他系统会消耗更多的内存。

当然除了在软件上优化指纹的查找，很多研究人员也在硬件方面考虑问题。我们知道，计算指纹(一般使用hash函数，比如Sha1)需要消耗大量的CPU。为此引入其他物理器件(比如GPU)[25,26]，使得CPU的计算能力能被释放，做更有意义的工作。

 数据可靠性

在过多目光放在DEDUPE的去重复率和吞吐率方面的时候，我们需要考虑备份数据的可恢复性以及完整性。也就说，希望备份数据的invulnerability不能被破坏。那么到底从哪些方面保证数据的可靠性？笔者认为，对一个去重复系统而言来讲，当数据从客户端通过传输介质进入数据去重复系统后，必须考虑系统中的每一个模块。也就是说在设计整个DEDUPE系统的时候，必须考虑任何一个部件在运行过程存在错误的可能。

首当其冲需要考虑的是外部存储的可靠性。现在备份的数据最终会放到磁盘(取代了以前的磁带)。所以一个简单的问题，就是在备份过程中磁盘设备坏了，该如何处理？为了解决这个问题，RAID[27]技术中被引入。一般常在数据去重复系统中的应用有RAID0，RAID5或者RAID 6。当然RAID技术也有软件和硬件之分。硬件RAID部署起来虽然比较容易，但是也不是百分之百能保证数据不出错。磁盘也一样，写入磁盘的数据未必一定正确，当然发生的概率非常低。为此就需要去重复系统，通过软件的方法去验证一些数据的完整性。例如对于一些数据结构，采用内嵌的checksum(校验值)来保证数据的完整性。

第二个可能需要考虑的是内存的可靠性，在服务器上，我们知道所带的内存比较高级一些，都携带ECC(Error correcting code)功能。对于deduplication系统而言，如果内存有这样的机制，就可以去监控这些内存条。如果在同一个区域ECC 错误的出现频率变高了，超过了某个阈值，似乎就可以判断这块内存条在一定时间内有损坏的可能，需要及时进行替换。再发散一下，就是对系统中任何的硬件，都需要有监控，以防止意外发生，例如CPU和风扇的温度等。

第三个问题，可能比较难解决了。假设在进行去重复的过程中，整个系统崩溃了，还能保证数据的完整性吗？对于那些还在CPU或者内存中的数据，但是并没有被刷入外部存储的数据，我们能不能进行相关的track。发生这样的事情，最完美的结局是：系统能恢复正常，还没刷入外部存储的数据（已经经过了指纹处理），能被正常的写入外部存储。直观的想，这似乎是不可能的，但是细想一下，似乎还有一定的解决方案。先把思维发散到数据库中。我们知道支持OLTP的数据库，对事物的支持有很强的要求，比如那些没被正常commit的事务(transaction)需要被回滚。在数据库中为了满足这一需求，引入了WAL(write ahead log)机制。也就任何写磁盘操作，必须先写log。那么在数据去重复系统中，是不是也可以引入WAL 机制呢？的确可以，但是纯粹使用引入WAL机制，似乎不能满足数据去重复系统高吞吐率的要求，那么怎么办？为此数据去重复系统向一些高端的存储系统学习，引入了NVRAM[29]，那么log可以先写入NVRAM。于是当系统崩溃的时候，一些数据就可以从NVRAM中恢复出来，这在一定程度上缓解了系统崩溃所导致的数据丢失问题。但是NVRAM也不是万能的，系统依然在某些情况下，会处于一个不能完全恢复数据的状态，当然这样的概率是比较低的。

从数据invulnerability的角度来讲，开发一个好的数据去重复系统还是比较难的。总的来讲，必须把数据可失性的问题在软件和硬件等方面进行全面考虑，才能尽可能的避免数据在去重复或者恢复过程中的丢失。

自由讨论(open discussion)

DEDUPE技术的萌芽到兴起时间不长，但是随着大数据的增长，需求也是爆炸式增长。前面我们所讲的是当前DEDUPE技术在数据备份系统中的应用，市场上销售的DEDUPE系统基本都是一体化的。所谓一体化系统，是指数据去重复系统以容量大小进行销售，也就是说用户会购买一个BOX(包含了所有软硬件)。但是大家不禁要问，随着容量的增长，单个BOX是否还能满足要求？

就笔者而言，答案是否定的。数据去重复系统的可扩展性(scalability)在以后会成为一个比较热门的话题，只是现在处于探索阶段。目前我们可以进一步压榨多核(many/multi core)或者GPU的能力，但是总有一天，优化的效果会变得越来越不显著。为此我们必须转向分布式系统，或者把数据去重复和云联系起来。例如昆腾公司最近发布了一款虚拟插件产品DXi  V1000[30]，开始把数据重复删除和虚拟化以及云相结合。此外在2011年的FAST会议上，EMC 发表了一篇分布式数据去重复的文章[31]，具体内容大家可以阅读原文。DEDUPE在数据备份相关中的应用，还有很长的路要走，在这里笔者只是抛砖引玉：

如上文所言，构建分布式的数据去重复系统。和云结合，有很多种玩法：对云存储服务商而言，可以在云存储背后使用DEDUPE 技术，来降低自己的成本。云服务代理商，可以结合DEDUPE技术和一些廉价的云存储服务，来提供更加可靠的存储服务。在这里，DEDUPE技术也是为了降低成本。DEDUPE供应厂商，不再单纯的卖B OX给用户，而是提供更加一体化的服务。当前用户的BOX容量满了，需要替换，购买容量更大的BOX，对于一些小企业来讲，持续的替换是一个比较大的IT开销。为此如果数据去重复厂商，提供额外的云服务，允许在用户BOX容量满的情况下，把去重复后的数据放到远端，当然这个从性能而言会有下降，但是确实满足了小型企业的一个需求。比如，如果用户买了1T的去重复系统，附加一个10T的云数据去除系统，会不会有相应的市场呢？

DEDUPE除了在数据备份系统(主要指secondarystorage)中的应用，在其他方面，例如主存储(primary storage)，文件系统，虚拟化甚至内存中。在这里我们可以稍微简单介绍一下：

主存储中的数据去重复。在2012年的FAST会议上，NetApp公司发了一篇文章[32]，希望DEDUPE在主存储上的应用能同时在存储空间节省和I/O延迟之间做一个平衡。另外在2010年ACM TOS 的杂志上也发表了一篇在主存储上进行I/O deduplication的文章[33]。文件系统的数据去重复。比如ZFS[34], liveDFS [35], SDFS[36],DEDE[37],。 其中ZFS在文件系统管理中支持了数据去重复功能； liveDFS也差不多，可在虚拟机内进行DEDUPE；SDFS可在一些文件系统之下进行DEDUPE，不过它是一个用户级数据去重复文件系统；DEDE工作在VMware的VMFS层可以在线的对用户虚拟机磁盘进行重复数据删除。内存中的去重复(数据共享)。这个大家应该不会陌生，一般都是在page(页)级别进行内存共享。例如在操作系统中进程之间贡献内存，而使用的copy-on-write 机制，以及同一个host中的不同虚拟机之间通过copy-on-write 机制共享内存。另外还有一些更复杂内存数据去重复机制，例如[38,39]。

总结

本文首先对数据重复删除技术(DEDUPE) 做了简要的介绍，接着探讨了DEDUPE在数据备份中的一些核心技术，最后笔者还列出了DEDUPE在其他方面的一些应用。

原帖地址：http://qing.blog.sina.com.cn/2294942122/88ca09aa33000uyo.html