在数据恢复中，清晰的思路是至关重要的。你要用你清晰的思路，配合技术，来分析，来破开前人给你造成的障碍。
上周，国内著名台式机品牌的售后老总给我打电话，说碰上一个棘手的活，想让我帮个忙。这个老总我们合作过很多次了，很熟，我说没问题，让你下面人找我吧。5分钟电话过来了，情况是这样的。他们的技术人员去给人家维护电脑，用的是什么什么恢复光盘，估计是直接ghost了以个系统上去，ghost一遍后，无法启动。技术人员说那我给你ghost一个我们最新的vista吧，ghost后无法启动。客户这时候说，你行不行啊，别把我d盘的数据库给我弄丢了，那可是我好几年的客户资料啊。技术人员说没事，不可能。咱们接到其他机器上先备份出来。结果接到其他机器上一看，以前的c，d，e，f，4个区，就剩下了一个c啦，里面有2个乱码文件夹。客户说当时心都凉啦，直接找经理对话，你不给我恢复了，我告你，我让你见报。客户也是很nb的，哈哈。
由于是那个技术人员闯的祸，他全程陪同客户来恢复，而且恢复的钱由他来出。第一站，中关村XXXX维修中心，用软件扫描，不行，开价300。第二站，中关村XXXX做数据恢复的，这回还真是大牌子打着数据恢复的牌子的，扫描，没戏，diskgen重写分区表，找回一个f区，里面都是cs和祖玛。
diskgen，以前到diskman，这软件可没少给高手找麻烦。不是说大海兄编的软件不好，而是很多250根本不会用，直接就扫描写分区表。10%运气好的，数据能恢复，90%就有可能再次破坏分区表。如果您是用diskgen的告诉，我可没说您，我说是那些不会用的250。不幸的是，我碰到的就是改了又改的分区表。
2家都不行啦，客户有点急，这回直接找老总了，我是XXXXXX，你们工程师把我数据弄丢了，那是我们公司多少年的客户资料，要是你们找不回来，XXXXXXXXXXXXXXXXXXXXXXXXXX
等我拿到硬盘，看到分区表的时候，我都快哭啦，那叫一个乱。80G的硬盘，前面一个20G的c，ntfs的，中间一个30G的未分配，最后一个26G，fat32的分区，通过里面的游戏确定可能是f盘。先了解情况吧，我听了上面那些情况，脑袋嗡嗡的。问问客户以前的分区情况吧，您以前分了几个区啊，都什么格式的啊。客户很肯定的回答，4个区，都是平分的，ntfs格式的。我说是20，20，20这样分下来的吗，客户说，对。这是第一个陷阱。
我一个看，最后一个区不是fat32的吗，客户怎么说ntfs的？难道格式都不对，cs和祖玛还能看到？c到是ntfs的，也是20g。慢慢来吧。先看看运气如何，用finaldata扫一下硬盘，按照XXXX柱的1头1扇来扫，运气好能有些信息。3分钟，什么都没有。接着用diskedit把0扇的55aa换成55ab，排除diskgen后写的0扇的干扰。在用finaldata扫描XXXX柱的1头1扇，3分钟。出来2个fat32的分区，一个在30g，一个在50g。客户不是说都是ntfs的吗，而且是20，20，20分的啊。算了，先看看怎么回事吧。直接跳到30g那个fat32的分区头，一看，正常啊，回跳63扇，有一个扩展分区表。先写一个0扇看看。把0扇整个备份到1扇，然后把除了分区表项的头16个字节，全清0，手动写一个第2行16个字节，指向30g的那个扩展分表。
重新加载硬盘，my god，更乱啦。c还是20g的ntfs，后面10g未分配，再后面20g的fat32，再后面有个5g的servers，最后是26g的fat32。这都什么啊，具体看一下，原来是分区表后面也是错了，把一键还原的隐藏分区显示出来了。再改，保留分区表项区域中64自己的头16字节，这是c，改第2个16个字节，直接指向后面的30g位置的fat32，不指向分区表，而直接指向信息表。再算到50g开头的fat32，直接写到第3个16字节中进行指向。卸载，重新加载硬盘。
乱的好点了，现在是有一个c，20g，ntfs，里面有2个乱的目录，后面跟了一个10g的未分配，30g开始是一个20g的fat32，分区正常，文件正常，是一些工作文档什么的。50g开始是一个26g的fat32，里面是cs和祖玛。打电话核实，从文件确定这是以前的e和f分区。我说不是ntfs的吗，怎么我做出来的是fat32，而且肯定是fat32的。客户说应该是ntfs的啊，要不就是fat32的。但是，重要的数据库在d区的一个XXXX文件夹中。我心想，这不是和没说一样吗。第一个陷阱也跳过去了。这时候客户已经喝了30分钟咖啡啦。
那客户说的20，20，20分的也明显不对，后面的分区都对了，说明前面的c，d加起来肯定是30G。而且不一定是ntfs的。finaldata扫描不到d头，我怀疑是因为后来的这个20g的ntfs超过了以前c的大小，干扰了finaldata，这没有办法，只能凭经验了。很多人喜欢把c分8或者10G，我猜10g的可能性大一些，因为，这样后面就是20，20，26的情况了。分10G系统一般会写在20482875，这个数很熟，跳到20482875一看，果然，有一个扩展分区表，残留的信息也表示以前的d是fat32的，并且大小是20g。再往后跳63看看，空的，再跳6看看，空的。用finaldata直接定位到20482875，扫描，没有任何结果。估计大概d也就是这了。
再回到0扇，手动16进制写分区表，先把第2、3个分区表项挪到第3、4上，留出2的位置写d区。直接把d区写成fat32，直接指向20482875+63的位置，分区大小，反向算出，写入。这么做是为了让软件能有一个fat32的信息可言，然后在按照你的想法来扫描。不然软件根本就不认为这是一个分区，什么finaldata，easyrecovery根本不管用。
写好0扇后，不能重新加载，直接用getdataback强行按照fat32来扫描指定的d，40分钟，数据全部恢复，目录也有。
整个数据恢复大概2小时，不过这种情况太乱了，是非常少见的情况。