存储数据恢复案例误操作删除lun-Netapp的数据恢复
Posted 宋国建
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了存储数据恢复案例误操作删除lun-Netapp的数据恢复相关的知识,希望对你有一定的参考价值。
环境:
存储NETAPP
型号FAS3220
硬盘600G SAS 520字节硬盘 72块
共2个机头,一个扩展柜,共3组raid
故障:
误操作删除10个1T lun和1个5T lun
数据恢复流程:
为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏,首先要为每块磁盘做完全镜像。此后所有恢复操作都在镜像盘上进行, 杜绝对原始磁盘数据造成破坏。
1、经过北亚数据恢复工程师讨论后,最终出具数据恢复方案:
第一步,分析盘序和LVM的组成方式;
第二步,扫描硬盘内的所有节点(一般只扫描“MBFI”,即用户节点)
第三步,在节点扫描结果中找到文件大小符合需求的节点并提取此节点uid相同,事务号最大的作为索引根;
第四步,根据索引根内的第一级数据指针提取本文件的所有直接数据指针(需要参考节点中0x03位置的MAP深度,为0x00时直接从节点内提取数据,0x01时需要提取一次MAP,0x02时需要提取两次MAP......)。在指针提取完毕后开始提取文件数据。
2、分析超级块
在盘头位置找到超级块
从超级块中得到磁盘组名字,磁盘组的逻辑起始块号,总块数,磁盘组中raid的编号
netapp超级块
3、去除校验盘
每个数据块占8个扇区,数据块后附加64字节数据块描述信息。根据这些信息可以判断出哪些磁盘是校验盘(提取数据时校验盘需剔除)
0x10:6字节为aggr_data块号
如果0x10处为FFFF表示校验块
校验块描述信息样例
4、aggr盘序分析
盘序分析时主要依据每块磁盘8号扇区的磁盘信息以及磁盘末尾的RAID盘序表确定盘序。首先要确定各个磁盘所属aggr组,然后再判断组内盘序。数据指针跳转时不考虑校验盘,所以只取得数据盘的盘序即可。
aggr_raid(磁盘靠近尾部) 根据10H处的VCN块号判断磁盘组内各盘的顺序
netapp盘序表
5、节点及节点头部信息
Netapp的节点分布在数量众多的数据块内,在数据块内又被统一组织为节点组。每个节点组的前64字节记录一些系统数据,之后用192字节为一项记录各个文件节点。根据用户级别可分为两类:“MBFP”系统文件节点和“MBFI”用户文件节点,在数据恢复时一般只取MBFI节点组即可。
netapp节点样例图
头部信息64字节
解析如下:(此头部为数据文件的节点文件块头部,大小为64字节)
标志,常量(“MBFP”为元文件的节点标志,“MBFI”为用户文件的节点标志)
根据更新序列值获取到最新节点
解析节点中节点类型,逻辑块号,文件数量,文件大小,所占块数量,及数据指针
获取节点在节点文件中的逻辑块号,从0开始计数
6、获取目录项,并根据其节点编号,找到对应节点
编写数据提取程序
数据提取程序按照功能分为3步,分别为节点扫描、信息录入和数据提取。
1、扫描节点信息
节点扫描类
节点扫描程序完整流程
在循环扫描完毕之后会将所有扫描到的MBFP、MBFI和DOC数据块分别写入到三个文件内,用于后续处理。
2、将节点信息导入到数据库
此模块主要负责将ScanNode扫描得到的MBFI和MBFP、Dir存入数据库以备后续使用。
以下是流程:
MBFI导入数据库整体流程
函数执行完毕后可以查看数据库得到如下信息:
节点导入信息
Netapp在更改inode节点时不会直接覆盖而是重新分配inode进行写入。单个文件的节点node_uid唯一不变,mbfi_usn会随着节点的变化而增大(正常情况下提取某个文件时使用usn最大的节点)。一般情况下存储划分出的单个节点会作为LUN映射到服务器使用,根据file_size可以确定这个文件的大小,按照文件大小分组后再选取usn最大值的节点,跳转到MBFI文件的offset值偏移位置,取出节点。
节点样例
3、提取文件
在获取到要提取的文件的Node之后,开始提取块设备文件。
程序需要读取配置文件:
初始化完毕后,开始提取文件的各级MAP,在本次提取过程中文件大小均大于1T,MAP层级为4,所以需要提取4次。第一级MAP默认只占用1个块,所以在程序内直接提取,后三级MAP在GetAllMap函数内进行提取。通过块号计算数据块位置时,由于NetApp使用JBOD组织LVM,直接用块号除以每块磁盘上的块数可得到当前块所在的磁盘序号(计算机整数除法,丢弃小数邠);再使用块号取余块数,得到数据块在此磁盘上的物理块号,物理块号乘以块大小,得到数据块偏移位置。
数据库检测
搭建小机环境,安装oracle数据库,检测数据库文件和备份文件。
1、检测数据库文件
使用提取出的数据库文件启动数据库,启动失败
经检测该数据库文件存在坏块,无法使用
2、检测数据库备份文件
由于客户设定的数据库备份机制,每个数据库都存在多个备份。
因此先筛选出最新的数据库备份文件,使用筛选出的备份文件还原数据库,经过一一尝试,筛选出最新的可用的数据库备份,还原数据库环境,由客户进行验证。
验证及数据移交
对恢复完成的数据库进行验证,数据库中有少量的数据缺失,缺失量在可接受的范围内。
经过3天左右的验证,对数据库恢复确认无误,此次数据恢复工作圆满成功。
以上是关于存储数据恢复案例误操作删除lun-Netapp的数据恢复的主要内容,如果未能解决你的问题,请参考以下文章
服务器数据恢复IBM某型号服务器VMware虚拟机误删除的数据恢复案例