XFS/ext4 文件系统损坏修复全流程：从紧急排障到 AIOps 自动化预防

前言

做运维这么多年，文件系统损坏属于那种「平时见不着，一碰见就是大事故」的故障。轻则业务只读、数据写入失败，重则分区无法挂载、整台服务器脱机。尤其是跑数据库、日志存储的机器，一旦文件系统出问题，恢复时间直接影响业务 SLA。

很多新手碰到 Input/output error、挂载失败就慌了，上来直接硬修，反而把问题搞大。这篇把 XFS 和 ext4 两套主流文件系统的排查、修复、避坑、标准化巡检、监控告警、AIOps 自愈一次性讲透，全部是生产环境踩过坑总结出来的流程。

一、故障现象与初步定位

1. 典型异常表现

• 读写文件时报 Input/output error
• 执行 ls、df 命令卡住或报错
• 分区变成只读模式（read-only filesystem）
• 重启后分区无法挂载，提示 mount: wrong fs type, bad option, bad superblock
• dmesg 中出现 I/O error、XFS: Internal error、ext4_abort 等内核日志

2. 第一步：先判断是硬件坏了还是文件系统坏了

这一步非常关键，很多人上来直接修文件系统，结果底层是磁盘物理坏道，越修越糟。

bash

运行

# 1. 查看内核日志，确认报错来源
dmesg | grep -E "io error|xfs|ext4|sd[a-z]"

# 2. 检查磁盘健康状态（smartctl）
smartctl -a /dev/sda | grep -E "Reallocated_Sector|Current_Pending_Sector|Offline_Uncorrectable"

# 3. 检查是否有坏道
badblocks -v /dev/sda1

判断原则：

• smartctl 中重映射扇区、待映射扇区数值不为 0 → 优先怀疑磁盘硬件故障，先备份数据再考虑换盘
• dmesg 只有文件系统层面报错，磁盘硬件无异常 → 走文件系统修复流程
• 虚拟机环境基本排除物理坏道，大概率是异常断电、强制关机导致的文件系统元数据损坏

二、XFS 文件系统修复实战流程

XFS 是目前 CentOS 7+、RHEL 主流默认文件系统，修复工具是 xfs_repair，和 ext4 的 fsck 逻辑不太一样，不能乱用。

1. 修复前置条件：必须卸载分区

XFS 修复绝对不能在挂载状态下执行，会直接加重损坏。

bash

运行

# 先尝试正常卸载
umount /data

# 如果提示设备忙，先查占用进程
fuser -m /data
lsof /data

# 紧急情况可以强制卸载（有数据丢失风险，谨慎使用）
umount -l /data

如果是根分区 / 无法卸载，需要进入单用户模式或救援模式操作。

2. 第一步：先做元数据日志重放

大部分异常断电导致的 XFS 损坏，日志重放就能恢复，不用走深度修复。

bash

运行

# 只重放日志，不做完整修复，风险最低
xfs_repair -L /dev/sda1

-L 参数会清空日志并强制挂载，适用于日志损坏导致无法挂载的场景。

3. 第二步：完整修复

日志重放后仍无法挂载，执行完整修复：

bash

运行

# 标准修复
xfs_repair /dev/sda1

# 修复完成后验证
xfs_check /dev/sda1

4. 极端情况：超级块损坏

XFS 超级块损坏时，需要用备份超级块修复：

bash

运行

# 查找备份超级块位置
xfs_db -r /dev/sda1
xfs_db> sb 0
xfs_db> p

# 指定备份超级块进行修复
xfs_repair -b 块大小 -s 备份超级块位置 /dev/sda1

5. 修复后验证与挂载

bash

运行

# 先只读挂载验证数据完整性
mount -o ro,norecovery /dev/sda1 /data

# 确认文件正常可读后，重新读写挂载
umount /data
mount /dev/sda1 /data

三、ext4 文件系统修复实战流程

ext4 是老牌文件系统，修复工具 e2fsck 更成熟，但同样有严格的操作顺序。

1. 同样先卸载分区

bash

运行

umount /data

2. 查找备份超级块

ext4 有多个超级块备份，主超级块坏了可以用备份恢复，这是 ext4 的一大优势。

bash

运行

# 查看超级块备份位置
dumpe2fs /dev/sda1 | grep -i superblock

# 或者通过 mkfs 模拟查询（不会真的格式化）
mkfs.ext4 -n /dev/sda1

输出中 Backup superblock at 后面的数字就是备份块号。

3. 执行修复

bash

运行

# 基础修复，自动回答 yes
e2fsck -y /dev/sda1

# 主超级块损坏，指定备份超级块修复
e2fsck -b 32768 /dev/sda1

# 强制检查（即使文件系统标记为干净也强制扫描）
e2fsck -f /dev/sda1

4. 修复参数说明

• -p：自动修复（preen），安全问题自动修，严重问题停下
• -y：所有问题都回答 yes，适合无人值守但有一定风险
• -n：只检查不修复，先预扫一遍评估损坏程度
• -f：强制完整检查

生产环境建议顺序： 先用 -n 看损坏程度 → 再用 -p 自动安全修复 → 最后才考虑 -y 全量修复。

四、线上修复五大避坑要点（踩过的坑总结）

坑 1：挂载状态下直接跑修复

不管 XFS 还是 ext4，挂载状态执行修复工具都是高危操作，轻则修复无效，重则元数据彻底损坏。务必先卸载，根分区就进救援模式。

坑 2：没备份就硬修

修复前如果数据重要，先做整块磁盘镜像备份：

bash

运行

dd if=/dev/sda1 of=/backup/sda1.img bs=4M

修坏了还能回滚，尤其是客户数据、数据库分区，这一步不能省。

坑 3：磁盘有坏道还反复 fsck

物理坏道导致的文件系统损坏，fsck 修完还会反复坏，正确做法是先标记坏道或直接换盘，再恢复数据。

坑 4：修复后直接挂载写业务

修复完先只读挂载验证文件完整性，检查关键数据、目录结构是否正常，确认没问题再切读写模式恢复业务。

坑 5：忽略文件系统版本与工具版本匹配

老版本的 xfs_repair 修复新版 XFS 会出问题，救援模式下注意工具版本和原系统一致。

五、标准化巡检 SOP：把故障掐在萌芽期

文件系统损坏不是突然发生的，前期都有征兆，纳入日常巡检就能提前发现。

每日巡检项

bash

运行

# 1. 检查文件系统是否只读挂载
mount | grep "(ro"

# 2. 检查 dmesg 有无 IO 错误
dmesg | grep -i "io error|xfs error|ext4 error" | tail -20

# 3. 检查磁盘 SMART 健康度
smartctl -H /dev/sda

# 4. 验证各分区可正常写入
touch /data/.write_test && rm /data/.write_test

每月深度巡检

1. 对非核心分区执行一次只读文件系统一致性检查
2. 统计 SMART 坏道趋势，坏道数量增长的磁盘提前更换
3. 验证备份超级块完整性
4. 检查所有挂载点 fstab 配置，确认修复参数与实际文件系统匹配

故障处理 SOP 流程

1. 告警触发 → 2. 确认影响范围 → 3. 备份数据 / 镜像 → 4. 判断硬件 / 软件故障 → 5. 卸载分区 → 6. 执行对应修复工具 → 7. 只读验证 → 8. 恢复挂载 → 9. 业务验证 → 10. 复盘归档

六、监控告警体系搭建

1. 基础监控指标（Prometheus/node_exporter）

表格

指标	告警阈值	说明
node_filesystem_readonly	== 1	分区变成只读，立即告警
node_filesystem_avail_bytes	< 10%	空间不足，间接关联文件系统风险
node_disk_io_time_seconds_total 异常飙升	-	IO 异常升高，疑似坏道
dmesg 关键字告警	匹配到 error 关键字	内核层文件系统报错

2. 日志监控（ELK / 自建日志平台）

配置关键字告警规则，匹配以下内容立即触发 P2 级告警：

• XFS: Internal error
• ext4_abort
• I/O error
• read-only filesystem
• journal aborted

3. 分级告警策略

• P1：根分区只读、核心数据分区无法挂载 → 电话 + 短信告警
• P2：非核心分区 IO 报错、SMART 坏道增长 → 企业微信 / 钉钉告警
• P3：磁盘空间不足、inode 告警 → 普通工单处理

七、AIOps 自动化预防与自愈

文件系统故障靠人工巡检效率太低，结合 AIOps 思路可以做到自动发现、自动评估、部分场景自动恢复。

1. 自动化巡检脚本

每日定时执行，异常自动上报：

bash

运行

#!/bin/bash
# 文件系统健康巡检脚本
PARTITIONS="/ /data /var/log"

for part in $PARTITIONS; do
    # 检查只读状态
    if mount | grep "$part" | grep -q "(ro"; then
        echo "ALERT: $part is read-only"
        # 触发告警逻辑
    fi
    
    # 写入测试
    if ! touch "$part/.health_check_$$" 2>/dev/null; then
        echo "ALERT: $part write failed"
    else
        rm -f "$part/.health_check_$$"
    fi
done

# dmesg 错误扫描
if dmesg | grep -qiE "xfs error|ext4 error|i/o error"; then
    echo "ALERT: filesystem errors found in dmesg"
fi

2. 预测性维护：坏道趋势预测

收集每日 SMART 重映射扇区数据，建立趋势模型：

• 连续 7 天坏道数增长 → 自动创建更换磁盘工单
• 坏道数超过阈值 → 自动标记该磁盘为高风险，业务迁移预警

3. 轻量级自愈场景

场景：非核心分区因日志异常导致文件系统只读

• 监控检测到只读状态 → 自动判断分区等级
• 非核心分区 → 自动卸载 → 执行安全修复 → 重新挂载 → 验证写入 → 通知运维人员
• 核心分区 → 只告警不自动操作，人工介入

4. 根因分析辅助

每次文件系统故障自动收集上下文：

• 故障前 1 小时磁盘 IO 指标
• 系统重启 / 断电记录
• 关联的业务写入峰值
• 磁盘 SMART 历史数据

自动生成初步根因分析报告，减少人工排查时间。

结尾

文件系统损坏属于低频高危故障，一年碰不上几次，但碰上一次处理不好就是重大事故。比起故障发生后比拼修复速度，更重要的是监控早发现、巡检早预防、SOP 标准化、自动化早自愈。

从手动 fsck 救火，到标准化流程，再到 AIOps 自动化闭环，本质上都是把运维经验沉淀成体系，让故障越来越少，处理越来越快。后续会继续分享更多生产环境落地的运维标准化实战方案。