AIX下删除LV后的现场保护和数据恢复方案

简介:

   在AIX环境下,因维护误操作、存储mapping错误等,不小心将LV误删除,这种损失通常是巨大的。删除后的不当保护及恢复操作可能使数据无法恢复,也可能增加处理的时间与算法复杂度。如何有效保护现场,并选择正确的数据恢复方案是非常重要的。

 

   AIX的存储层有太多文章描述,做为铺垫,简要描述一下。PV相当于物理磁盘(对于存储,是存储映射过来的卷,对于操作系统而言,等同于物理硬盘),若干个PV组成一个VG,意味着可以将容量不同的存储空间合起来统一分配。为了实现这个目的,AIX把同一个VG的所有PV按相同大小的存储颗粒进行空间编排,这个存储颗粒就是PP。而分配空间时,以若干个PP(可能是不同PV上的),做为使用集合,这个集合就是LV。

    AIX的LVM层VGDA区域有一个固定的PP到LV的映射表,称为PPMAP。每个PV的所有PP从第一个(PP#1)开始,以固定大小的32个字节记录本PP归属于哪个LV。删除AIX中VG的某个LV,底层上最根本的就是释放这个LV原先占用的PP,也就是清0之前所有占用PP的32字节PPMAP条目,另外还会做一些诸如LV名称的清理、LV设备摘要信息的清理等工作。

    LV被删除后,不建议贸然尝试用mklv等操作试图进行灾难恢复。虽然mklv本质上不会清除pp内容区,但有些情况会损坏数据,比如:如果故障前后的PP分配表不相同,但前面PP表分配正确,这样,文件系统可能可以识别,甚至于可以挂上。不过,麻烦的是,挂上后某些结构可能会出现错误,以至于被系统自动修正,事情就会变得更糟。即便是只读方式mount,也不是最优选的做法。

    如果时间允许,AIX LV删除后的恢复方案大致为:

    1、保持VG状态,不新建任何LV。

    2、使用备份手段,对VG中所有的PV做完整镜像。

    3、在镜像中进行数据提取恢复。或保护镜像后以分析好的PPMAP,重建丢失的LV。

    上述方案的宗旨为:所有操作尽可能可回溯。

【如何完整镜像故障卷】

    来说说如何对AIX中的PV做完整镜像(从目前的数据恢复技术看,多数处理和分析过程首选是WINDOWS环境,所以,镜像方案尽量兼顾镜像出来的数据可以在WINDOWS下直接访问):

    第一种方法:如果存储自身有卷镜像功能,可以尝试之。

    第二种方法:如果AIX环境中有足够空间,放得下需要镜像的pv,可以将pv镜像成文件(或LV)。如果是文件,可以通过FTP等手段传出来。(不建议此方法)

    第三种方法:另外构建一台NFS server,以nfs的方式用dd将pv镜像到nfs上。当然如果aix上可以挂载cifs,甚至于直接可以镜像到windows的共享文件夹下。但windows下如果生成大文件,有可能会越来越慢,可以尽量使用WINDOWS2008或选择其他方案。

    第四种方法:建议的方案。具体为构建块设备mapping至aix环境,直接以块设备至块设备的方法进行镜像。可选择的块设备有fc lun,iscsi等。如果不具备fc环境的支撑,至少iscsi(可以是软iscsi)是足够好的方案。

    以windows端做iscsi target,AIX环境做iscsi initiator为例,下面为详细过程:

    1、在配置网络环境,保证AIX与WINDOWS网络可通。

    2、在WINDOWS上搭建ISCSI TARGET,以 下图starwind为例,创建了一个名称为pv0的iscsi磁盘。

clipboard

    3、返回aix平台,确定是否安装iscsi initiator:

        lsdev |grep iscsi,如果提示“iscsi0     Available              iSCSI Protocol Device” 表示ISCSI客户端已经安装,设备号是iscsi0。

        也可以用lslpp -L|grep -i iscsi 确认是否已经安装了ISCSI软件包。

        如未安装,先安装iscsi initiator。

    4、修改aix环境中/etc/iscsi/targets文件,在最后增加一行(本例中windows iscsi target的ip是192.168.1.9,iqn见上图)

        192.168.1.9 3260 iqn.2008-08.com.starwindsoftware:tel-pv0

    5、在aix平台执行cfgmgr -l iscsi0 (见步骤3中的设备号),重新扫描iscsi设备。

    6、lspv 查看是否识别到iscsi设备。本例结果如下:

clipboard[1]

        可以看到hdisk3已经认到,可以使用lsattr -El hdisk3  查看设备详细情况,命令结果为:clipboard[2]

        可以看到明确的iscsi设备细节,还可以通过bootinfo -s hdisk3查看目标iscsi容量是否正确(单位为MB,本例为演示,仅创建了个大小为4GB的ISCSI存储卷)

clipboard[3]

    7、使用dd命令对故障存储做完整镜像(建议使用块设备路径进行镜像):

dd if=/dev/rhdisk0 of=/dev/rhdisk3   bs=4096k   conv=noerror,sync

更详细部分,可参考之前的文章:<如何为IBM AIX的数据卷做完整镜像> 以及 <最全面的关于LINUX与UNIX下的dd命令详解>

【AIX LV误删除数据恢复方案】 
    在完整备份故障PV后,就可以着手恢复数据了。大致有3种方案可对数据进行恢复

    方案一:

        分析得到原LV的PPMAP,之后通过mklv -m <指定的ppmap文件>的方式重建与原先LV相同的分配表,以激活原LV,从而恢复数据。

    方案二:

        分析得到原LV的PPMAP,直接通过第三方软件(北亚开发有WINDOWS端的JFS2文件系统解释软件)进行JFS2文件系统解释。如果是裸设备(RAW),可完整读出后再重新按块写回。

    方案三:

        如果原LV中存储的是ORACLE数据库,可以针对oracle数据文件的特征,以碎片的方式,从所有PP中提取并组合好所有的特定数据文件,再灾难方式恢复oracle系统。










本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/1103101,如需转载请自行联系原作者
目录
相关文章
|
4月前
|
存储
【北亚服务器数据恢复】ZFS文件系统服务器无法进入系统的数据恢复案例
服务器数据恢复环境: 服务器中有32块硬盘,组建了3组RAIDZ,部分磁盘作为热备盘。zfs文件系统。 服务器故障: 服务器运行中突然崩溃,排除断电、进水、异常操作等外部因素。工作人员将服务器重启后发现无法进入操作系统。
【北亚服务器数据恢复】ZFS文件系统服务器无法进入系统的数据恢复案例
|
4月前
|
存储 运维 数据挖掘
服务器数据恢复-DELL EqualLogic PS存储raid5数据恢复案例
服务器数据恢复环境: 一台DELL EqualLogic PS系列存储,存储中有一组由16块SAS硬盘组成的RAID5。上层是VMFS文件系统,存放虚拟机文件。存储上层分了4个卷。 服务器故障&检测: 存储上有2个硬盘指示灯显示黄色,磁盘出现故障导致存储不可用,存储设备已经过保。 硬件工程师对故障存储中的16块硬盘做了硬件故障检测,发现其中有2块磁盘存在坏道,SMART的错误冗余级别已经超过阈值。
服务器数据恢复-DELL EqualLogic PS存储raid5数据恢复案例
|
7月前
|
存储 数据挖掘 Windows
服务器数据恢复-zfs文件系统服务器raidz数据恢复案例
服务器数据恢复环境: 一台服务器共配备32块硬盘,组建了4组RAIDZ,Windows操作系统+zfs文件系统。 服务器故障: 服务器在运行过程中突然崩溃,经过初步检测检测没有发现服务器存在物理故障,重启服务器后故障依旧,需要恢复服务器内的大量数据。
服务器数据恢复-zfs文件系统服务器raidz数据恢复案例
|
4天前
|
存储 Oracle 关系型数据库
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
**服务器存储数据恢复环境:** 某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。 **服务器存储故障&分析:** 该RAID5阵列中一块硬盘出现故障离线,热备盘自动激活替换故障硬盘,热备盘同步数据的过程中该raid5阵列中又有一块硬盘出现故障,RAID5阵列瘫痪,上层LUN无法正常访问。 因为本案例中存储控制器的磁盘检查策略严格,一旦某些磁盘性能不稳定,该型号存储控制器就将该块磁盘识别为坏盘,并将该块磁盘踢出RAID。一旦RAID中掉线的盘数到超过RAID级别允许掉盘的最大数量,该RAID将不可用,
服务器数据恢复—RAID5上层SAP+oracle数据恢复案例
|
3月前
|
存储 Oracle 关系型数据库
【北亚企安数据恢复】服务器ZFS文件系统数据恢复案例
服务器数据恢复环境: ORACLE SUN ZFS某型号存储,共40块磁盘组建存储池,其中的36块磁盘分为三组,每组12块,单个组使用ZFS特有的RAIDZ管理所有磁盘,RAIDZ级别为2;另外的4块磁盘作为全局热备。存储池内划分出若干空间映射到服务器使用。 服务器故障: 服务器正常运行过程中崩溃,服务器管理员重启设备后无法进入系统。通过对服务器和存储的初步检测以及和管理人员的沟通,排除了断电、进水、异常操作等外部因素。
【北亚企安数据恢复】服务器ZFS文件系统数据恢复案例
|
4月前
|
存储 运维
服务器数据恢复-EMC存储ZFS文件系统下raid5数据恢复案例
一台emc某型号存储服务器,存储服务器上组建了一组raid5磁盘阵列,阵列中有两块磁盘作为热备盘使用。存储服务器在运行过程中有两块磁盘出现故障离线,但是只有一块热备盘激活,最终导致该raid5阵列崩溃,上层应用无法正常使用。
|
4月前
|
存储 数据挖掘 数据库
服务器数据恢复—ocfs2文件系统数据恢复案例
由于工作人员的误操作,将Ext4文件系统误装入到存储中Ocfs2文件系统数据卷上,导致原Ocfs2文件系统被格式化为Ext4文件系统。 由于Ext4文件系统每隔几百兆就会写入文件系统的原始信息,原Ocfs2文件系统数据会遭受一定程度的破坏,但破坏的应该不太多。
服务器数据恢复—ocfs2文件系统数据恢复案例