讓人耳目一新的增量備份方式（使用數字簽名）

我原來以爲，作增量備份，無非就是每次計算這個文件的每一個段（好比每段20M大小）的數字簽名，若是每一個段的數字簽名與前次計算結果徹底相同，那麼就沒必要上傳這個段了，只需上傳被修改的段便可。固然被修改以後，後面的段就不會對齊了，那麼就要沿着每一個字節都要計算從它開始的20M大小的數據的數字簽名（計算強度很高），直到發現相同的數字簽名爲止，才能夠省去上傳這個段。通過計算髮現先後兩段不一致之後，就使用流技術定位後開始改寫，一直改寫到兩個大文件又有相同的段爲止。若是相同的段以後還有不一樣的段，那麼重複前面的過程。這種方法看上去不難，可是若是本身實現的話，整個過程會很是繁瑣。

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

如今又據說了另外一種說法，此種方法充分利用了數學的成果，而不是我使用的簡單邏輯的辦法：
http://librsync.sourcefrog.net/
意思就是，第一次上傳之後的文件永遠不變，每次本地文件被修改後，計算它與第一次文件之間的差別便可。這樣文件無論被修改多少次，永遠都是一個原始文件和一個增量文件，配合起來就能生成新文件。而上傳的時候，永遠只上傳那個增量文件便可。
原理看上去很簡單，可是那個差別是怎麼計算出來的，這點十分關鍵。由於不單單要記錄新數據，並且要記錄新數據相對於原文件的位置和要替換的內容。不管原文件怎麼改，都直接計算新文件相對於第一次原始文件的數字簽名（而不是第三次新文件相對於第二次新文件的數字簽名）。若是原文件不停的改變，要記錄的信息就慢慢的多了，上傳效率也就變低了。但仍不失爲一個簡單好用的增量備份方案。

若是要將增量備份的潛力挖到底，那麼每次上傳之後，發一條指令，將上一次上傳的原始文件與增量文件合併，從新計算它的數字簽名，那麼下次增量上傳就能夠以上一次的文件爲基礎，而不是很早之前的第一次上傳的文件爲基礎。

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

問題的難點在於：這個數字簽名，不只要表示文件的惟一性，並且要代表文件裏全部數據的位置和內容，這樣才能方便下一次在沒有源文件的狀況下進行差別計算。