Data Deduplication：http://en.wikipedia.org/wiki/Data_deduplication
数据备份或传输的时候，为了降低存储或带宽开销，做一下压缩是很经常的，这是用CPU的cycle换取存储或带宽。
压缩算法已经有很多的，不再赘述。data deduplication是另一种意义上的压缩：通过文件之间或文件块之间的冗余，来进行去重（deduplication）。
考虑qq邮箱的超大邮件，会有用户经历过，当上传一个超大文件的时候，经过本地计算以后，页面提示用户说这个文件在服务器上面已经有了，这样就可以不用重新上传了。这就是data deduplication的一个典型例子。
文件级的deduplication是最常见的，典型的应用场景例子有：
1，qq邮箱的附件、超大附件；
2，QQ旋风、迅雷的离线下载功能；
3，乱七八糟的各种网盘；
4，软件新版本的分发，如CernVM-FS（cvmfs用的是content-addressable storage，非常相近的一个概念）。
这些场景的相同之处在于，软件的不同版本之间（4）、不同用户上传的附件之间（1、3）、不同用户要下载的文件（2、3）之间，都有很多文件会是重复的。我们很容易猜测，（1）、（2）、（3）的文件中，一些热门资源（如喜闻乐见的视频文件、Windows安装镜像等）会有大量用户来使用，通过data deduplication，可以极大减少存储开销和网络通信开销。
这里其实也可以有个思考，譬如迅雷的离线下载功能、或者115的网盘，如果只是上传下载一些热门资源，那么您号称10GB的空间，可能都是和别人共享的，hoho。
还有一个应用场景，对于virtual server来说，不同virtual server会有很多系统文件是一样的（譬如6个virtual server都装的是centos），那么对这些文件进行deduplication，可以减少运行virtual server的那台机器的存储开销。
Data deduplication的做法很简单，计算文件（块）的指纹，然后对比是否有重复，如果有，则只做标记，而不再存储一个拷贝。
根据操作的时间来区分，这个过程可以是在线的，也可以是离线的，即有in-line process和post process的区别；
根据操作的位置来区分，可以过程可以发生在数据产生处，也可以发生在目标存储设备处，即有source deduplication和target deduplication的区别。
计算文件的指纹，自然而言的要用cryptographic hash function，如SHA-1。虽然hash肯定会有碰撞，但是碰撞发生的概率比其他故障概率要低的太多，所以基本上可以忽略了。
实现上，为了优化，可以用两个hash，一个weak hash，计算速度会比较快，但碰撞概率也增大；而strong hash就可以用cryptographic hash了，虽然理论上有碰撞，但是既然暂时没有地球人能找到，那就权当没有了。
对于比较保守的人来说，用了strong hash如SHA-1以后，即使SHA-1指纹是一样的，他们还是害怕他们遇见了SHA-1的碰撞，两个文件并不相同，那么他们大可以把两个文件bit by bit地做个对比，这样他们就放心了。在我看来，保守并不一定是坏事，不过他们用错地方了，与其害怕SHA-1会碰撞，那还不如直接上SHA-512，然后如果还碰上了，没有人会怪你，反而密码学界的人们还要感谢你找到了碰撞。
更新：最近Dropbox被人骂了，参见http://internet.solidot.org/article.pl?sid=11/05/16/064217
从描述中，很容易猜到Dropbox对用户的文件做了data deduplication。而对于Dropbox只存一个文件拷贝的指控，我们很容易理解为什么Dropbox要这么做：
1，Dropbox主要的成本就是上传文件到Amazon的带宽、以及存储文件在Amazon的存储空间（下载文件是不可避免的开销，不做考虑），那么，为了降低存储的开销，和上传文件的带宽开销，对用户的文件进行deduplication是很诱人的。
2，在上传的时候，先在本地计算一个文件指纹（反正是在用户本地么，不用消耗他们的CPU cycle），然后发送到服务器，服务器检查是不是已经有这个文件了，如果有的话，做个标记就行了，不用真的上传。这样，带宽和硬盘都省出来了。
Data deduplication与加密是矛盾的。而为了让用户放心（没人希望自己的文件明文保存在云端），Dropbox声称文件是经过加密的。那么，这个加密过程通常要放到服务器端来做，而且Dropbox一定要知道加密密钥。这是因为：加密是一种pseudo-random permutation，针对加密以后的文件进行deduplication是没有意义的，因为即使是完全相同的文件，使用不同密钥加密以后内容也将大不相同（或者说，完全不同）。
为了保持文件加密的同时仍然可以进行data deduplication，Dropbox只能这样做：
1，存在Amazon那里的文件是加密过的，但是Dropbox有解密密钥；
2，A文件上传时，会计算指纹，然后送到服务器对比，如果和现有的B文件指纹重复，就不上传了；
3，文件加密可以发生在客户端（这和上面链接中对Dropbox的指控不符），但Dropbox得有加密（也就是解密）密钥，所以并没区别；
4，当A文件被下载时，服务器知道A文件并没有真的存储，而是指向B了，就得拿到B的加密版本，然后自行解密，解密以后作为A返回。
因此，我们也就不难理解为什么会有针对Dropbox的加密密钥管理以及加密过程的质疑了。对密钥管理的质疑是肯定的，Dropbox肯定有密钥，否则就无法deduplication了；对加密过程的质疑并不太站得住脚，因为加密过程可以放到客户端（所谓client backup deduplication，参见wikiData Duplication条目中相应的entry），大不了同时计算一个hash然后送到服务器就是了，不过既然服务器有密钥，那么发生在哪儿也无所谓了，不可能更不安全了。