SQLite3数据库恢复⽅法总结
最近做SQLite 3数据库的恢复，了⽐较多相关⽅⾯的论⽂，在这⾥记录⼀下。
⼀、基于SQLite ⽂件系统的恢复
  上⼀篇⽂章中，记录了SQLite 3的⽂件结构，⾥⾯提到了⼀点数据库中记录单元删除前后的底层变化，但是不太详细。在这⾥详细讲⼀下。
  SQLite 3数据库的删除与PC的⽂件系统数据的删除有些类似，就是删除的过程中，原始数据是不会被删除的，它会存留在底层，直到新的数据存储时覆盖掉。另外，在删除的过程中，当删除的记录单元较多时，数据库会整合⾃由块，这样⼀个⾃由块就可能包含多个记录单元，当某个页的数据都被删除时，给页就会形成空闲页。总的来说，记录单元被删除后形成的⾃由块就可能有这⼏种情况：
  1、⼀个⾃由块包含⼀个记录单元的⼀部分（部分覆盖的情况）
  2、⼀个⾃由块包含⼀个完整的记录单元
  3、⼀个⾃由块包含多个完整的记录单元
truncate的数据如何恢复另外，就是形成空闲页的情况。
  ⽅法⼀
  基于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++；在⼀个⾃由块恢复完成后，针对⾃由块的第三中情况，要判断⾃由块是否结束？存储恢复信息：继续相似类型匹配。
  恢复阶段和⽅法⼀类型，就不在赘述。
  这种⽅法是陈飞在他的论⽂《智能移动终端应⽤数据取证技术研究》中提出来的。后⾯我将尝试以这种⽅法恢复⾃由块，想来应该⽐⽅法⼀好很多。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。