Linux 檔案系統唯讀故障：成因分析、緊急修復與資料保護全攻略

前言：當系統突然變成「唯讀」

維護 Linux 伺服器時，最讓人心驚膽戰的莫過於檔案系統突然轉為 Read-only file system。此時應用無法寫入日誌、資料庫拒絕新增交易、甚至系統無法重啟。本文將深入剖析兩大主流成因，提供標準化修復流程，並強調資料備份的紅線原則，助你在危機中穩住陣腳。

一、核心成因：兩大典型場景

1. 多機共享存儲：同步機制失效

• 叢集環境下，多節點同時掛載同一檔案系統（如 GFS2、OCFS2、NFS）
• 鎖管理器或分散式協調服務異常，導致寫入衝突或元資料不一致
• 核心為保護資料完整性，主動將檔案系統降級為唯讀

2. 單機意外斷電：日誌回放失敗

• 掉電、核心恐慌、硬體故障導致臟頁未寫入磁碟
• 重啟時 ext4/xfs/jfs 等日誌式檔案系統嘗試回放 Journal
• Journal 損壞或裝置層面報錯（I/O error），掛載程式拒絕讀寫掛載

二、標準修復流程（SOP）

步驟 1：隔離故障檔案系統

# 1. 先嘗試重新掛載為讀寫（若根分區則需特殊處理）
mount -o remount,rw /mount/point

# 2. 若 /etc/fstab 無法寫入，先註解對應行
sed -i '/\/data/s/^/#/' /etc/fstab
# 或手動編輯 vi /etc/fstab

步驟 2：執行檔案系統檢查

# 針對 ext4
fsck -y /dev/sda1

# 針對 XFS（需卸載後執行）
xfs_repair /dev/sda1

# 針對 Btrfs
btrfs check --repair /dev/sda1

關鍵提醒：fsck 執行前務必確認該分區已卸載，否則極高機率造成更嚴重的元資料損壞。根分區請進入單用戶模式或使用 LiveCD 執行。

步驟 3：驗證與恢復服務

# 重新掛載驗證
mount -a
# 檢查應用寫入功能
echo test > /mount/point/test_write && rm /mount/point/test_write

三、資料保護紅線：備份優先原則

# 建議：使用 dd 建立分區級映像檔（需足夠備份空間）
dd if=/dev/sda1 of=/backup/sda1_$(date +%F).img bs=4M status=progress

# 或檔案級備份關鍵目錄
tar -czf /backup/critical_$(date +%F).tar.gz /etc /var/lib/mysql /home

四、預防勝於治療：長期防護策略

1. UPS + 優雅關機腳本：避免硬性斷電
2. 定期檢查磁碟健康：smartctl -a /dev/sdX 監控 Reallocated_Sector_Ct
3. 啟用檔案系統自動修復：/etc/default/rcS 設定 FSCKFIX=yes
4. 叢集環境部署 STONITH：防止裂腦導致雙主寫入
5. 監控告警：Prometheus + node_exporter 監控 node_filesystem_readonly 指標

五、常見錯誤與避坑指南

檔案系統唯讀是保護機制而非故障本身。冷靜執行「備份→隔離→修復→驗證」四步曲，配合平日完善的備份演練與監控體系，才能將風險降至最低。記住：沒有備份的修復，都是在賭運氣。