本帖最後由 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