最近做SQLite 3數據庫的恢復，找了比較多相關方面的論文，在這里記錄一下。
一、基於SQLite 文件系統的恢復
上一篇文章中，記錄了SQLite 3的文件結構，里面提到了一點數據庫中記錄單元刪除前后的底層變化，但是不太詳細。在這里詳細講一下。
SQLite 3數據庫的刪除與PC的文件系統數據的刪除有些類似，就是刪除的過程中，原始數據是不會被刪除的，它會存留在底層，直到新的數據存儲時覆蓋掉。另外，在刪除的過程中，當刪除的記錄單元較多時，數據庫會整合自由塊，這樣一個自由塊就可能包含多個記錄單元，當某個頁的數據都被刪除時，給頁就會形成空閑頁。總的來說，記錄單元被刪除后形成的自由塊就可能有這幾種情況：
1、一個自由塊包含一個記錄單元的一部分（部分覆蓋的情況）
2、一個自由塊包含一個完整的記錄單元
3、一個自由塊包含多個完整的記錄單元
另外，就是形成空閑頁的情況。
方法一
基於SQLite 3數據庫文件系統結構的恢復步驟通常是：
准備階段：讀取數據庫頭，得到數據庫的頁大小和編碼方式。
讀取系統表，得到要恢復目標表的根頁。
從根頁開始，遞歸遍歷所有的葉子頁。
遍歷所有的葉子頁，找到該表所有的自由塊。
判斷階段：針對上面提到的自由塊情形2，判斷階段的目的就是確定是否一個自由塊是一個完整的記錄單元。判斷的方法是：推算：n值+type區域的字節數+data區域的字節數是否和自由塊記錄的大小相同。（n的初始值為4，也就是兩個字節的下一個自由塊偏移和連個字節的本自由塊大小，n最大為28）。當判斷結果相同時，就進入下一個階段，恢復數據。
在這一階段中，關鍵的地方是要分析清楚記錄單元變成自由塊前后，原始記錄單元的type區域有沒有被覆蓋。在這個問題上,白晉國、孫紅勝、胡澤明《一種基於SQLite3文件格式的刪除數據恢復方法》一文中做了詳細分析，他們說，n的值范圍在3-6之間，因此刪除前后type區域是否被覆蓋的情況就分三種情況：
1、單元大小+rowID+headersize=3個字節時，這種情況顯示是數據庫數據較少，這時n=4，type區域被覆蓋一個字節，但是在追蹤底層的時候，我發現，每個記錄單元的type區域第一個字節的值始終為0x00，也就是對應的數據區域的長度為0，因此覆蓋一個字節影響不大，但是計算type的字節數顯示要從2開始。
2、單元大小+rowID+headersize=4個字節時，這時n=4，type區域沒有被覆蓋，並且計算整個自由塊的時候，正好可以領type從1開始
3、第三種情況就是當數據庫數據較多時，單元大小+rowID+headersize>4個字節時,這時n值就要大於4了，並且type區域同樣沒有被覆蓋且從1開始
關於上述三點，只是記錄了結論，沒有具體的分析原因，可以看一下那篇論文，就很清楚了。
恢復階段：恢復階段要做的工作就是根據type區域的記錄將data區域的每個元素進行編碼，這一步比較麻煩的是type區域記錄了后面相對應data域的長度和類型。
這種方式只能是針對上述的第二種情況，恢復的結果不是很理想。我做的實驗結果是：
以上是幾個表的恢復情況，可以看到，當表的記錄量較小、刪除數據較少的時候，恢復的情況還可以；但是當表的記錄量增加、刪除數據量較多時，符合第二種情況的自由塊就沒有那么多了，因此恢復的情況就不理想。
鑒於上述情況，繼續查閱SQLite恢復方面的論文，發現有一篇論文中提到了一種方法：相似類型匹配估算方法。
方法二 相似類型匹配估算方法
這種方法本質上也是基於SQLite數據庫的文件結構，准備階段和方法一一樣，也是要遍歷所有的葉子頁，以便找到所有的自由塊，除此之外還需要得到正常的記錄單元的type區域類型。但是在判斷階段，不再是針對一個單一的自由塊，而是和存在的記錄單元進行比較，從這里我們也能明白該方法名字的來源：比較自由塊的type類型和記錄單元的type類型是否相似。
判斷階段：從自由塊第n個字節開始（n值在方法一種也做了討論），相似類型匹配成功？恢復階段：n++；在一個自由塊恢復完成后，針對自由塊的第三中情況，要判斷自由塊是否結束？存儲恢復信息：繼續相似類型匹配。
恢復階段和方法一類型，就不在贅述。
這種方法是陳飛在他的論文《智能移動終端應用數據取證技術研究》中提出來的。后面我將嘗試以這種方法恢復自由塊，想來應該比方法一好很多。