如何配置ASM元数据备份_md_backup与md_restore重建磁盘组结构-Oracle-PHP中文网

md_backup生成的文件不能直接用md_restore恢复磁盘组，因为它仅备份ASM元数据（如磁盘头、AU位图、目录结构），不含实际数据块；md_restore仅重建磁盘组结构（名称、冗余、AU大小等），无法还原文件内容，故执行后v$asm_file为空属正常设计。

为什么 `md_backup` 生成的文件不能直接用 `md_restore` 恢复磁盘组

因为 md_backup 默认只保存元数据快照（如 asm disk header、au 分配位图、file directory 结构），不包含实际数据块内容；而 md_restore 只能重建磁盘组结构（disk group name、failure group、au_size、compatible.asm 等），无法还原已删除或损坏的文件。常见错误是执行完 md_restore 后发现 v$asm_file 为空，或 asmcmd ls 看不到任何文件——这不是命令失败，而是设计如此。

实操建议：

md_backup 必须在磁盘组仍 online 且未发生严重 corruption 时定期执行，推荐配合 crontab 每日一次：
```
asmcmd md_backup /backup/asm_dg1_$(date +\%F).bak -G DG1
```
md_restore 前必须确保所有原始磁盘设备路径可用、权限正确（oracle:oinstall 可读）、且未被其他 ASM 实例占用
若原磁盘组使用了非默认 au_size（比如 4M 或 8M），备份文件里虽记录该值，但 md_restore 不会自动应用——必须显式加 -au_size 参数，否则重建后磁盘组无法 mount

执行 `md_restore` 时哪些参数漏掉会导致 mount 失败

最常踩的坑是忽略磁盘路径映射和兼容性版本。ASM 不会从备份文件里自动推断物理磁盘位置，也不会继承原环境的 compatible.asm 设置。

实操建议：

必须用 -n 显式指定新磁盘组名（即使和原名相同），否则默认创建为 RESTORED_DG

必须用 -d 列出全部目标磁盘路径，顺序无关，但数量必须与原磁盘组一致；例如原 DG1 有 3 块盘：

md_restore -G DG1 -n DG1 -d '/dev/oracleasm/disks/DISK01' -d '/dev/oracleasm/disks/DISK02' -d '/dev/oracleasm/disks/DISK03' /backup/asm_dg1_2024-06-15.bak

如果原磁盘组设置过 compatible.asm='12.1.0.0.0'，恢复时需加 -c '12.1.0.0.0'，否则可能报错 ORA-15018: diskgroup cannot be created 或挂载时报 ORA-15032: not all alterations performed

`md_restore` 成功但磁盘组 mount 不上，怎么快速定位

成功执行 md_restore 只代表元数据结构写入磁盘头，不代表能 mount。典型现象是 alter diskgroup DG1 mount 卡住或报 ORA-15033/ORA-15040。

实操建议：

立刻检查 asmcmd lsdsk -k：若显示 HEADER_STATUS = MEMBER 但 MODE_STATUS = OFFLINE，说明磁盘头已写但 ASM 实例未识别其归属，大概率是 -d 指定的路径与当前系统中实际设备路径不一致（比如用了 udev 别名但备份时用的是 /dev/sdb）
查 alert.log，搜索关键词 ERROR 和 WARNING，重点关注 disk header validation 和 failgroup mismatch —— 这往往意味着 failure group 定义在备份时和恢复时不匹配（比如原配置为 NORMAL 冗余但恢复时少指定了一个 failure group）
用 kfed read 抽样检查一块磁盘头：
```
kfed read /dev/oracleasm/disks/DISK01 | grep -E "(kfbh.type|kfdhdb.dskname|kfdhdb.grpname|kfdhdb.fgname)"
```
确认 kfdhdb.grpname 是否为预期值，kfbh.type 是否为 1（KFBTYP_DISKHEAD）

能否用 `md_backup` + `md_restore` 替代 RMAN 备份整个数据库

不能。这是最容易混淆的点：md_backup 不是数据备份工具，它只管 ASM 元数据“骨架”，不管 Oracle 数据文件里的“血肉”。哪怕你完整恢复了磁盘组结构，里面所有数据文件仍是空壳或残留旧版本。

实操建议：

把 md_backup 当作“ASM 配置保险丝”，只用于灾难恢复初期重建磁盘组容器；真正保护数据，必须依赖 RMAN 对数据库做全量+归档备份
若磁盘组已损坏且无 RMAN 备份，仅靠 md_restore 无法找回表数据；此时唯一希望是磁盘物理可读 + 使用 dd 镜像 + amdu 提取文件，但成功率极低，且不保证一致性
生产环境务必开启 _asm_allow_only_raw_disks=FALSE 并禁用裸设备直写，否则 md_backup 可能漏掉某些手工写入的元数据变更

真正麻烦的地方在于：备份文件本身不校验完整性，md_backup 执行成功不等于内容可用；恢复前没法预演，只能试 mount。所以每次更新磁盘组结构（比如 add disk、drop disk、rebalance）后，都应该立即补一次 md_backup。