元数据损坏时抢救数据量无固定比例，取决于损坏位置、严重程度和干预及时性；越早停机、越少写入、备份越完整，恢复空间越大。
元数据错误发生时，能抢救多少数据没有固定比例，取决于损坏位置、严重程度和是否及时干预。核心原则是：越早停机、越少写入、越完整备份，恢复空间越大。
哪些元数据损坏相对“友好”，数据较可能保全
这类情况通常只影响文件系统管理结构，不直接破坏文件内容：
- 日志区（log）损坏：xfs_repair -L 强制清空日志后常可挂载，大部分用户文件完好，仅可能丢失最后一次未提交的写操作（如正在保存的文档）
- 某一个分配组（AG）的AGF或AGI结构异常：若非根AG或关键AG，修复后该AG内文件可能无法访问，但其他AG中的数据仍可读取
- 部分inode索引块损坏：仅导致个别目录打不开或某些文件“消失”，但文件数据块本身未覆盖，后续可用 xfs_undelete 或类型扫描恢复
哪些元数据损坏意味着大面积数据风险
这些属于深层结构性破坏，常规修复易失败，恢复难度陡增：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 超级块（superblock）完全损毁且无有效备份：xfs_repair 无法识别文件系统，必须依赖 xfs_db 手动定位备用块；若所有备份块也失效，需从镜像中人工提取AG信息
- 根inode（root inode）不可读：系统无法构建目录树起点，/、/usr、/var 等挂载点全部失效，即使数据块完好，也无法按路径访问
- 实时日志+AGF+自由空间位图同时报错：说明分配逻辑已紊乱，修复过程可能误将A文件的数据块分配给B文件，造成交叉覆盖
修复前必须做的三件事（决定抢救上限）
跳过任一环节，都可能把“部分损坏”变成“彻底覆写”：
- 立即停止写入并卸载设备：不要尝试 mount -o remount,rw 或继续运行服务；只读挂载也不建议，因内核可能触发后台日志回放
- 对整块磁盘做扇区级只读镜像：用 ddrescue 或 cat /dev/sdX > disk.img（确保目标空间充足），所有操作基于镜像进行
- 导出元数据快照：在镜像上运行 xfs_metadump -o /tmp/meta.img /dev/loop0，为后续人工分析留底
修复后如何评估实际恢复量
别只看 xfs_repair 是否返回 success，要分层验证：
- 基础可用性：能否 mount -t xfs -o ro /dev/mapper/centos-root /mnt？只读挂载成功是底线
- 目录结构完整性：ls -lR /mnt | wc -l 对比正常系统估算层级深度；重点检查 /etc/passwd、/var/log/messages 是否可读
- 关键业务数据抽样：打开数据库目录下的 .ibd 文件头、Web 目录里的 index.html、最近3天的日志片段，确认内容未乱码或截断
- 隐式损坏排查：运行 xfs_db -c "sb 0" -c "p" /dev/mapper/centos-root 检查 LSN 值是否异常跳变，提示日志已强制丢弃
不复杂但容易忽略：元数据错误不是“修好就能用”，而是“修完要逐层验”。能抢救多少，一半靠磁盘状态，一半靠你动手前那十分钟有没有冷静下来做镜像。
