網友分享篇

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

最近更新時間: 2017/02/21

因為瘋狂測試磁碟性能,同時因為磁碟有大量其他工作進行,導致 XFS 檔案系統損毀。損毀之後的救援方式就像底下這樣囉!

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

鳥哥的學生需要測試 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 可以參考救援!
其他連結
環境工程模式篇
鳥園討論區
鳥哥舊站

今日 人數統計
昨日 人數統計
本月 人數統計
上月 人數統計