近期接手一个怪异的数据恢复案例,基本环境是:
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
转载于:https://blog.51cto.com/199818/862636