blog
XFS 文件系统修复指南：诊断、恢复与最佳实践
文档信息
适用系统： RHEL 7/8/9 · CentOS 7/8 · Rocky Linux · AlmaLinux · Ubuntu 20.04+
内核要求： Linux Kernel ≥ 3.10（XFS v5 需 ≥ 3.16）
阅读时间： 约 25 分钟
目录
XFS 基础与损坏原因
损坏诊断与症状识别
修复前必读：黄金原则
核心工具详解
xfs_repair 完整修复流程
xfs_db 底层调试
日志（Journal）恢复
数据恢复策略
特殊场景处理
预防性维护
参考资料
1. XFS 基础与损坏原因
1.1 XFS 核心架构
XFS 是 SGI 于 1993 年开发的高性能 64 位日志型文件系统，RHEL 7 起成为默认文件系统。其核心结构如下：
XFS 磁盘布局
┌─────────────────────────────────────────────────────────┐
│ Superblock (SB) │ 主超级块，记录文件系统元数据 │
├─────────────────────────────────────────────────────────┤
│ AG 0 │ Allocation Group 0（含独立 SB 副本） │
│ ├─ AGF │ 空闲空间 B+Tree 根 │
│ ├─ AGI │ inode B+Tree 根 │
│ └─ AGFL │ 空闲列表 │
├─────────────────────────────────────────────────────────┤
│ AG 1 ... AG N │ 每个 AG 独立管理，支持并行 I/O │
├─────────────────────────────────────────────────────────┤
│ Internal Log │ 日志区（或外部日志设备） │
└─────────────────────────────────────────────────────────┘
关键概念：
概念
说明
AG（Allocation Group）
分配组，XFS 的并发单元，大文件系统通常有数十至数百个 AG
Superblock
记录块大小、AG 数量、UUID、特性标志等关键元数据
B+Tree
XFS 广泛使用 B+Tree 管理空闲空间、inode、目录项
日志（Log）
保证元数据操作的原子性，损坏日志是 XFS 最常见故障
inode
文件元数据节点，默认 512 字节（XFS v5 可更大）
1.2 损坏的常见原因
磁盘损坏根因分类
硬件层面
├─ 存储设备突然断电（最常见）
├─ 坏块（Bad Sector）/ 硬件 ECC 错误
├─ RAID 控制器故障或缓存数据丢失
└─ 磁盘固件 Bug / 写入中途掉电
系统层面
├─ 内核崩溃（Kernel Panic）时文件系统未 umount
├─ 强制 kill -9 正在写入的进程
├─ 虚拟机快照回滚导致文件系统不一致
└─ 时间戳回退（NTP 跳变）
操作层面
├─ 误操作 dd / mkfs 覆盖分区
├─ 分区调整（resize）操作中断
└─ 文件系统挂载参数不当（如关闭日志 nobarrier）
2. 损坏诊断与症状识别
2.1 系统日志快速排查
第一步：查看内核日志，识别 I/O 错误：
# 查看最近的文件系统错误
dmesg | grep -iE "xfs|error|corruption|ioerror" | tail -50
# 查看系统日志（systemd）
journalctl -k -p err --since "1 hour ago" | grep -i xfs
# 查看 /var/log/messages（RHEL/CentOS）
grep -i "xfs\|filesystem" /var/log/messages | tail -100
# 实时监控内核日志
dmesg -w | grep -i xfs
典型 XFS 错误消息解读：
# 日志损坏（最常见）
XFS (sdb1): log mount/recovery failed: error -5
XFS (sdb1): Log I/O Error Detected. Shutting down filesystem
# 元数据校验失败（XFS v5 CRC）
XFS (sdb1): Metadata CRC error detected at xfs_agf_read_verify
XFS (sdb1): Corruption detected. Unmounting filesystem
# inode 损坏
XFS (sdb1): corrupt dinode 12345678, ... Unmounting filesystem
# 超级块损坏
XFS (sdb1): bad magic number
XFS (sdb1): SB validate failed with error -22
2.2 文件系统状态检查
# 查看挂载状态
mount | grep xfs
df -hT | grep xfs
# 检查文件系统是否以只读模式重新挂载（损坏的典型表现）
dmesg | grep "remounting read-only"
# 查看块设备信息
lsblk -f
blkid /dev/sdXN
# 检查磁盘 SMART 状态
smartctl -a /dev/sdX
smartctl -t short /dev/sdX # 触发快速自检
2.3 xfs_check 快速检测
注意
xfs_check 在大文件系统上极慢，已被废弃，推荐使用 xfs_repair -n。
# 只读模式检查（不修复），适合快速确认是否存在问题
xfs_repair -n /dev/sdXN
# 输出解读：
# "No modify flag set, skipping phase X" → 正常，表示只读模式
# "would have fixed ..." → 发现问题，需要实际修复
# "Metadata corruption detected" → 元数据损坏
2.4 故障严重程度评估
级别
症状
建议行动
轻微
文件系统只读重挂、日志需重放
xfs_repair 通常可自动修复
中等
部分 inode 损坏、目录项丢失
xfs_repair 修复 + 备份恢复丢失文件
严重
超级块损坏、AG 头部损坏
使用备份超级块恢复 + xfs_repair
极严重
多 AG 损坏、日志区物理损坏
需结合底层工具 + 数据恢复
3. 修复前必读：黄金原则
数据安全警告
这些原则关乎数据安全，请在操作前逐条确认。
原则一：先备份，再修复
# 对损坏分区做完整镜像（哪怕分区已损坏）
# dd 会跳过读取错误并继续，conv=noerror,sync 填充坏块为零
dd if=/dev/sdXN of=/backup/disk-image.img bs=4M conv=noerror,sync status=progress
# 使用 ddrescue（推荐，比 dd 更强的坏块处理）
ddrescue -d -r3 /dev/sdXN /backup/disk-image.img /backup/rescue.log
# 验证镜像可读
file /backup/disk-image.img
xfs_repair -n /backup/disk-image.img # 在镜像上先测试
原则二：修复前必须卸载
# XFS 必须在卸载状态下修复（不能在线修复损坏）
umount /dev/sdXN
# 若设备忙，查找并终止占用进程
fuser -mv /mount/point
lsof | grep /mount/point
fuser -k /mount/point # 强制终止（谨慎）
# 若无法卸载（根分区），进入单用户模式或救援模式
systemctl rescue
# 或通过 LiveCD/LiveUSB 启动
原则三：根分区修复必须离线
# 根分区（/）无法在运行时卸载
# 方法 1：进入救援模式（systemd）
systemctl rescue
# 方法 2：编辑 GRUB，追加 single 或 emergency 启动参数
# 在 GRUB 选项行末尾加：rd.break 或 init=/bin/bash
# 方法 3：使用同发行版 LiveCD 启动后操作
# 方法 4：设置 /etc/fstab 的 fsck 顺序（xfs 通常不自动 fsck）
# XFS 会在挂载时自动重放日志，无需 fsck
原则四：记录操作日志
# 所有修复操作务必记录，便于回溯
script /tmp/xfs-repair-$(date +%Y%m%d-%H%M%S).log
# ... 执行修复操作 ...
exit
4. 核心工具详解
4.1 工具速查
工具
用途
风险等级
xfs_repair
文件系统元数据检查与修复
中（会修改文件系统）
xfs_db
底层调试、结构查看与手动修改
高（直接操作底层结构）
xfs_metadump
导出元数据用于离线分析
低（只读导出）
xfs_mdrestore
从 metadump 恢复元数据
中
xfs_logprint
解析并打印 XFS 日志内容
低（只读）
xfs_growfs
在线扩展文件系统
中
xfs_freeze
冻结/解冻文件系统（用于一致性快照）
低
xfs_info
查看文件系统参数
低（只读）
ddrescue
坏块磁盘镜像恢复
低（源盘只读）
4.2 安装工具包
# RHEL/CentOS/Rocky
yum install -y xfsprogs xfsdump gddrescue
# Ubuntu/Debian
apt install -y xfsprogs xfsdump gddrescue
# 验证安装
xfs_repair -V
xfs_db -V
5. xfs_repair 完整修复流程
xfs_repair 是 XFS 的主要修复工具，采用多阶段检查机制。
5.1 修复阶段说明
xfs_repair 工作阶段
Phase 1: 找到并验证文件系统超级块
Phase 2: 检查 AG 头部结构（AGF / AGI / AGFL）
Phase 3: 扫描 AG 中的 inode，检查 inode 结构
Phase 4: 清理并重建 inode 链接计数
Phase 5: 检查并修复各 inode 的内容（目录/数据块）
Phase 6: 检查目录连接性（确保所有 inode 可达）
Phase 7: 重建 AG 空闲列表
Phase 8: 验证并清理磁盘配额信息（若有）
关键阶段：
- Phase 2 失败 → AG 头部损坏，可能需要备份超级块
- Phase 3 失败 → inode 严重损坏
- Phase 6 产生 lost+found → 有孤立文件
5.2 标准修复步骤
Step 1：只读预检（不修改磁盘）
# 强烈建议先执行只读检查，了解损坏程度
xfs_repair -n /dev/sdXN 2>&1 | tee /tmp/xfs-check.log
# 分析输出
grep -E "ERROR|CORRUPT|would|bad|lost" /tmp/xfs-check.log | head -50
Step 2：执行修复
# 标准修复（最常用）
xfs_repair /dev/sdXN 2>&1 | tee /tmp/xfs-repair.log
# 修复过程中的关键输出说明：
# "Phase X - ..." → 进度正常
# "ERROR: ..." → 发现错误（通常会自动修复）
# "fixed ..." → 已修复
# "disconnected inode XXXXXXXX, moving to lost+found" → 孤立 inode
# "would move inode ... to lost+found" → （-n 模式，实际会处理）
Step 3：强制重置日志（日志损坏时）
# 当 xfs_repair 提示日志损坏，无法正常修复时
# ⚠️ 此操作会丢失未提交的事务（通常可接受）
xfs_repair -L /dev/sdXN 2>&1 | tee /tmp/xfs-repair-L.log
-L 参数说明
强制清零日志，会丢失日志中尚未提交的元数据变更。对于已损坏的文件系统，这通常是必要的，代价是可能丢失最近几秒内的写操作。
Step 4：使用备份超级块修复
# 当主超级块损坏时，使用备份超级块
# 首先找到所有备份超级块的位置
xfs_db -c "sb 0" -c "print" /dev/sdXN # 查看 agcount 和 agblocks
# 或使用 xfs_repair 自动探测备份超级块
xfs_repair -o ag_stride=
# 指定备份超级块位置（AG 编号，从 1 开始）
xfs_repair -b
# 更简单的方式：让 xfs_repair 自动寻找
xfs_repair /dev/sdXN
# 若失败，尝试：
xfs_repair -v /dev/sdXN # 详细模式，显示更多信息
Step 5：验证修复结果
# 修复完成后再次只读检查
xfs_repair -n /dev/sdXN
# 若无错误输出，尝试挂载
mount /dev/sdXN /mnt/recovery
# 验证文件系统完整性
ls -la /mnt/recovery/
ls -la /mnt/recovery/lost+found/ # 查看是否有孤立文件
# 查看文件系统信息
xfs_info /mnt/recovery
df -hT /mnt/recovery
5.3 xfs_repair 常用参数
# -n 只读检查，不修改文件系统（Dry Run）
xfs_repair -n /dev/sdXN
# -L 强制清零日志（日志损坏时使用）
xfs_repair -L /dev/sdXN
# -v 详细输出
xfs_repair -v /dev/sdXN
# -d 允许在挂载状态下运行（危险！仅用于根分区单用户模式）
xfs_repair -d /dev/sdXN
# -e 遇到错误立即退出（不尝试修复）
xfs_repair -e /dev/sdXN
# -f 将设备视为普通文件（用于镜像文件修复）
xfs_repair -f /path/to/image.img
# -m
xfs_repair -m 2048 /dev/sdXN
# -t
xfs_repair -t 30 /dev/sdXN
# -P 禁用预取（Prefetch），减少内存使用
xfs_repair -P /dev/sdXN
# 组合使用示例
xfs_repair -v -t 30 /dev/sdXN 2>&1 | tee /tmp/repair-$(date +%Y%m%d%H%M%S).log
6. xfs_db 底层调试
xfs_db 是 XFS 的底层调试工具，允许直接查看和修改文件系统结构。高风险，非必要不直接修改。
6.1 只读探查（安全操作）
# 以只读模式启动（推荐）
xfs_db -r /dev/sdXN
# 常用只读命令
xfs_db -r -c "sb" /dev/sdXN # 查看超级块
xfs_db -r -c "sb 0" -c "print" /dev/sdXN # 打印主超级块内容
xfs_db -r -c "agf 0" -c "print" /dev/sdXN# 查看 AG 0 的空闲块头
xfs_db -r -c "agi 0" -c "print" /dev/sdXN# 查看 AG 0 的 inode 头
# 查看文件系统 UUID
xfs_db -r -c "uuid" /dev/sdXN
# 查看标志位
xfs_db -r -c "sb 0" -c "print features_incompat" /dev/sdXN
6.2 超级块关键字段解读
xfs_db -r -c "sb 0" -c "print" /dev/sdXN
# 重点字段：
# magicnum = 0x58465342 → 必须为 "XFSB"，否则超级块损坏
# blocksize = 4096 → 块大小（通常 4096 字节）
# dblocks = XXXXXX → 数据块总数
# agcount = XX → AG 总数
# agblocks = XXXXXX → 每个 AG 的块数
# logstart = XXXXXX → 日志起始块（内部日志）
# uuid = XXXXXXXX-... → 文件系统 UUID
# inprogress = 0 → 必须为 0，为 1 表示修复未完成
# versionnum = ... → 版本号（v5 特性需要 >= 5）
6.3 查找备份超级块
# 列出所有 AG 的超级块位置
xfs_db -r /dev/sdXN
sb 0
print agblocks # 记下 agblocks 的值，例如 2621440
# 备份超级块位于每个 AG 的第一个块：
# AG 0: block 0 (主超级块)
# AG 1: block agblocks * 1
# AG 2: block agblocks * 2
# ...
# 快速列出所有备份超级块块号
xfs_db -r -c "sb 0" -c "print agblocks agcount" /dev/sdXN
# 假设 agblocks=2621440, agcount=8
# 备份 SB 位于块：2621440, 5242880, 7864320, ...
# 验证备份超级块
xfs_db -r -c "fsblock 2621440" -c "type sb" -c "print" /dev/sdXN
6.4 使用 metadump 导出元数据
# 导出元数据（不含用户数据，可安全传输给专家分析）
xfs_metadump /dev/sdXN /tmp/metadata-$(date +%Y%m%d).xfsdump
# 在另一系统恢复元数据进行分析
xfs_mdrestore /tmp/metadata.xfsdump /tmp/restored-image.img
# 在恢复镜像上进行无损调试
xfs_db -r /tmp/restored-image.img
7. 日志（Journal）恢复
XFS 日志损坏是最常见的故障类型，处理方式如下：
7.1 检查日志状态
# 打印日志内容（只读）
xfs_logprint /dev/sdXN
# 查看日志配置
xfs_info /dev/sdXN | grep -i log
# 检查日志是否干净
xfs_db -r -c "sb 0" -c "print" /dev/sdXN | grep -E "logstart|logblocks|logbsize"
7.2 日志损坏的典型表现
# 挂载时报错
mount: /dev/sdXN: can't read superblock
XFS: log mount/recovery failed: error -5
# xfs_repair 输出
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it
before re-running xfs_repair.
# 无法挂载也无法重放时
XFS: log mount/recovery failed
7.3 日志恢复步骤
# Step 1: 尝试正常挂载（自动重放日志）
mount /dev/sdXN /mnt/test
# Step 2: 若挂载失败，尝试忽略日志挂载（会丢失未完成事务）
mount -o norecovery,ro /dev/sdXN /mnt/test
# Step 3: 若仍失败，用 xfs_repair 重放日志
xfs_repair /dev/sdXN
# Step 4: 若 xfs_repair 提示日志不可恢复，强制清零
# ⚠️ 最后手段，确保已有备份
xfs_repair -L /dev/sdXN
# Step 5: 确认日志已清理
xfs_logprint /dev/sdXN | head -20
# 正常输出: "no log records"
7.4 外部日志设备
# 若使用外部日志设备（-l 参数挂载的文件系统）
mount -o logdev=/dev/sdYN /dev/sdXN /mnt/test
# xfs_repair 指定外部日志
xfs_repair -l /dev/sdYN /dev/sdXN
# 强制清零外部日志
xfs_repair -l /dev/sdYN -L /dev/sdXN
8. 数据恢复策略
8.1 lost+found 目录处理
xfs_repair 会将无法确定归属的 inode 放入 lost+found：
# 挂载后查看 lost+found
ls -la /mnt/recovery/lost+found/
# lost+found 中的文件命名规则：
# #INODE_NUMBER（例如 #12345678）
# 尝试识别文件类型
file /mnt/recovery/lost+found/*
# 对文本文件，查看内容推断用途
head -5 /mnt/recovery/lost+found/\#12345678
# 批量识别
for f in /mnt/recovery/lost+found/*; do
echo "=== $f ==="
file "$f"
head -2 "$f" 2>/dev/null || echo "[binary file]"
done
8.2 使用 PhotoRec / TestDisk 恢复用户数据
当 XFS 元数据严重损坏，文件无法通过 xfs_repair 恢复时，使用数据雕刻工具：
# 安装
yum install -y testdisk # RHEL/CentOS
apt install -y testdisk # Ubuntu
# TestDisk：修复分区表、恢复分区
testdisk /dev/sdX
# PhotoRec：按文件头特征恢复文件（不依赖文件系统）
photorec /dev/sdXN
# → 选择分区 → 选择文件类型 → 选择输出目录 → 开始恢复
# ⚠️ PhotoRec 恢复的文件无原始文件名，需手动整理
8.3 挂载只读镜像进行恢复
# 将磁盘镜像以 loop 方式挂载（只读，安全）
losetup -r -f /backup/disk-image.img
losetup -a # 查看 loop 设备编号，例如 /dev/loop0
# 修复镜像（不影响原始磁盘）
xfs_repair -f /backup/disk-image.img
# 挂载修复后的镜像
mount -o loop,ro /backup/disk-image.img /mnt/recovery
# 从镜像中拷贝数据
rsync -avH /mnt/recovery/ /data/restored/
9. 特殊场景处理
9.1 根分区（/）损坏修复
# 方案 1：进入 Emergency 模式
# 在 GRUB 启动参数末尾添加：
systemd.unit=emergency.target
# 进入 emergency shell 后
mount -o remount,ro /
xfs_repair /dev/sdaN # 根分区设备
# 方案 2：使用 LiveCD
# 1. 从 LiveCD 启动
# 2. 识别根分区
lsblk -f
# 3. 修复
xfs_repair /dev/sdaN
# 4. 验证并重启
mount /dev/sdaN /mnt && ls /mnt
9.2 LVM 上的 XFS 修复
# 激活 LVM 卷组
vgscan
vgchange -ay
# 查看逻辑卷
lvdisplay
lvs
# 卸载并修复
umount /dev/vg0/lv_data
xfs_repair /dev/vg0/lv_data
# 若 LVM 元数据也损坏，先修复 LVM
vgcfgrestore -f /etc/lvm/backup/vg0 vg0
9.3 加密分区（LUKS）上的 XFS 修复
# 解锁 LUKS 容器
cryptsetup luksOpen /dev/sdXN xfs_crypt
# 修复内层 XFS
xfs_repair /dev/mapper/xfs_crypt
# 修复完成后关闭
cryptsetup luksClose xfs_crypt
9.4 NFS 导出的 XFS 修复
# 取消所有 NFS 导出
exportfs -ua
# 确认无客户端连接
netstat -an | grep :2049
showmount -a
# 卸载并修复
umount /export/data
xfs_repair /dev/sdXN
# 重新挂载并恢复导出
mount /dev/sdXN /export/data
exportfs -a
9.5 容器/虚拟机环境
# Docker 数据目录（通常为 /var/lib/docker）
# 先停止 Docker
systemctl stop docker
# 修复
xfs_repair /dev/sdXN # Docker 所在分区
# 若 Docker 使用 overlay2，修复后可能需要重建层
systemctl start docker
docker system prune # 清理损坏的 layer（会删除所有停止的容器和未使用镜像）
10. 预防性维护
10.1 挂载参数优化
# /etc/fstab 推荐配置
# 格式：设备 挂载点 类型 选项 dump fsck优先级
# 数据盘（高性能）
/dev/sdXN /data xfs defaults,noatime,nodiratime 0 0
# 重要数据盘（强一致性）
/dev/sdXN /critical xfs defaults,noatime,barrier 0 0
# 参数说明：
# noatime → 不更新访问时间，减少写 I/O
# nodiratime → 不更新目录访问时间
# barrier → 写屏障（默认开启，确保掉电安全）
# nobarrier → ⚠️ 禁用写屏障（SSD/RAID 带 BBU 时可提升性能，但增加风险）
# logbufs=8 → 增大日志缓冲数（高并发写入场景）
# allocsize= → 预分配大小（流式写入场景）
10.2 监控脚本
#!/bin/bash
# /usr/local/bin/xfs-health-check.sh
# 建议加入 crontab 每日执行
LOGFILE="/var/log/xfs-health-$(date +%Y%m%d).log"
ALERT_EMAIL="[email protected]"
echo "=== XFS Health Check $(date) ===" >> "$LOGFILE"
# 检查所有 XFS 分区
while IFS= read -r line; do
device=$(echo "$line" | awk '{print $1}')
mountpoint=$(echo "$line" | awk '{print $3}')
echo "Checking $device ($mountpoint)..." >> "$LOGFILE"
# 检查 dmesg 中的 XFS 错误
errors=$(dmesg | grep "XFS.*$device" | grep -i "error\|corrupt" | wc -l)
if [ "$errors" -gt 0 ]; then
msg="WARNING: $errors XFS errors found for $device"
echo "$msg" >> "$LOGFILE"
echo "$msg" | mail -s "XFS Alert on $(hostname)" "$ALERT_EMAIL"
fi
# 检查文件系统使用率
usage=$(df -h "$mountpoint" | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$usage" -gt 90 ]; then
msg="WARNING: $mountpoint is ${usage}% full"
echo "$msg" >> "$LOGFILE"
echo "$msg" | mail -s "XFS Disk Space Alert on $(hostname)" "$ALERT_EMAIL"
fi
done < <(mount | grep "type xfs")
echo "=== Check Complete ===" >> "$LOGFILE"
# 添加到 crontab
echo "0 2 * * * root /usr/local/bin/xfs-health-check.sh" > /etc/cron.d/xfs-health
chmod 644 /etc/cron.d/xfs-health
10.3 定期备份策略
# 使用 xfsdump 进行增量备份（XFS 原生备份工具）
# Level 0 = 全量备份
xfsdump -l 0 -f /backup/data-full-$(date +%Y%m%d).dump /data
# Level 1 = 基于上次 Level 0 的增量
xfsdump -l 1 -f /backup/data-incr-$(date +%Y%m%d).dump /data
# 恢复
xfsrestore -f /backup/data-full-20260101.dump /mnt/restore
# 查看 dump 信息
xfsdump -I # 列出所有历史 dump 记录
10.4 UPS 与写缓存配置
# 查看磁盘写缓存状态
hdparm -W /dev/sdX
# 对无 BBU 的 RAID 控制器，禁用磁盘写缓存
hdparm -W0 /dev/sdX
# 对有 BBU 的 RAID 控制器，可以启用（通过控制器管理界面）
# SSD 检查是否支持 FUA（强制单元访问）
cat /sys/block/sda/queue/fua
10.5 内核参数调优
# /etc/sysctl.d/99-xfs.conf
# 增大脏数据回写阈值（减少突发 I/O）
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
# 增大脏数据最大驻留时间（秒）
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
# 应用
sysctl -p /etc/sysctl.d/99-xfs.conf
11. 参考资料
资源
说明
XFS 官方文档
XFS 内核 Wiki，架构与设计文档
xfs_repair(8) 手册页
man 8 xfs_repair 完整参数说明
xfs_db(8) 手册页
底层调试工具完整文档
Red Hat Storage Administration Guide
RHEL 官方文件系统管理指南
Linux XFS FAQ
常见问题解答
ddrescue 手册
GNU ddrescue 官方文档
TestDisk / PhotoRec
数据恢复工具官方文档
快速参考卡
XFS 修复速查
【诊断】
dmesg | grep -i xfs # 查看内核错误
xfs_repair -n /dev/sdXN # 只读检查
【标准修复流程】
1. umount /dev/sdXN # 卸载
2. dd/ddrescue → 备份镜像 # 备份
3. xfs_repair /dev/sdXN # 修复
4. xfs_repair -n /dev/sdXN # 验证
5. mount /dev/sdXN /mnt # 挂载验证
【日志损坏】
xfs_repair -L /dev/sdXN # 强制清零日志（最后手段）
【超级块损坏】
xfs_db -r -c "sb 0" -c "print" /dev/sdXN # 查看超级块
xfs_repair /dev/sdXN # 自动找备份超级块
【孤立文件】
ls /mnt/lost+found/ # 查看孤立 inode
【镜像修复】
xfs_repair -f /path/to/image.img # 在镜像上修复
总结
XFS 修复的核心原则是 “备份优先，只读验证，最后动手”。xfs_repair 能处理绝大多数场景，日志损坏时配合 -L 参数，超级块损坏时利用 AG 备份副本恢复。任何操作前务必用 ddrescue 备份原始磁盘镜像，这是数据安全的最后防线。