近期接手一个怪异的数据恢复案例，基本环境是：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