近期接手一个怪异的数据恢复案例,基本环境是: HP-UX小型机连接HP EVA存储,从EVA上划分1TB的逻辑卷(LUN)给HP-UX小型机使用,LVM逻辑结构是一个VG中只包含1TB的物理硬盘(PV),在这个VG中划分出13个LV。
故障现象:这个小机是生产环境下使用的,某天下午 3点多钟发现客户端访问不了,检查服务器,发现oracle数据库所在的文件系统全部mount不上,oracle数据库因此全部停止。由于数据库备份是半个月之前的,丢掉的十几天的数据,如果不能及时找回来,接下来的补救工作将是十分繁重的,因为这涉及到整个工厂的生产业务。
客户首先请到 HP原厂资深工程师从美国进行远程分析,经过彻夜分析,发现存储本身没有问题,损坏的oravg是逻辑层的问题,从LVM深层次分析,发现LVM信息全部被破坏,唯一的办法是重构LVM信息,而且重构的前提是有oravg信息备份。运气还好,找到前一个月的VG备份信息oravg.conf.old文件,通过vgrestore命令,把VG新息还原到了出问题的PV上,最后结果,4个LV能mount上,如下:
/dev/oravg/lv102_64 Good
/dev/oravg/lvK12 Bad
/dev/oravg/lvK12_102_64 Good
/dev/oravg/lvmirrlogA Bad
/dev/oravg/lvmirrlogB Bad
/dev/oravg/lvoraarch` Bad
/dev/oravg/lvoriglogA Bad
/dev/oravg/lvoriglogB Bad
/dev/oravg/lvsapreorg Bad
/dev/oravg/lvsapdata1 Good
/dev/oravg/lvsapdata2 Good
/dev/oravg/lvsapdata3 Bad
/dev/oravg/lvsapdata4 Bad
其余 9个LV没能正常mount,按照用户的说法,在这一个月时间内,这个VG内的LV没有进行过扩容或者收缩,那么这个VG信息备份文件oravg.conf.old提供的信息是正常的,不正常的就是LV上的数据了。
因为用户需要恢复的重要数据是 oracle数据库,如果我能把oracle数据库表空间文件提取出来,那数据恢复就能取得成功。我们把重点工作放在/dev/oravg/lvsapdata3和/dev/oravg/lvsapdata4这两个LV上,按照oracle数据库页面特征对整个1TB的逻辑卷进行扫描收集信息,把收集到的信息进行二次整理,找出丢失掉的oracle表空间文件。分析的结果是我们在整个1TB的LUN中找到两套Oracle实例,一套实例名称 是K13,一套实例名称是K12,K13的实例保留的相对完整,K12受破坏比较严重。经过跟客户核实发现,K13数据库实例是一个月之前他们做的一个测试系统,测试完成以后,就把数据迁移到生产系统K12实例上了,然后把K13实例全部删除掉。
从收集到的 oracle数据库页面分布结果看,K12数据库实例受损严重,要完整恢复几乎不可能,就算要50%恢复也不理想,所以最后就宣布数据恢复失败。
造成数据严重破坏的原因我们一直在讨论,造成破坏的现象是:数据遭受破坏地方,几乎是被符合 oracle数据页面结构的数据写入的,数据写入的方式不是在文件系统环境中写入,而是跳出文件系统层面直接以dd的方式或者以oracle裸设备方式写入。就我个人角度出发,要么是恶意的数据破坏操作,用某个oracle表空间文件dd到某些文件系统;要么是oracle本身的bug,在申请数据空间的时候出现指针错误而写入错误的地方。
一下附加 oravg信息:
# vgdisplay -v /dev/oravg
--- Volume groups ---
VG Name /dev/oravg
VG Write Access read/write
VG Status available
Max LV 2047
Cur LV 13
Open LV 13
Cur Snapshot LV 0
Max PV 2048
Cur PV 1
Act PV 1
Max PE per PV 1023975
VGDA 2
PE Size (Mbytes) 1
Unshare unit size (Kbytes) 1024
Total PE 1023975
Alloc PE 765952
Current pre-allocated PE 0
Free PE 258023
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 2.2
VG Max Size 1023975m
VG Max Extents 1023975
Cur Snapshot Capacity 0p
Max Snapshot Capacity 1023975m
---Logical volumes ---
LVName /dev/oravg/lvK12
LVStatus available/syncd
LVSize (Mbytes) 20480
Current LE 20480
Allocated PE 20480
UsedPV 1
LVName /dev/oravg/lvoraarch
LVStatus available/syncd
LVSize (Mbytes) 30720
Current LE 30720
Allocated PE 30720
UsedPV 1
LVName /dev/oravg/lvmirrlogA
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvmirrlogB
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvoriglogA
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvoriglogB
LVStatus available/syncd
LVSize (Mbytes) 2048
Current LE 2048
Allocated PE 2048
UsedPV 1
LVName /dev/oravg/lvsapreorg
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
LVName /dev/oravg/lvsapdata3
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LV Name /dev/oravg/lvsapdata4
LVStatus available/syncd
LVSize (Mbytes) 184320
Current LE 184320
Allocated PE 184320
UsedPV 1
LVName /dev/oravg/lvsapdata1
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LVName /dev/oravg/lvsapdata2
LVStatus available/syncd
LVSize (Mbytes) 163840
Current LE 163840
Allocated PE 163840
UsedPV 1
LVName /dev/oravg/lvK12_102_64
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
LVName /dev/oravg/lv102_64
LVStatus available/syncd
LVSize (Mbytes) 10240
Current LE 10240
Allocated PE 10240
UsedPV 1
---Physical volumes ---
PVName /dev/dsk/c12t0d1
PVName /dev/dsk/c14t0d1Alternate Link
PVName /dev/dsk/c4t0d1 Alternate Link
PVName /dev/dsk/c6t0d1 Alternate Link
PVName /dev/dsk/c24t0d1 Alternate Link
PVName /dev/dsk/c26t0d1Alternate Link
PVName /dev/dsk/c20t0d1Alternate Link
PVName /dev/dsk/c22t0d1Alternate Link
PVStatus available
TotalPE 1023975
FreePE 258023
Current pre-allocated PE 0
Autoswitch On

Proactive Polling On