XFS 文件系统修复指南：诊断、恢复与最佳实践

Wed, 15 Apr 2026 00:00:00 +0000

XFS 文件系统修复指南：诊断、恢复与最佳实践

文档信息

适用系统： RHEL 7/8/9 · CentOS 7/8 · Rocky Linux · AlmaLinux · Ubuntu 20.04+
内核要求： Linux Kernel ≥ 3.10（XFS v5 需 ≥ 3.16）
阅读时间： 约 25 分钟

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=<agblocks> /dev/sdXN

# 指定备份超级块位置（AG 编号，从 1 开始）
xfs_repair -b <blocksize> -f -o bhash=<size> /dev/sdXN

# 更简单的方式：让 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 <mb>   限制内存使用量（MB），大文件系统修复时可能需要
xfs_repair -m 2048 /dev/sdXN

# -t <secs> 进度报告间隔（秒）
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="ops@example.com"

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 内核 Wiki，架构与设计文档
	`man 8 xfs_repair` 完整参数说明
	底层调试工具完整文档
	RHEL 官方文件系统管理指南
	常见问题解答
	GNU ddrescue 官方文档
	数据恢复工具官方文档

快速参考卡

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 备份原始磁盘镜像，这是数据安全的最后防线。

存储运维 | 技术站点

XFS 文件系统修复指南：诊断、恢复与最佳实践

XFS 文件系统修复指南：诊断、恢复与最佳实践

目录

1. XFS 基础与损坏原因

1.1 XFS 核心架构

1.2 损坏的常见原因

2. 损坏诊断与症状识别

2.1 系统日志快速排查

2.2 文件系统状态检查

2.3 xfs_check 快速检测

2.4 故障严重程度评估

3. 修复前必读：黄金原则

原则一：先备份，再修复

原则二：修复前必须卸载

原则三：根分区修复必须离线

原则四：记录操作日志

4. 核心工具详解

4.1 工具速查

4.2 安装工具包

5. xfs_repair 完整修复流程

5.1 修复阶段说明

5.2 标准修复步骤

Step 1：只读预检（不修改磁盘）

Step 2：执行修复

Step 3：强制重置日志（日志损坏时）

Step 4：使用备份超级块修复

Step 5：验证修复结果

5.3 xfs_repair 常用参数

6. xfs_db 底层调试

6.1 只读探查（安全操作）

6.2 超级块关键字段解读

6.3 查找备份超级块

6.4 使用 metadump 导出元数据

7. 日志（Journal）恢复

7.1 检查日志状态

7.2 日志损坏的典型表现

7.3 日志恢复步骤

7.4 外部日志设备

8. 数据恢复策略

8.1 lost+found 目录处理

8.2 使用 PhotoRec / TestDisk 恢复用户数据

8.3 挂载只读镜像进行恢复

9. 特殊场景处理

9.1 根分区（/）损坏修复

9.2 LVM 上的 XFS 修复

9.3 加密分区（LUKS）上的 XFS 修复

9.4 NFS 导出的 XFS 修复

9.5 容器/虚拟机环境

10. 预防性维护

10.1 挂载参数优化

10.2 监控脚本

10.3 定期备份策略

10.4 UPS 与写缓存配置

10.5 内核参数调优

11. 参考资料

快速参考卡