guid linux 识别的分区表_GUID分区表(GPT)修复实战

本帖最后由 pig_10 于 2009-8-4 13:40 编辑

我有一个用两个1.5TB硬盘组成的RAID卷，由于MBR分区表无法支持超过2TB的单个分区，所以我使用了GUID分区表

某日，我用diskpart命令的时候选错了硬盘，然后毫不犹豫的执行了clean指令，很好，灰飞烟灭，将近3TB的数据跟我886了

心里那个悔阿，但是木已成舟，或者说生米已煮成熟饭，又能如何？考虑恢复吧。

祭出Winhex，磁盘编辑！一看，傻眼了，diskpart的clean命令整整抹掉了1M的数据，想直接找回分区表是不大可能了

然后就是各种Try and Error，n种方案失败之后终于成功了

我首先想到的是能否手动编辑GPT分区表？答案是：可以，但是比MBR分区表复杂，而且GPT主索引区还保存了分区清单部分的CRC32值

我把这个卷重新初始化，然后建立了一个非常小的分区(10M)，以确保数据不会被覆盖，之后手动编辑这个分区的起始LBA与结束LBA，保存，好，Winhex能够认出这个分区了，但是Windows打死也不认，就是那10M，这怎么办？Winhex的NTFS遍历(Traverse)又没有办法拿来大规模的用，会丢文件，完整性(Integrity)也无法保障，看起来微软把自己用的分区表存在了别的什么地方，不过后来我知道了在哪里。

后来想到的是能否再建立一个同等，或者更大的分区，然后用Winhex的扇区复制将原硬盘的扇区复制到新硬盘？正好我还有两块1.5T的硬盘，我赶紧把数据倒到我淘汰下来的三块共计1TB的硬盘之中(谢天谢地这两块硬盘里的数据只有800G)，然后用这两块硬盘再建立一个3TB的Raid卷。

但这时候Winhex就傻X了，指定扇区数量无法超过2TB！行不通，又失败了

我接下来继续查了些资料，发现Windows在处理GPT的时候必须留出128M的Microsoft Reserved(微软预留)，我猜测Windows采用的分区表是否在这里？后来的实验证明我对了，但是我直到最后也不知道这里的结构，我实在是没精力去分析128M的数据，这个分区是没有文件系统(File System)的，想找数据无异于大海捞针。

查资料的途中发现事实上Diskpart之中create partition命令可以通过offset=x与size=y来精确指定分区偏移量与其大小(单位是MB)，我如获至宝，赶紧打开Winhex根据我找到的分区的起始偏移量与大小创建了一个参数与原丢失分区完全一样的分区，这样我的系统之中就存在了一个Windows可识别的参数又与原来相同的分区，然后我尝试性的将这个卷的0扇区开始的128M数据(包括了微软预留分区)全部复制到丢失分区的硬盘上(用Winhex的Clone Disk(克隆磁盘)的指定扇区功能)，重起，找到了！分区回来了！我赶紧分配了一个盘符，运行chkdsk，谢天谢地，没有数据丢失(其实也说不准，可能文件系统没有任何改动但是在各种实验中有数据被覆盖)，剩下的就是往回倒数据了，oh yeah！这个实验的成功也说明了Windows承认的分区表确实存在于那128M的微软预留分区之中！

这次的经验表明了GPT分区表也并不是那么难以触及，只要有思路，仍然可以进行数据恢复以及分区恢复，不过比较麻烦的是因为没有像编辑MBR的PTEDIT32那样的工具所以很多事情只能手工来。

以下是几点经验：

1、Windows存储在内存之中的分区与文件系统的挂载(Mount)信息(不要惊讶，Windows也有这说法，这不是Linux的专利)，除非在Diskmgmt.msc或者diskpart或者其他分区软件的操作之下，不然不会改变，即使你在Winhex等磁盘编辑器中做出了相应的修改也不会被Windows所识别，只有重起并且让Windows重新扫描所有分区才会识别并挂在你手动恢复了的(如果成功了)分区，MBR亦然，并不仅限于GPT

2、各种可能性都要尝试一下，不过注意备份，不过这个备份并不是要让你备份全部数据，而是只要备份被修改部分前后数兆就可以

3、慎用Diskpart，里面的破坏性指令是不需要确认的

4、……想不出来了

主要资料来源：

GPT详细资料：

http://en.wikipedia.org/wiki/GUID_Partition_Table

没有中文，不过将就看吧

Diskpart命令列表：

http://technet.microsoft.com/zh-cn/library/cc766465(WS.10).aspx