XFS 搭配 GPT 分割表的檔案系統損毀救援說明

一個檔案系統錯誤之後的救援情況分享

鳥哥的學生需要測試 storage 主機的 I/O 性能，瘋狂測試的結果，導致 xfs 檔案系統的結構出了點錯誤！因為結構的錯誤，因此某些檔案無法刪除，新的檔案也無法建立。同時，因為這個 storage 是實際給學生使用於專題 VM 運作的系統，因此也無法隨便將這個檔案系統卸載來處置。

最終在昨晚通知所有 VM 的管理員將各自的 VM 關閉，之後關閉掉 NFS 服務，接下來 umount 該裝置，使用 xfs_repair 來處理這個檔案系統。指令一邊整理我們一邊擔心...因為出現太多的 inode 錯誤的訊息！而 inode 是影響到整個檔案內容的重點！鳥哥最怕的是....檔名錯亂的問題...那就慘了～

最後修理完畢，然後 mount 上目錄樹之後....慘了！果然最重要的目錄名稱錯亂了！有一個主目錄死掉，然後該目錄下所有的次目錄 (還好，都是目錄，次目錄底下才有檔案) 都變成隨機的檔名....好佳在的是，在次目錄底下的檔名倒是沒有出錯！還活的好好的～那些檔案就是用來作為 VM 磁碟的檔名啊～

最終調出資料庫，找到每個 image filename 對應的使用者，而使用者就是目錄名稱，因此將上百個檔案陸陸續續的搬回原本應該要存在的目錄底下，終於將檔案系統救了回來。

以為處理完畢後，將整個 storage 系統重新開機....差點哭出來～原本檔案系統所在的磁碟裝置為 /dev/sdb, /dev/sdb1 ，重新開機完畢後，要命了！變成僅有 /dev/sdb ，那個 /dev/sdb1 遺失了....鳥哥跟學生面面相覷...裡面有數百個檔案，等於是數百個 VM 的硬碟全部消失不見了....

後來想到，我們的磁碟是使用 GPT 格式的，這種 partition 格式會在整顆磁碟的前、後各留一份分割表，因此我們單純使用 gdisk /dev/sdb 這個指令之後，gdisk 就發現到最前面分割表遺失，但是最後面分割表是存在的，所以建議我們要將分割表復原，一按下復原，嘿嘿！ /dev/sdb1 就回復了！趕緊儲存分割表，重新掛載測試，確定檔案系統恢復正常！好個加在！

這次處理的心得是：

• 如果在檔案系統還能使用的情況下，要卸載處理 xfs_repair 前，最好可以使用 ls -ilR /some/dir > somefilename.txt 之類的指令，將所有的檔案系統內的檔案組織先留檔，這樣在未來如果有出現 inode 錯誤導致的檔名遺失，就可以透過這個檔名來了解到未知檔案的可能檔名為何，也就不需要還得要查閱資料庫等其他附屬功能了(也還好我們有這東西～)！
• 未來不論磁碟大小，建議還是使用 GPT 作為分割表類型，不但可以避免主要磁碟分割 4 個的限制，若磁碟最前端的 partition table 出問題，還能夠有個 backup 可以參考救援！