SQLite3数据库恢复方法总结

最近做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++；在一个自由块恢复完成后，针对自由块的第三中情况，要判断自由块是否结束？存储恢复信息：继续相似类型匹配。

　　恢复阶段和方法一类型，就不在赘述。

　　这种方法是陈飞在他的论文《智能移动终端应用数据取证技术研究》中提出来的。后面我将尝试以这种方法恢复自由块，想来应该比方法一好很多。