[摘要]
中国联通信息平台，海南分部，HP-UX小型机，重要的ORACLE数据库被工程师误RM掉了，丢失所有数据表、UNDO、LOG等。卷文件系统为VxFS，卷大小约50G，数据总量为23G左右。灾难异常重大。
用户非常谨慎，完全不惜成本，但多数公司无法提供解决方案。甚至于大多数数据恢复公司并无HP-UX下的数据恢复案例及经验。客户造访了几家号称国家性质及名头很响的数据恢复公司，最后这几家公司均在访谈中不得不承认没有目标及解决方案，只能试试，有几家干脆直接宣告做不了。
用户来到我公司后，将现象完整描述后，我们提供至少两种解决方案。因之前类似的案例很多，且用户不惜成本，没必要隐瞒故障情况，所以我们给出的结论是：最次的情况，数据也将在多花时间与精力的前提下100%恢复成功。
用户非常激动，马上决定由我公司完成此次数据恢复工作，并责令全部参与此事的员工全力配合。
[分析]
非常典型的，UNIX误删除。此例中数据应该没有被覆盖。
[解决方案]
1、 方案一：通过对文件系统规律性分析，对特定文件的节点进行重建。重现原来文件属性（名称、位置、大小等）
2、 方案二：利用ORACLE数据库本身结构的特性，全盘进行规律性分析及总结，恢复所有ORACLE数据表、LOG及UNDO文件，因ORACLE数据库表头会描述表在ORACLE环境中的名称及大小，故名称问题亦可解决。
[解决过程]
1、 远程登陆到HP-UX系统之后，对故障卷DD操作，输出到另外卷上。
2、 通过FTP传输到WINDOWS平台，马上将目的盘从海南送到北京。
3、 按方案一实施，利用自主数据恢复软件成功分析出除UNDO1外的其他文件节点表，依据节点，将文件全部提取。
4、 按方案二实施，成功恢复所有文件，除UNDO1外，与方案一的结果进行比较，1个字节均不差，由此，或断定除UNDO1外，其余文件100%正确。
5、 因UNDO1并不影响数据，且按方案一结论看，也应该正确。故数据恢复宣告成功。
6、 客户将所有数据库还原回HP-UX系统后，成功启动服务，数据完好无损。总耗时2个工作日。
[给用户的建议]
UNIX及LINUX误删除之后应尽快UMOUNT掉卷，最好直接关掉设备。DD之后再做其他操作。
中国联通信息平台，海南分部，HP-UX小型机，重要的ORACLE数据库被工程师误RM掉了，丢失所有数据表、UNDO、LOG等。卷文件系统为VxFS，卷大小约50G，数据总量为23G左右。灾难异常重大。
用户非常谨慎，完全不惜成本，但多数公司无法提供解决方案。甚至于大多数数据恢复公司并无HP-UX下的数据恢复案例及经验。客户造访了几家号称国家性质及名头很响的数据恢复公司，最后这几家公司均在访谈中不得不承认没有目标及解决方案，只能试试，有几家干脆直接宣告做不了。
用户来到我公司后，将现象完整描述后，我们提供至少两种解决方案。因之前类似的案例很多，且用户不惜成本，没必要隐瞒故障情况，所以我们给出的结论是：最次的情况，数据也将在多花时间与精力的前提下100%恢复成功。
用户非常激动，马上决定由我公司完成此次数据恢复工作，并责令全部参与此事的员工全力配合。
[分析]
非常典型的，UNIX误删除。此例中数据应该没有被覆盖。
[解决方案]
1、 方案一：通过对文件系统规律性分析，对特定文件的节点进行重建。重现原来文件属性（名称、位置、大小等）
2、 方案二：利用ORACLE数据库本身结构的特性，全盘进行规律性分析及总结，恢复所有ORACLE数据表、LOG及UNDO文件，因ORACLE数据库表头会描述表在ORACLE环境中的名称及大小，故名称问题亦可解决。
[解决过程]
1、 远程登陆到HP-UX系统之后，对故障卷DD操作，输出到另外卷上。
2、 通过FTP传输到WINDOWS平台，马上将目的盘从海南送到北京。
3、 按方案一实施，利用自主数据恢复软件成功分析出除UNDO1外的其他文件节点表，依据节点，将文件全部提取。
4、 按方案二实施，成功恢复所有文件，除UNDO1外，与方案一的结果进行比较，1个字节均不差，由此，或断定除UNDO1外，其余文件100%正确。
5、 因UNDO1并不影响数据，且按方案一结论看，也应该正确。故数据恢复宣告成功。
6、 客户将所有数据库还原回HP-UX系统后，成功启动服务，数据完好无损。总耗时2个工作日。
[给用户的建议]
UNIX及LINUX误删除之后应尽快UMOUNT掉卷，最好直接关掉设备。DD之后再做其他操作。
本文转自 张宇 51CTO博客，原文链接：http://blog.51cto.com/zhangyu/33740，如需转载请自行联系原作者
