NTFS文件系统。由于客户不清楚这个分区是什么文件系统，因此只有先按NTFS文件系统尝试。是NTFS文件系统就一定有$MFT这个原文件（当然前提是$MFT没被损坏），于是去搜索这个原文件的文件名的十六进制值24004D0046005400，这次从50G位置开始向后搜索，搜索到若干个24004D0046005400后，终于在155698795扇区找到了一个$MFT的文件记录。
接下来要确认这个扇区是$MFT还是$MFTMirr的起始扇区。由于$MFTMirr只是前四个MFT项的备份，因此只要确定一下155698795扇区之后的若干个连续扇区中的MFT项是不是超过四个就能基本确定155698795扇区是$MFT的起始扇区还是$MFTMirr的起始扇区了。于是搜索NTFS文件记录的特征字节值46494C45，结果在155698795扇区后的部分连续扇区中找到找到了二三十个MFT项，可以确定155698795扇区就是$MFT的起始扇区了，没再往下搜索了。在这些MFT项中随便找了几个文件名给客户看，确定了那就是原E分区的文件。 找到了$MFT的起始扇区，接下来的工作便是确定E分区的起始扇区号了。而E分区的起始扇区号只有通过$MFT的起始簇号和簇大小扇区数去反推。
首先计算簇大小。分别查看80属性18～2F字节处的8个字节的值（属性结束VCN）和28～2F字节值（属性内容分配大小）再用“属性内容分配大小/（属性结束VCN+1）/512”得到簇大小扇区数为8（其实NTFS文件系统的簇大小一般都是8，这里只是为了确认一下）。这里对属性结束VCN和属性内容分配大小这两个值没做记录，只记得计
算出来的簇大小扇区数了。
接下来需要根据$MFT的80属性中记录的$MFT起始簇号和从簇大小扇区数去反推E分区的DBR位置了。查看80属性的第一个运行，得出起始簇号为3754787（这个与常见的$MTF起始簇号786432还不一样）。由于NTFS文件系统的0号簇是从DBR开始的，因此用3754787*8得到E分区的$MFT距DBR的扇区总数为30038296（3754787*8＝30038296），再用$MFT所在扇区号155698795减去30038296得出E分区的DBR扇区应在125660499（155698795－30038296＝125660499）。
跳转到125660499扇区，这个扇区有数据，但显然不是原来E分区的DBR，看来只有在这个扇区把写一个DBR。为以防万一，先把125660499扇区做一个备份。
首先拷贝一个正常的NTFS的DBR到125660499扇区，接下来要修改的几个参数有：簇大小（前面已计算为8）、隐藏扇区数（即该分区前的扇区数，就为125660499），分区大小扇区数，$MFT起始簇号（为3754787），$MFTMirr起始扇区号。现在还差两个参数：分区大小扇区数和$MFTMirr起始扇区号不知道。
先查$MFTMirr起始扇区号。$MFTMirr的文件记录项是$MFT的后面一个MFT记录项，跳转到155698797扇区查看该扇区中的文件记录项，从文件名属性（30属性）可看到它确是$MFTMirr的文件记录项，查看80属性运行列表，得出它的起始簇为23979812。
然后确定分区大小值。根据客户所说E分区是最后一个分区，于是
只需将后面的全部扇区全分配给E分区就行了，在这里我也没全部分配，从目录浏览器中看到有一个未分区空间起始扇区为625137282，与硬盘总扇区数相差不过数千扇区，于是便以它为E分区结束位置。则E分区大小扇区数取625137281－125660499＝499476782。
跳转到125660499扇区，用NTFS的引导扇区模板修改以上参数（分区大小扇区数为499476781，一会儿在分区表中分区大小填写为499476782）后保存，DBR就写好了。
最后要做的就是写分区表了。分区表的三个主要参数分别为分区类型（NTFS为07），分区起始扇区号和分区大小扇区数。经客户同意，D分区不要了，只要把C分区和原来的E分区的分区表写出来就好了。 确定C分区和原来的E分区的起始扇区和分区大小就可以了。C分区起始已有了的，为63，大小为原E分区起始扇区125660499－63＝125660436。E分区起始即为125660499，大小为499476782（因为DBR的备份位于分区的最后一个扇区，这个要比DBR中描述的多1）。得到这些参数后，把两个分区表写上就行了。
跳转到63扇区，修改C分区DBR中的分区大小值为125660435（C分区也是NTFS格式，因此这个值比分区表中描述的少1）。 最后，跳转到125660499扇区，将该扇区中的DBR数据拷贝下来写到625137281扇区做一个DBR备份。
修复到此就结束了。在Winhex关闭硬盘，重新打开硬盘，分别打开两个分区，第一个分区就是原来的系统了，经客户确认，第二个分区就是原来的E分区的数据。
经客户重启计算机，确定数据完全正确，至此本次恢复完毕。由于远程操作太慢，此次恢复竟然用了6小时左右时间。
顺便抛出一下问题大小讨论一下：一般情况下，误GHOST后造成只有一个分区的情况下是不会损坏后两分区分的DBR的，而且客户的系统分区有45G左右，一个XP系统怎么也不会有45G吧，也就是说应该不会覆盖掉后两个分区的DBR，这两个分区的DBR怎么会损坏呢？这个问题到现在我都还没弄明白。
Ntfs手动修复删除文件
对于数据恢复来说，虽然文件删除后所有的数据运行都能够在残留的MFT中找到，但是数据运行的个数越少即文件碎片越少或者没有碎片，文件被覆盖的可能性就越小，数据恢复的概率也就越高。以下是手工恢复NTFS卷中误删除文件的过程。
1. 需要恢复的文件
NTFS卷中一个文件被删除时，其MFT并没有被删除，前面已经介绍过，这里以恢复一个NTFS卷中一删除的文件为例，假设在用户的NTFS卷D盘中有一个名为photo的目录，该目录下有一个名为“penquan.jpg”的文件，如图5-1所示。假设用户不小心将此文件删除。
图5-1 NTFS卷中将被删除的文件
2. 找到要恢复文件的MFT
首先通过WinHex选择文件所在的逻辑磁盘将其打开，如图5-2所示。
图5-2 选择磁盘分区
打开磁盘的分区后找到该分区的MFT，如图5-3所示。