SAN LUN Mapping出错导致文件系统共享冲突,数据恢复成功

【用户单位】

中国联通某分公司

【数据恢复故障描述】

SUN 光纤存储系统,中心存储为6枚300G硬盘组成的RAID6,划分为若干LUN,MAP到不同业务的服务器上,服务器上运行SUN SOLARIS操作系统。

正常工作状态下,用户需要新增应用,所以增加了一台IBM服务器,之后在线状态下将存储中的某个LUN映射到新增的IBM服务器,不料,映射的卷是原先已经MAP到SOLARIS生产系统上的某个LUN上了,由于并未及时发现,IBM服务器上已经对此LUN进行了部分初始化操作(操作不详),之后SOLARIS上磁盘报错,重启后发现问题,卷无法挂载。

SUN工程师检测后,执行fsck,完成后文件系统可挂上,但很多数据丢失或大小变为0,尤其最新数据破坏严重。

【数据恢复故障分析】

SAN环境下此类故障较为常见,但多数是人为不小心导致,此故障也是如此。正常情况下,SAN分配出来的LUN是独占模式的,如果同时为几个操作系统所控制,极易导致写操作不互斥,导致文件系统一致性出错。

如果要恢复此部分数据,需要深入文件系统,考察其各结构的破坏情况。本例中,因文件系统采用UFS,所以对任何一个需要恢复的文件而言,优先考虑目录信息、节点、数据区是否正常,如上述3个结构均正常,数据可完整恢复。但多数情况下,fsck后INODE会清除,即使留下目录信息,也无法与数据一一对应,这时候,就只能参考文件内部格式进行类型式的恢复了。

【数据恢复过程】

1、完整备份故障卷,因RAID无故障,所以直接在SOLARIS环境中对原LUN做dd备份。

2、在备份中分析文件系统,确定需恢复文件的inode已经全部清除,无法还原。只好按文件类型进行处理。

3、对用户需要恢复的特定文件进行分析,发现采用vfs公文系统的索引文件具有强的类型特征,同时文件中包含目录信息。

4、按照公文系统的索引结构特征,写程序提取,提取后根据特征重新命名。

5、按类型恢复数据文件,之后用户人工根据索引文件,对数据文件进行重新整理。

【数据恢复结论】

历时24小时,目录索引文件99%恢复成功,数据文件大部分恢复成功,其余已破坏无法恢复的文件,用户根据目录索引文件重新向其他部门采集。

结论上,用户认可数据恢复成功。

时间: 2024-10-12 10:52:26

SAN LUN Mapping出错导致文件系统共享冲突,数据恢复成功的相关文章

SAN LUN Mapping出错导致文件系统共享冲突的数据恢复全过程

[用户单位] 中国联通某分公司 [数据恢复故障描述] SUN 光纤存储系统,中心存储为6枚300G硬盘组成的RAID6,划分为若干LUN,MAP到不同业务的服务器上,服务器上运行SUN SOLARIS操作系统. 正常工作状态下,用户需要新增应用,所以增加了一台IBM服务器,之后在线状态下将存储中的某个LUN映射到新增的IBM服务器,不料,映射的卷是原先已经MAP到SOLARIS生产系统上的某个LUN上了,由于并未及时发现,IBM服务器上已经对此LUN进行了部分初始化操作(操作不详),之后SOLA

分析SAN LUN Mapping出错导致文件系统共享冲突的情况

[数据恢复故障描述]SUN 光纤存储系统,中心存储为6枚300G硬盘组成的RAID6,划分为若干LUN,MAP到不同业务的服务器上,服务器上运行SUN SOLARIS操作系统.正常工作状态下,用户需要新增应用,所以增加了一台IBM服务器,之后在线状态下将存储中的某个LUN映射到新增的IBM服务器,不料,映射的卷是原先已经MAP到SOLARIS生产系统上的某个LUN上了,由于并未及时发现,IBM服务器上已经对此LUN进行了部分初始化操作(操作不详),之后SOLARIS上磁盘报错,重启后发现问题,卷

lun masking,lun mapping zone

我们有了独立的磁盘阵列用了之后,服务器只要看到存储的控制系统,就有可能使用磁盘阵列的磁盘资源,但是磁盘阵列不可能只为某一个服务器来使用,所以他必须管制主机使用某部分磁盘资源.这个管制分为两个部分:一部分就是lun mapping,类似于绿色通道,就是保证服务器能看到某部分存储资源,一部分就是lun masking,类似于警戒线,就是保证服务器只可访问给它分配的存储资源,而没分配给服务器的资源,就不要染指了. http://blog.sina.com.cn/s/blog_6b7ae4270101m

EXT3文件系统误删除导致文件系统中的邮件丢失恢复方法

一.故障描述 由8块盘组成的RAID5, 上层是EXT3文件系统,由于误删除导致文件系统中的邮件丢失 二.镜像磁盘为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏, 使用winhex软件为每块磁盘做镜像, 以后所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘造成影响镜像结果如下:图一 三.组建RAID通过分析数据在硬盘中分布的规律, 获取RAID类型, RAID条带的大小,以及每块磁盘的顺序.根据分析结果使用UFS组建RAID.结果如下:图二 四.导出目标分区 从组建好的RAID中可以看

真实案例:异常断电导致虚拟机无法启动恢复成功

虚拟机数据恢复故障: 发生故障的存储设备是某品牌存储 EVA8400型号,由于机房意外断电导致该存储中的一台VMware虚拟机无法启动(虚拟机中存储了oracle数据库),管理员清空cache并尝试重新启动该虚拟机但失败了.需要对该无法启动的虚拟机进行数据恢复. 虚拟机数据恢复流程:1)合并虚拟机快照 由于VMware虚拟机的快照原理是虚拟机的快照文件一旦被创建则之后的数据更新都只在快照文件里面发生,并且该虚拟机存在有两个快照文件.所以本次虚拟机数据恢复的第一步为将两个虚拟机快照进行合并,然后才

ERP软件数据库覆盖数据恢复成功/重装数据库系统软件,导致同名文件覆盖

ERP软件数据库覆盖数据恢复成功/重装数据库系统软件,导致同名文件覆盖   [数据恢复故障描述]上海某酒店ERP软件原来安装在C盘上,用户误操作把软件进行了卸载,发现软件没有了, 但操作之前没有把原来的数据库文件复制出来,没有备份,重装好后,又把新的同名数据库安装到原来的路径下,造成了同名数据库文件覆盖. 然后自己尝试用一年前的账套备份进行了还原.发现数据不对,客户没有再乱动.客户找到了软件售后,售后无法恢复,又在当地找了一家数据恢复公司,恢复之后数据还是对不起帐来.最后经过网上搜索,联系到我们

SELINUX导致数据修改权限不成功

SELINUX导致数据修改权限不成功基本概念参考:https://blog.csdn.net/yanjun821126/article/details/80828908 查看SELinux状态: 1./usr/sbin/sestatus -v ##如果SELinux status参数为enabled即为开启状态 SELinux status: enabled 2.getenforce ##也可以用这个命令检查 关闭SELinux: 1.临时关闭(不用重启机器): setenforce 0 ##设

爬坑PIL,文件名Image与类Image()重名,导致引用new,open不成功,报错 type object 'Image' has no attribute 'new'

网上的东西真坑人啊 在知乎里看到的最有意思的python项目,于是选了一个qrcode二维码的项目来自己尝试 github里下载到pycharm之后就开始了踩坑之路. 先说安装pillow 升级pip到19.2.3版本之后,安装pillow(pip install pillow) 之后尝试导入 import Pillow / import pillow / import PIL 死活没有,我很纳闷.卸了重装都没效果依旧导入失败. 然后手动查找到底有没有,于是打开site-package. 大爷的

一个NFS缓存管理包的bug导致文件系统满的问题和解决方法

这几天安装CentOS 6的虚拟机总是提示文件系统满,一开始以为是最近oracle经常操作大数据量提交导致undo tbs无限扩大,后来发现原来是NFS缓存管理包cachefilesd的问题.分享一下: 由于是测试虚拟机,文件系统懒得专门规划,只划分了一个根目录分区.(各位admin切记不要犯这种实际生产环境的大忌): [[email protected]* /]df -h Filesystem            Size  Used Avail Use% Mounted on /dev/m