标签归档：asm disk dd恢复

dd破坏包含50多个pdb的asm 磁盘组恢复

发表于 2026 年 6 月 27 日由惜分飞

前段时间刚刚恢复了一个客户dd了34个磁盘中的2个磁盘的1-2G多的数据（在生产环境错误执行dd命令破坏asm磁盘故障恢复），这次又遇到一个客户dd了asm 的两个磁盘的100m和10m，这次故障麻烦的是由于dd了disk 0和disk 1，ausize为4M，有50多个pdb在该磁盘组中，相对恢复比较麻烦，通过不懈努力，最后终于最大限度恢复客户数据，避免了进一步的损失
故障误操作
近期又一个可以误执行了dd命令，破坏了生产库的两个asm disk磁盘

上述截图中可以确认两个信息
1.sdh盘被dd掉了10m，sdg盘被dd掉了100M
2.sdg对应的是asm-data1，sdh对应的是asm-data2
dd误操作之后，data磁盘组开始报错，然后直接dismount.

分析原磁盘组中asm磁盘情况
1.确定损坏磁盘在磁盘组中位置
通过asm的alert日志分析损坏的盘对应的磁盘组信息

基于这个信息，我们可以确认asm-data1 对应的是DATA磁盘组的disk 0，asm-data2对应的是DATA磁盘组的disk 1，也就是说现在DATA磁盘组的0号盘被dd了100M，1号盘被dd了10m
2.确认ausize大小
通过分析该磁盘组的其他磁盘确认ausize大小
kfdhdb.ausize: 4194304 ; 0x0bc: 0×00400000
可以确认该磁盘组的au大小为4M
3.磁盘组后续进行了一次加盘扩容

在25年6月份，对data磁盘组加了三块盘
4.sdh(asm-data2)磁盘还被加入到了arch磁盘组中

比较幸运由于在另外一个节点上sdh磁盘权限没有正确修改，导致该增加没有完全成功，也就是该磁盘没有被reblance（如果加入成功并正常reblance，那后果比现在严重很多）
5.通过结合asm日志以及kfed，磁盘物理大小等信息，并且通过kfed构造出来损坏的磁盘头信息，列出故障之前DATA磁盘组所有磁盘的情况（为了避免udev别名带来的影响，我直接使用物理磁盘名称来显示）

客户现场情况说明
1.客户有一个大概1年多之前的dataguard（后续没有继续同步），已经进行了failover激活
2.客户的备份系统中有一个大概1个月之前的备份，但是备份库缺少归档，我接手之时，已经被维护厂商强制拉起
3.在我恢复之前，有专业的工程师已经对其这个现场进行了分析，但是没有拿出好的恢复方案
恢复难点说明
1.该磁盘组的disk 0 被dd掉了100M，这个导致kfdhdb.f1b1locn记录被清空，也就无法获取到存储指向ASM file 1 文件目录表，这个值虽然被清空，但是根据经验或者对比其他磁盘组的disk 0 可以确认指定aun为10
2.f1b1locn指向的au中存储中asm元数据1-255以及256-1023的file的前面60个au的extent映射表，由于这个在aun为10（也就是aun*aus=40M）的位置，但是这个位置也已经被dd掉了，从原理上业务文件256-1023的前面60个au的extent映射表彻底丢失
3.通过工具扫描，发现存储别名信息的au也在disk 0的前面100M之内(也被dd掉了),导致通过别名直接定位文件的起点的恢复思路也不可行，而且别名丢失导致以别名的数据文件后续识别有一定的难度（无法获取asm里面文件的完整路径）
4.该库有50多套pdb组成，也就意味着通过数据库碎片扫描的方式无法恢复（因为每个pdb里面都是由默认的种子创建而成，也就意味着rfile 1,4,9是重复的）
5.由于中途加过一次磁盘，因引起这个asm里面的文件进行重新reblance，使得部分文件同一个block记录在不同磁盘的au上(数据文件块可能重复)
6.由于该磁盘组中asm disk 大小不等，导致文件au分布在各个磁盘上不均匀，无明显规律可循
恢复操作
1.通过kfed对损坏的asm-data1、asm-disk2的磁盘头进行构造，便于后续的恢复工具识别
2.通过工具对data中所有磁盘进行扫描，主要扫描文件extent映射表信息和ACD中关于asm文件的分配信息
2.1> 通过对这些信息进行综合分析，确认asm file >=1024的文件的extent映射表信息完整，数据可以直接恢复，效果类似

2.2> 对于256-1023号文件通过asm file的extent信息缺少0-59 au的数据，结合acd中获取的部分au分配信息，可以尽可能完整的恢复出来这些数据(由于disk 0中的acd信息丢失,所以不是100%完整)

3.对于绝对文件号非1,4,9的文件，而且asm file 小于1024的数据文件，结合rdba碎片重组的方式再一次进行恢复，避免上面2.2中恢复中前面240M(60个au)，有部分au信息丢失导致文件不完整的情况
通过上述多种方法恢复，整体恢复数据文件类似（由于文件较多，存放多个目录和根据规则取了多种名字）

4.由于asm的文件目录，别名信息全部丢失，而且该库有50多个pdb，无法确认恢复出来的上千个文件和pdb对应的关系，对于这种情况，临时写了一个小程序，对这些文件进行读取，获取file#,rfile#,ts#,tsname,文件大小,dbid,dbname,scn等信息(obet(Oracle Block Editor Tool)第二版发布