Linux fack 檔案系統修復命令

【簡介】

fsck命令被用於檢查並且試圖修復檔案系統中的錯誤。當檔案系統發生錯誤四化，可用fsck指令嘗試加以修復。

【選項】
必要引數
 -a 非互交模式，自動修復
 -c 檢查是否存在有損壞的區塊。
 -C<反敘述器> fsck.ext3命令會把全部的執行過程，都交由其逆向敘述，便於監控程式
 -d 詳細顯示命令執行過程
 -f 強制進行檢查
 -F 檢查檔案系統之前，先清理該儲存裝置塊區內的資料
 -l<損壞區塊檔案> 把檔案中所列出的損壞區塊，加入標記
 -L<損壞區塊檔案> 清除所有損壞標誌，重新標記
 -n 非互動模式,把欲檢查的檔案系統設成唯讀
 -P<數位>  設定fsck.ext2命令所能處理的inode大小為多少
 -r 互動模式
 -R 忽略目錄
 -s 順序檢查
 -S 效果和指定“-s”引數類似
 -t  顯示fsck.ext2命令的時序資訊。
 -v 顯示詳細的處理過程
 -y 關閉互動模式
選擇引數
 -b<分割區第一個磁區地址>  指定分割區的第一個磁區的起始地址/Super Block
 -B<區塊大小>  設定該分割區每個區塊的大小
 -I設定欲檢查的檔案系統，其inode緩衝區的區塊數目
 -V顯示版本資訊

【適用】
1) 檔案系統：ext2 ext3 reiserfs xfs等
2) 範圍：提示檔案系統需要FSCK時，未執行或FSCK執行完成

【症狀】
1) 無法MOUNT分割區;
2) 大量檔案、目錄丟失，根目錄下生成/LOST+FOUND資料夾，裡面有大量#XXXXXX類的檔案和目錄;
3) fsck很快報錯完成;
4) fsck執行時，有大量提示，如修改節點、清0節點等操作

【應急】
1，如遇提示fsck時，要小心，如果可能，請儘快斷開系統，umount所有分割區
2，必須執行fsck時，先做準備工作，方法一：可實現用dd命令所有涉及到的分割區輸出到另外的儲存體上，命令大致所示：dd if=/dev/sda1 of=/dev/sdb1
3，如上面幾種方式均因條件等原因無法執行，但又必須執行時，可小心觀察fsck的執行提示(關掉 -a) 如果發現有提示節點錯誤需更正或清0，節點描述檔案大小不正確等資訊，應停止執行fsck
【備註】
1，如果可能，先對故障區做dd全映象備份後在執行，或者以唯讀方式自行，並仔細看修復過程，如果提示大量inode錯誤，需要重建樹、或大小不對等就不可再繼續下去了
2，檔案系統常見錯誤，並且問題通暢原因是電源失敗，硬體失敗，或者操作失誤，例如沒有正常關閉系統
3，fsck只能執行於為mount的檔案系統，不要用於已mount的檔案系統
4，修復完成後，會出現提示“FILE SYSTEM WAS MODIFIED”。這時重新啟動系統

【參考範例】

手動fsck修復

　　fsck不僅可以對檔案系統進行掃描，還能修正檔案系統的一些問題。值得注意的是fsck 掃描檔案系統時一定要在單使用者模式、修復模式或把裝置umount後進行。
　　警告：如果掃描執行中的系統，會造成系統檔案損壞。
　　檔案系統掃描工具有 fsck，fsck.ext2，fsck.jfs，fsck.msdos，fsck.vfat，fsck.ext3，fsck.reiserfs（reiserfsck）。其中fsck 預設支援檔案系統ext2，如果想支援ext3檔案系統的掃描，應該加-j 引數。最好是根據不同的檔案系統來呼叫不同的掃描工具，比如ext3的檔案系統使用fsck.ext3，ext2檔案系統使用fsck.etx2等。

/dev/sdb1是ext3的檔案系統，只介紹fsck.ext3

範例1： 檢測磁碟
[root@linux test]# fsck.ext3 /dev/fd0
範例2： 檢測磁碟並顯示時序資訊
[root@linux test]# fsck.ext3 -ft /dev/fd0

檢視fsck報錯的紀錄檔
[root@server ~]# ls -l /var/log/fsck/
total 8
-rw-r----- 1 root adm 190 2011-06-09 10:03 checkfs
-rw-r----- 1 root adm 192 2011-06-09 10:03 checkroot
這兩個檔案中會出現fsck的報錯資訊。
[root@server ~]# more /var/log/fsck/checkfs
[root@server ~]# more /var/log/fsck/checkroot

檢視當前的執行級別：
fsck.ext3掃描檔案系統時一定要在單使用者模式、修復模式或把裝置umount後進行。如果掃描執行中的系統，會造成系統檔案損壞。
選擇在單使用者模式下執行
# runlevel  ---檢視執行級別
[root@server ~]# runlevel
N 2
#init 1  --單使用者模式（1 S），在轉換成單使用者模式時可能會需要輸入root密碼。
[root@server ~]# init 1

使用fsck.ext3對檔案系統進行掃描、修復
[root@server ~]# fsck.ext3  -y /dev/sdb1  ---開始進入掃描、修正檔案系統， sdb1必須umount
注意紅色方框，該位置需要輸入yes

fsck.ext3開始進入掃描、修正檔案系統，這個過程時間比較長，中間有數次停頓的過程，只需等待即可，千萬不要以為宕機而重新啟動伺服器。
fsck.ext3掃描、修正完檔案系統後，根據提示可能需要重新啟動系統。如果沒有提示重新啟動系統，也需要reboot來重新啟動系統。
[root@server ~]# reboot  ---重新啟動系統
在重新啟動系統的過程中，fsck會對檔案系統進行掃描，如下：

fsck掃描完以後，會啟動到系統的登入介面，不需要進行任何干涉。
 
再次重新啟動系統，系統可以正常啟動。

【Linux ext3 fsck一定要慎用】

　　不管是哪種檔案系統，其根本目的都是相同的：如何把檔案存在系統給定的區域裡，如何有效地管理檔案的讀與寫。為實現這樣的目的，驅動層需要完善、周密地應付附加在檔案系統上的各種操作。這些操作通常不會是一條指令完成的，如果一個過程需要多條指令完成???在執行這些操作時，全部指令未完成的情況下產生中斷，那這個檔案系統便會出現一致性錯誤(或者叫連續性錯誤)。

　　為了保證盡可以少的出現一致性錯誤，現在主流的檔案系統都會設計成紀錄檔型的。紀錄檔型檔案系統的主要特點就是把一個操作的所有指令執行過程都另外緩衝下來，如果全部執行完成再清除紀錄檔標誌，如果操作沒有執行完成，可以在重新啟用後通過紀錄檔回溯或繼續完成。

　　EXT3的紀錄檔功能通過在EXT2的設計基礎上增加一個特殊的檔案(通常是８號節點檔案)，在這個檔案中記錄檔案系統的操作過程。但EXT系統檔案系統本身在節點、間接索引塊、目錄節點方面沒有冗餘保護，所以當檔案系統除紀錄檔外的其他結構並不一致，卻又要通過fsck來進行修復，這種一致性有可能將原本正確的結構也錯誤化。(就像原來是1+2=3，現在錯成了1+3=3，也許改完後變成了1+3=4，就完全沒辦法還原成最早的1+2=3)。

　　資料恢復領域經常會遇到這類情況：一次RAID出故障後，下次啟動系統提示做fsck，但做完後，也無法mount分割區或者mount 分割區後資料全是錯的。需要對這類情況進行資料修復的難度是很大的，從一個完整的結構(fsck後實際上從系統角度看已經是完整的了)再構建另一個完全不同的結構要比修正一個錯誤的結構更難以下手。其實這類情況，很多是因為RAID5有早離線的盤加入了兩個邏輯磁碟組，導致所有的資料流是以新+舊的方式交錯組成的，自然會有太多錯誤。這時候如果做fsck後，有可能資料都無法恢復了。

　　所以，在EXT3（實際上其他檔案系統也類似）無法mount，或者提示fsck時，如果有重要資料，應該慎重對待，千萬不可貿然執行"fsck -f -y　"這樣的自動修復功能。如果可能，先對故障區域做dd全映象後再執行，或者以唯讀方式執行，並仔細看修復過程，如果提示大量inode錯誤、需要重建樹、或大小不對等就不可再繼續下去了。

本文永久更新連結地址：http://www.linuxidc.com/Linux/2017-12/149622.htm