| 前阶段，遇到个客户，客户ESX4.0的服务器，文件系统VMFS3,删除了一个96G左右的VMDK，客户要求，重新启动。第一次遇到vmfs的，网上资料少的可怜，但是还好，官方的一些资料以及开源的vmfstools给予了本次恢复莫大的帮助。 首先看看客户盘中现存的vmdk的情况，vmdk的碎片量非常大，几个vmdk都看了一下碎片后，碎片总量在800-10000之间，因此对flat的vmdk做碎片基本是不可能了，只能从文件系统存储角度考虑。 刚开始在网上查找资料，国内国外的统统看了一下，国内的基本上就是广告，没有实质性的东西，国外的止步于.FDC.SF（暂且可以理解为文件索引的一级索引）的分析（后面会讲到）。 记得夜里加班的时候，我给我同事写过四句话，这四句话其实可以概括了，所有的文件系统类型的反删除恢复的基本操作步骤，当然，如果你对本文件系统相当了解的情况下，也可以直接跳过去，分享下四句话： 1. 文件系统如何读文件？ 2. 删除文件的时候发生了什么，是否会干掉所有pointer（类似fat那样）？ 3. 哪些系统元数据是与数据指向有关的？（与编程一样，都是靠pointer来实现寻址） 4. 制作一个工具，逆向这些步骤，你就可以恢复出来了。 ） 因此，通过上诉四句话，我们基本上可以了解了从一个未知的文件系统中恢复数据的基本逻辑步骤，因此作为第一步，我们需要一个测试环境，能够让我们随意的创建和删除文件用，因此我安装了一个esx的虚拟机，作为分析，逐步解开vmfs的删除操作之谜 这个是我测试用的vmfs文件系统，通过不断反复几十次的增，删，改，查的方式，我们发现两个箭头中所指向的文件应该是恢复的重点。.fdc.sf(=file descriptor cluster.system file英文全称，这样好记一点，主要负责存储文件元数据以及一级索引)，pbc.sf = pointer block cluster.system file，主要存储2级索引。下面是我们测试的结果： 当我们删文件的时候发生了什么？ 1. 文件的目录项（包含名称以及record id等信息）会被直接清空掉（搞不懂为何要用这种这么低效的办法，对于文件数量庞大的存储，vmfs绝对是噩梦，还好只是少量的vmdk） 2. 一级索引会被直接清空。因此小文件是无法通过索引恢复的。 那么一级和二级索引在文件删除时发生了什么？ 一级索引，只有256个槽位，每个索引都是u_int32,因此一共可以存放256个索引，我们测试了一下，在默认情况下，一个vmfs的block的大小是1m的情况下，一级索引能够承载的最大文件就是256M，如果文件一旦大于这个量一级索引就不会直接在指向数据区，而是改到二级索引位置由二级索引完成数据指向，从而达到扩展索引槽位的目的。当发现这个信息的时候，我们就激动了，因为vmdk基本不可能那么小，都是上百G，因此所有的二级索引都会被保留下来，通过对PBC中的二级索引进行提取即可完成所有碎片的搜集和恢复工作。 目前的局限性： 1. 目前只做了vmfs3的分析，vmfs5还有待我们后续深入，基本原理应该是差不多的。 2. 目前没有涉及到vmdk的快照的恢复，因此我们还会继续深入下去。 3. 本人的知识能力所限，可能有错误的地方，还请海涵 （ozone） |
