让人耳目一新的增量备份方式（使用数字签名）

我原来以为，作增量备份，无非就是每次计算这个文件的每一个段（好比每段20M大小）的数字签名，若是每一个段的数字签名与前次计算结果彻底相同，那么就没必要上传这个段了，只需上传被修改的段便可。固然被修改以后，后面的段就不会对齐了，那么就要沿着每一个字节都要计算从它开始的20M大小的数据的数字签名（计算强度很高），直到发现相同的数字签名为止，才能够省去上传这个段。通过计算发现先后两段不一致之后，就使用流技术定位后开始改写，一直改写到两个大文件又有相同的段为止。若是相同的段以后还有不一样的段，那么重复前面的过程。这种方法看上去不难，可是若是本身实现的话，整个过程会很是繁琐。

-------------------------------------------------------------------------------------------------

如今又据说了另外一种说法，此种方法充分利用了数学的成果，而不是我使用的简单逻辑的办法：
http://librsync.sourcefrog.net/
意思就是，第一次上传之后的文件永远不变，每次本地文件被修改后，计算它与第一次文件之间的差别便可。这样文件无论被修改多少次，永远都是一个原始文件和一个增量文件，配合起来就能生成新文件。而上传的时候，永远只上传那个增量文件便可。
原理看上去很简单，可是那个差别是怎么计算出来的，这点十分关键。由于不单单要记录新数据，并且要记录新数据相对于原文件的位置和要替换的内容。不管原文件怎么改，都直接计算新文件相对于第一次原始文件的数字签名（而不是第三次新文件相对于第二次新文件的数字签名）。若是原文件不停的改变，要记录的信息就慢慢的多了，上传效率也就变低了。但仍不失为一个简单好用的增量备份方案。

若是要将增量备份的潜力挖到底，那么每次上传之后，发一条指令，将上一次上传的原始文件与增量文件合并，从新计算它的数字签名，那么下次增量上传就能够以上一次的文件为基础，而不是很早之前的第一次上传的文件为基础。

-------------------------------------------------------------------------------------------------

问题的难点在于：这个数字签名，不只要表示文件的惟一性，并且要代表文件里全部数据的位置和内容，这样才能方便下一次在没有源文件的状况下进行差别计算。