我原来觉得，做增量备份，无非就是每次计算这个文件的每个段（比如每段20M大小）的数字签名，如果每个段的数字签名与前次计算结果完全相同，那么就不必上传这个段了，只需上传被修改的段即可。当然被修改之后，后面的段就不会对齐了，那么就要沿着每个字节都要计算从它开始的20M大小的数据的数字签名（计算强度很高），直到发现相同的数字签名为止，才可以省去上传这个段。经过计算发现前后两段不一致以后，就使用流技术定位后开始改写，一直改写到两个大文件又有相同的段为止。如果相同的段之后还有不同的段，那么重复前面的过程。这种方法看上去不难，但是如果自己实现的话，整个过程会非常繁琐。
-------------------------------------------------------------------------------------------------
现在又听说了另一种说法，此种方法充分利用了数学的成果，而不是我使用的简单逻辑的办法：
http://librsync.sourcefrog.net/
意思就是，第一次上传以后的文件永远不变，每次本地文件被修改后，计算它与第一次文件之间的差异即可。这样文件不管被修改多少次，永远都是一个原始文件和一个增量文件，配合起来就能生成新文件。而上传的时候，永远只上传那个增量文件即可。
原理看上去很简单，但是那个差异是怎么计算出来的，这点十分关键。因为不仅仅要记录新数据，而且要记录新数据相对于原文件的位置和要替换的内容。无论原文件怎么改，都直接计算新文件相对于第一次原始文件的数字签名（而不是第三次新文件相对于第二次新文件的数字签名）。如果原文件不停的改变，要记录的信息就慢慢的多了，上传效率也就变低了。但仍不失为一个简单好用的增量备份方案。
如果要将增量备份的潜力挖到底，那么每次上传以后，发一条指令，将上一次上传的原始文件与增量文件合并，重新计算它的数字签名，那么下次增量上传就可以以上一次的文件为基础，而不是很早以前的第一次上传的文件为基础。
-------------------------------------------------------------------------------------------------
问题的难点在于：这个数字签名，不仅要表示文件的唯一性，而且要表明文件里所有数据的位置和内容，这样才能方便下一次在没有源文件的情况下进行差异计算。