数据恢复 | 技术站点

闪回技术详解

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

第十四章：闪回技术详解

文档信息

适用版本：Oracle 12c / 18c / 19c / 21c
阅读时间：约 50 分钟
前置知识：第十一章备份与恢复

14.1 闪回技术概述

14.1.1 闪回技术家族

┌─────────────────────────────────────────────────────────────────┐
│                      Oracle 闪回技术体系                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回查询 (Flashback Query)                                 │ │
│  │  • AS OF TIMESTAMP / SCN                                   │ │
│  │  • 查看历史数据                                             │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回版本查询 (Flashback Version Query)                     │ │
│  │  • VERSIONS BETWEEN                                        │ │
│  │  • 查看数据变更历史                                         │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回表 (Flashback Table)                                   │ │
│  │  • 将表恢复到指定时间点                                      │ │
│  │  • 不需要脱机                                               │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回删除 (Flashback Drop)                                  │ │
│  │  • RECYCLEBIN                                              │ │
│  │  • 恢复已删除的表                                           │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回数据库 (Flashback Database)                            │ │
│  │  • 将整个数据库恢复到过去某个时间点                          │ │
│  │  • 代替不完全恢复                                           │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回数据归档 (Flashback Data Archive)                       │ │
│  │  • 长期保留历史数据                                         │ │
│  │  • 可审计跟踪                                               │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

14.1.2 前提条件

-- 必须启用行移动
ALTER TABLE employees ENABLE ROW MOVEMENT;

-- 闪回数据库需要启用闪回日志
ALTER DATABASE FLASHBACK ON;

-- 查看闪回是否启用
SELECT 
    flashback_on,
    log_mode
FROM v$database;

-- 查看回收站
SELECT * FROM USER_RECYCLEBIN;
-- 或
SELECT * FROM RECYCLEBIN;

14.2 闪回查询

14.2.1 基于时间戳的闪回查询

-- 查询过去某个时间点的数据
SELECT * FROM employees AS OF TIMESTAMP 
TO_TIMESTAMP('2024-01-15 10:00:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE department_id = 50;

-- 查询最近 1 小时前的数据
SELECT * FROM employees AS OF TIMESTAMP SYSDATE - 1/24 
WHERE department_id = 50;

-- 查询昨天这个时候
SELECT * FROM employees AS OF TIMESTAMP TRUNC(SYSDATE) - 1 + INTERVAL '14' HOUR;

-- 查看数据变化
SELECT 
    employee_id,
    salary AS current_salary,
    (SELECT salary FROM employees AS OF TIMESTAMP SYSDATE - 1) AS yesterday_salary
FROM employees
WHERE department_id = 50;

14.2.2 基于 SCN 的闪回查询

-- 获取当前 SCN
SELECT TIMESTAMP_TO_SCN(SYSTIMESTAMP) AS current_scn FROM DUAL;

-- 或者
SELECT DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER AS scn FROM DUAL;

-- 基于 SCN 查询
SELECT * FROM employees AS OF SCN 12345678;

-- SCN 与时间戳转换
SELECT SCN_TO_TIMESTAMP(12345678) FROM DUAL;

-- 查看某段时间内的 SCN
SELECT 
    BEGIN_INTERVAL_TIME,
    END_INTERVAL_TIME,
    CHECKPOINT_CHANGE# AS SCN
FROM DBA_HIST_SNAPSHOT
WHERE TIMESTAMP BETWEEN TO_TIMESTAMP('2024-01-15 09:00:00', 'YYYY-MM-DD HH24:MI:SS')
                    AND TO_TIMESTAMP('2024-01-15 10:00:00', 'YYYY-MM-DD HH24:MI:SS');

14.2.3 闪回查询示例

-- 场景：用户误删除数据后恢复

-- 1. 查看删除前的数据
SELECT * FROM employees AS OF TIMESTAMP 
TO_TIMESTAMP('2024-01-15 09:30:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE employee_id = 1000;

-- 2. 恢复数据
INSERT INTO employees
SELECT * FROM employees AS OF TIMESTAMP 
TO_TIMESTAMP('2024-01-15 09:30:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE employee_id = 1000;

-- 3. 或者更新当前数据
UPDATE employees e
SET (salary) = (
    SELECT salary FROM employees AS OF TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 09:30:00', 'YYYY-MM-DD HH24:MI:SS')
    WHERE employee_id = e.employee_id
)
WHERE EXISTS (
    SELECT 1 FROM employees AS OF TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 09:30:00', 'YYYY-MM-DD HH24:MI:SS')
    WHERE employee_id = e.employee_id
);

COMMIT;

14.3 闪回版本查询

14.3.1 闪回版本查询语法

-- 查看一段时间内数据的所有版本
SELECT 
    employee_id,
    first_name,
    salary,
    VERSIONS_OPERATION AS op,  -- I/U/D
    VERSIONS_STARTTIME,
    VERSIONS_ENDTIME,
    VERSIONS_STARTSCN,
    VERSIONS_ENDSCN,
    VERSIONS_XID AS transaction_id
FROM employees
VERSIONS BETWEEN TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 08:00:00', 'YYYY-MM-DD HH24:MI:SS')
    AND TO_TIMESTAMP('2024-01-15 12:00:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE employee_id = 1000
ORDER BY VERSIONS_STARTTIME;

-- 基于 SCN 的版本查询
SELECT 
    employee_id,
    salary,
    VERSIONS_OPERATION,
    VERSIONS_STARTSCN,
    VERSIONS_ENDSCN,
    VERSIONS_XID
FROM employees
VERSIONS BETWEEN SCN 12340000 AND 12350000
WHERE employee_id = 1000;

14.3.2 查询结果解读

┌─────────────────────────────────────────────────────────────────┐
│  VERSIONS BETWEEN 查询结果示例                                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  EMP_ID │ SALARY │ OP │ START_TIME          │ END_TIME          │
│  ───────┼────────┼────┼─────────────────────┼─────────────────────│
│   1000  │  5000  │ U  │ 2024-01-15 10:30:00 │ 2024-01-15 11:00:00│
│   1000  │  4500  │ U  │ 2024-01-15 09:00:00 │ 2024-01-15 10:30:00│
│   1000  │  4000  │ I  │ 2024-01-15 08:00:00 │                    │
│                                                                 │
│  OP: I=INSERT, U=UPDATE, D=DELETE                              │
│  空 END_TIME 表示当前版本                                         │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

14.3.3 恢复误删除的行

-- 查找被删除的行
SELECT * FROM employees
VERSIONS BETWEEN TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 08:00:00', 'YYYY-MM-DD HH24:MI:SS')
    AND SYSTIMESTAMP
WHERE employee_id = 1000
AND VERSIONS_OPERATION = 'D';

-- 恢复已删除的行
INSERT INTO employees (
    SELECT * FROM employees
    VERSIONS BETWEEN TIMESTAMP 
        TO_TIMESTAMP('2024-01-15 08:00:00', 'YYYY-MM-DD HH24:MI:SS')
        AND SYSTIMESTAMP
    WHERE employee_id = 1000
    AND VERSIONS_OPERATION = 'D'
);

14.4 闪回表

14.4.1 闪回表到指定时间

-- 必须启用行移动
ALTER TABLE employees ENABLE ROW MOVEMENT;

-- 闪回表到指定时间点
FLASHBACK TABLE employees TO TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 10:00:00', 'YYYY-MM-DD HH24:MI:SS');

-- 闪回表到 SCN
FLASHBACK TABLE employees TO SCN 12345678;

-- 闪回表到还原点
FLASHBACK TABLE employees TO RESTORE POINT before_upgrade;

-- 闪回前后对比
SELECT * FROM employees AS OF TIMESTAMP SYSDATE - 1;  -- 闪回前
SELECT * FROM employees;  -- 闪回后

14.4.2 闪回表示例

-- 场景：批量更新后需要撤销

-- 1. 创建还原点
CREATE RESTORE POINT before_batch_update;

-- 2. 执行批量更新
UPDATE employees SET salary = salary * 1.1 WHERE department_id = 50;
COMMIT;

-- 3. 发现错误，闪回表
FLASHBACK TABLE employees TO RESTORE POINT before_batch_update;

-- 4. 清理还原点
DROP RESTORE POINT before_batch_update;

-- 查看所有还原点
SELECT 
    NAME,
    SCN,
    TIME,
    GUARANTEE_FLASHBACK_DATABASE
FROM V$RESTORE_POINT;

14.4.3 闪回表限制

限制说明

以下情况不能使用闪回表：

表结构被修改（DDL）
表被删除
表已 Truncate
涉及引用完整性约束（外键）

14.5 闪回删除

14.5.1 回收站机制

-- 查看回收站
SELECT 
    object_name,
    original_name,
    type,
    droptime,
    space
FROM user_recyclebin;

-- 或者使用 DBA_RECYCLEBIN（需要 DBA 权限）
SELECT * FROM DBA_RECYCLEBIN WHERE owner = 'HR';

-- 回收站命名规则
-- BIN$globalUID$version
-- 例如: BIN$ABC123XYZ==$0

14.5.2 恢复删除的表

-- 方式1：使用回收站中原名
FLASHBACK TABLE employees TO BEFORE DROP;

-- 方式2：使用回收站中的名称恢复
FLASHBACK TABLE "BIN$ABC123XYZ==$0" TO BEFORE DROP;

-- 恢复并重命名
FLASHBACK TABLE "BIN$ABC123XYZ==$0" TO BEFORE DROP RENAME TO employees_old;

-- 恢复被删除的表到特定时间
FLASHBACK TABLE employees TO BEFORE DROP 
    TO TIMESTAMP TO_TIMESTAMP('2024-01-15 09:00:00', 'YYYY-MM-DD HH24:MI:SS');

14.5.3 管理回收站

-- 清除回收站
PURGE TABLE employees;  -- 清除特定表
PURGE TABLE "BIN$ABC123XYZ==$0";

-- 清除整个用户回收站
PURGE RECYCLEBIN;

-- DBA 清除所有回收站
PURGE DBA_RECYCLEBIN;

-- 手动删除而不进回收站
DROP TABLE employees PURGE;

-- 禁用回收站（需要 DBA 权限）
ALTER SYSTEM SET recyclebin = OFF SCOPE = SPFILE;

14.6 闪回数据库

14.6.1 闪回数据库原理

┌─────────────────────────────────────────────────────────────────┐
│                      闪回数据库原理                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  前提条件：启用闪回日志                                            │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │  闪回日志 (Flashback Logs)                                  │ │
│  │  • 记录数据块的前镜像                                       │ │
│  │  • 存储在闪回恢复区                                         │ │
│  │  • 自动管理                                                 │ │
│  └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│  恢复过程：                                                       │
│  ┌───────────┐    ┌───────────┐    ┌───────────┐               │
│  │  Flashback │ → │  Redo App │ → │  Open     │               │
│  │  Database  │   │  (可选)   │   │  Resetlogs│               │
│  └───────────┘    └───────────┘    └───────────┘               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

14.6.2 启用闪回数据库

-- 1. 确保数据库处于归档模式
ARCHIVE LOG LIST;

-- 2. 配置闪回恢复区
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u01/app/oracle/fra' SCOPE=SPFILE;
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 100G SCOPE=SPFILE;

-- 3. 启用闪回日志
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

-- 4. 查看闪回配置
SELECT 
    flashback_on,
    retention_target  -- 保留目标（分钟）
FROM v$database;

-- 5. 修改保留时间
ALTER DATABASE FLASHBACK ON RETENTION TARGET TO 1440;  -- 保留 1 天

-- 6. 查看闪回日志使用空间
SELECT 
    ROUND(SPACE_USED/1024/1024/1024, 2) AS used_gb,
    ROUND(SPACE_LIMIT/1024/1024/1024, 2) AS limit_gb
FROM v$recovery_file_dest;

14.6.3 执行闪回数据库

-- 1. 启动到 MOUNT 状态
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

-- 2. 执行闪回（基于时间戳）
FLASHBACK DATABASE TO TIMESTAMP 
    TO_TIMESTAMP('2024-01-15 10:00:00', 'YYYY-MM-DD HH24:MI:SS');

-- 3. 或者基于 SCN
FLASHBACK DATABASE TO SCN 12345678;

-- 4. 或者基于还原点
FLASHBACK DATABASE TO RESTORE POINT before_error;

-- 5. 以只读模式打开验证
ALTER DATABASE OPEN READ ONLY;

-- 6. 如果满意，执行 resetlogs
ALTER DATABASE OPEN RESETLOGS;

-- 7. 如果不满意，继续闪回或执行恢复
--    SHUTDOWN IMMEDIATE
--    STARTUP MOUNT
--    RECOVER DATABASE  -- 使用普通恢复

14.6.4 闪回数据库示例

-- 场景：执行了错误的批量更新

-- 1. 创建还原点（确保闪回可用）
CREATE RESTORE POINT before_bad_batch GUARANTEE FLASHBACK DATABASE;

-- 2. 执行批量更新（发现问题）
BEGIN
    FOR rec IN (SELECT employee_id FROM employees WHERE department_id = 50) LOOP
        UPDATE employees SET salary = 100 WHERE employee_id = rec.employee_id;
    END LOOP;
    COMMIT;
END;
/

-- 3. 所有工资变成 100，立即闪回
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

-- 4. 闪回到还原点
FLASHBACK DATABASE TO RESTORE POINT before_bad_batch;

-- 5. 验证数据
ALTER DATABASE OPEN READ ONLY;
-- 检查工资是否恢复正常
SELECT COUNT(*) FROM employees WHERE salary = 100;  -- 应该为 0
SELECT COUNT(*) FROM employees WHERE salary > 1000; -- 应该有很多

-- 6. 确认无误后打开
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE OPEN RESETLOGS;

-- 7. 清理还原点
DROP RESTORE POINT before_bad_batch;

14.7 闪回数据归档

14.7.1 创建闪回数据归档

-- 1. 创建闪回数据归档表空间
CREATE TABLESPACE fbda_ts
DATAFILE '/u01/app/oracle/oradata/ORCL/fbda01.dbf'
SIZE 1G;

-- 2. 创建闪回数据归档
CREATE FLASHBACK ARCHIVE DEFAULT fbda_1year
TABLESPACE fbda_ts
RETENTION 1 YEAR;

-- 创建不带 DEFAULT 的归档
CREATE FLASHBACK ARCHIVE fbda_2years
TABLESPACE fbda_ts
RETENTION 2 YEAR;

-- 3. 为表启用闪回归档
ALTER TABLE employees FLASHBACK ARCHIVE fbda_1year;

-- 4. 验证
SELECT 
    table_name,
    flashback_archive_name,
    retention_in_days
FROM user_flashback_archive_tables;

-- 5. 查询历史数据
SELECT * FROM employees
AS OF TIMESTAMP TO_TIMESTAMP('2023-01-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS');

-- 6. 禁用表归档
ALTER TABLE employees NO FLASHBACK ARCHIVE;

-- 7. 删除归档
DROP FLASHBACK ARCHIVE fbda_1year;

14.7.2 闪回数据归档查询

-- 查询多年前的员工数据（即使普通 UNDO 已过期）
SELECT 
    employee_id,
    first_name,
    salary,
    hire_date
FROM employees
AS OF TIMESTAMP TO_TIMESTAMP('2020-06-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE department_id = 50;

-- 对比不同时间点的数据
SELECT 
    e1.employee_id,
    e1.salary AS salary_2020,
    e2.salary AS salary_now
FROM 
    (SELECT * FROM employees AS OF TIMESTAMP TO_TIMESTAMP('2020-06-01', 'YYYY-MM-DD')) e1,
    employees e2
WHERE e1.employee_id = e2.employee_id;

14.8 闪回技术与 RMAN 恢复对比

特性	闪回技术	RMAN 恢复
恢复范围	表级/行级	表空间/数据库级
恢复速度	快（秒级）	慢（分钟/小时）
停机时间	极短	较长
数据丢失	闪回时间内无丢失	恢复到备份点
前提条件	UNDO/Flashback Log	备份集
适用场景	误操作恢复	灾难恢复

14.9 本章小结

✅ 闪回查询 (AS OF)：查看历史数据，无需恢复
✅ 闪回版本查询 (VERSIONS BETWEEN)：查看数据变更历史
✅ 闪回表 (FLASHBACK TABLE)：将表恢复到过去某个时间点
✅ 闪回删除 (RECYCLEBIN)：恢复误删除的表
✅ 闪回数据库 (FLASHBACK DATABASE)：将整个数据库恢复到过去
✅ 闪回数据归档：长期保留历史数据（审计追踪）

📖 下章预告：日志挖掘（LogMiner）

下一步：学习

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