数据:“最后我还想再拜托你一件事,希望你可以把我忘掉”
本人最近三个月之内经历了三次阵列崩溃,其中第一次损失了0.2TB,第二次算是因为第一次损失了一点点,第三次没有损失完美恢复
也是和阵列打交道多年了,也算是一点自己的经验之谈,给大家做参考。
警告!!! 请根据自己实际情况以及数据重要性来选择如何处理和操作,不要一味的按照本教程执行,本人不对按照本教程操作丢失的数据负任何责任!!
在质保期内用户,请优先寻找官方工程师
操作时请佩戴防静电手套或者手环,以免二次伤害!
本教程仅适用于阵列完全进入Failed状态,而不是Degraded状态,如果在Degraded状态那么说明数据还可读,请优先将数据提取出来,再进行任何操作!
但是非官方硬盘就算了,找了也是白搭,不如说是找打,比如说买了DELL的服务器不用官方的硬盘自己买往上塞,搞不好会失去整机的质保,因为用了“非官方配件”
如果你看到了本文,那么有以下几种情况:励志成为专业运维;还没有经历过,想了解一下;经历过,但是没有完美解决;正在经历,不知道该怎么办。
不管是哪种情况,在这里需要声明的是,本文仅为本人的多年经验之谈,并非适用于所有情况,也不保证能100%恢复数据,请当作参考,或者走投无路时使用本教程。
既然选择这一行,那么就要时刻为这天准备着,必须要提前做好心理准备,作为运维最重要的一点就是稳重,万事切忌急,遇到事情第一件事不是陷入焦虑抑郁,而是想这么修复,怎么挽救,怎么补救,怎么把损失降到最小。
# Section End
# Section End
# Section End
在本地也请先进行以下步骤
人在外地,够不着服务器,阵列崩了,怎么办。这可不是说RAID5损坏了一块硬盘,让机房人员换一块就行了,也不是CPU内存什么的坏了关机让现场人员换上就行了
这可是阵列崩了,数据全都要丢了,老婆们要丢了!
除非现场有高水平人才,且可以信任,否则不要让非专业人员进行操作。
# Section End
# Section End
这里分为两种情况,第一种是老型号阵列卡,一般如果之前被removed掉的硬盘在重新检测到之后会变成offline状态;第二种是个别新型号阵列卡,在重新检测到硬盘之后会变成Foreign
先讲第一种,也就是我第一次崩的时候
环境: DELL PowerEdge R510, 阵列卡:DELL PERC H700, 磁盘希捷Ironwolf系列4TB*3 (其他磁盘在此不提)
当时的DELL iDRAC日志:
Critical | Mon Dec 13 2017 17:08:40 | Fault detected on Drive 7. | ||
Critical | Wed Dec 13 2017 17:24:22 | Fault detected on Drive 8. |
下午5点,连着崩盘,收到警告之后还没等反应直接炸了,但是这是存储,并不是系统盘
所以当时系统内xfs刷的错误:
[email protected]****:/var/log# cat messages | grep sdb
Dec 13 17:24:40 **** kernel: [6527894.552003] sd 0:2:1:0: [sdb] Unhandled error code
Dec 13 17:24:40 **** kernel: [6527894.552019] sd 0:2:1:0: [sdb]
Dec 13 17:24:40 **** kernel: [6527894.552026] sd 0:2:1:0: [sdb] CDB:
Dec 13 17:24:40 **** kernel: [6527894.552254] XFS (sdb): xfs_do_force_shutdown(0x2) called from line 1172 of file /build/linux-1wJOX9/linux-3.16.43/fs/xfs/xfs_log.c. Return address = 0xffffffffa05eeede
Dec 13 17:24:40 **** kernel: [6527894.552399] sd 0:2:1:0: [sdb] Unhandled error code
Dec 13 17:24:40 **** kernel: [6527894.552403] sd 0:2:1:0: [sdb]
Dec 13 17:24:40 **** kernel: [6527894.552411] sd 0:2:1:0: [sdb] CDB:
Dec 13 17:24:40 **** kernel: [6527894.552488] sd 0:2:1:0: [sdb] Unhandled error code
Dec 13 17:24:40 **** kernel: [6527894.552490] sd 0:2:1:0: [sdb]
Dec 13 17:24:40 **** kernel: [6527894.552493] sd 0:2:1:0: [sdb] CDB:
Dec 13 17:24:40 **** kernel: [6527894.552566] sd 0:2:1:0: [sdb] Unhandled error code
Dec 13 17:24:40 **** kernel: [6527894.552568] sd 0:2:1:0: [sdb]
Dec 13 17:24:40 **** kernel: [6527894.552571] sd 0:2:1:0: [sdb] CDB:
Dec 13 17:24:40 **** kernel: [6527894.552829] XFS (sdb): xfs_do_force_shutdown(0x2) called from line 1172 of file /build/linux-1wJOX9/linux-3.16.43/fs/xfs/xfs_log.c. Return address = 0xffffffffa05eeede
Dec 13 17:24:40 **** kernel: [6527894.552883] XFS (sdb): xfs_do_force_shutdown(0x2) called from line 1172 of file /build/linux-1wJOX9/linux-3.16.43/fs/xfs/xfs_log.c. Return address = 0xffffffffa05eeede
Dec 13 17:24:40 **** kernel: [6527894.552936] XFS (sdb): xfs_do_force_shutdown(0x2) called from line 1172 of file /build/linux-1wJOX9/linux-3.16.43/fs/xfs/xfs_log.c. Return address = 0xffffffffa05eeede
Dec 13 17:24:45 **** kernel: [6527924.632465] XFS (sdb): xfs_log_force: error 5 returned.
Dec 13 17:25:45 **** kernel: [6527954.713584] XFS (sdb): xfs_log_force: error 5 returned.
Dec 13 17:25:46 **** kernel: [6527984.794638] XFS (sdb): xfs_log_force: error 5 returned.
# ...
嗯,系统直接乱套了,到了之后系统已经关机了,硬盘拔下来看看没有问题插回去
进入阵列卡BIOS
实际上当时是7和8都没了,整个阵列是红的Failed掉了
后来我强行上线了Disk 8
拿这个案例来讲,三块硬盘是RAID5阵列的最低要求,所以我们就拿这个最简单的模型来讲
三块硬盘,分别是Disk 6, Disk 7, Disk 8
一开始三块硬盘都在正常工作,可以fail一块,也就是Redundancy为1
啪,Disk 7不知道为什么,突然没了,直接扔了一个错误,跑路了。
但是不要紧,RAID5可以损失一块硬盘,系统也认为这个物理设备在正常工作,因为他还可写可读,也没有SMART信息,阵列卡也不会告诉系统我这损失了Redundancy你别写了,所以系统仍然在往阵列中写入数据。
但是,啪,Disk 8也不知道为什么,突然没了,也扔了一个错误,跑路了。
这样RAID5阵列整个就报废了,进入Failed状态,系统也意识到这个设备不可读写了,xfs就也炸了,在内存里面的数据,阵列卡缓存里面的数据肯定也都没法写到磁盘里了,所以这一部分数据是肯定要丢的。
现在,整个阵列的数据都不可读了,都完蛋了,你系统里也看不到了,阵列卡里也显示Failed了,一首凉凉送给自己
但是还没完啊!我们还能挽回数据!!!只要硬盘没有物理损伤!!只有这货还能加载磁头!!阵列卡还能认出这块硬盘!就完全大丈夫!
为什么要上线Disk 8而不是Disk 7,想必各位看完我前面的话就知道为什么了吧
因为Disk 7先掉线,很多数据根本就没同步写入到Disk 7中,所以Disk 7跟Disk 6, Disk 8中存储的数据就差的太远了
如果我选择强行上线Disk 7而不是Disk8的话,那么绝对会造成巨大的数据不一致(断片)以及肯定的数据丢失
但是如果上线Disk 8就不一样了,因为他掉线之后整个阵列就不可写也不可读了,所以也不会有新数据写入到阵列中,这时候Disk 6和Disk 8中的大部分数据是同步的,会有极少的不一致性(inconsistency)
所以我选择强行上线Disk 8,而不是Disk 7
需要注意的是,就算是这样,在Operation中选择Force Online的时候也会提示会造成数据不一致性以及潜在的数据丢失的可能性。
强行上线之后,阵列变成黄色, Degraded状态。重启进入系统,mount文件系统,开始转移数据
//我去之前买了一块4TB的西数,带过去配好RAID0开始倒数据
在处理这种磁盘阵列损坏的情况的时候,首先不要慌,评估当前的状态
到场之后确认是不是硬件损坏,如果物理损坏的硬盘数,大于阵列可容忍的数量,那么基本上真的是没救了,如果是公司数据而且公司贼有钱的话,那需要去找开盘提取数据再重新组阵列,而且成功率也不高
非硬件损坏相对于来说更好办,思路就如上所述
强行上线最近掉的一块盘,以此类推,按照硬盘消失的顺序强行上线,
当然间隔时间太长的硬盘就不要强行上线了,妥妥的数据不一致
# Section End
环境: DELL PowerEdge R730xd, 阵列卡:DELL PERC H730P, 磁盘:Intel 240G SSD*6 (其他磁盘在此不提)
//上图Disk 2被我手动拔出来了,为了防止import configuration的时候一起带进去
这次崩溃没有损失任何数据,有一定的运气成分在里面
这次同样是掉了两块盘,第一块掉了之后收到警告邮件马上开始转移数据,转移到一半又一块炸了
这次没截阵列卡的图,拿Lifecycle Log来看看吧,直接Log Type: Storage filter走起
顺序从下往上看,1月17号下午7点36分Disk 2挂了,阵列Degraded,之后阵列卡反复重试reset Disk2
这个消息很有意思,提示工作不正常之后让你去手动拔插一下看看行不行,不行就换硬盘,唉,时代变了,上面那个PERC H700如果拔了插回去就炸毛了,这个还主动让你拔插
PDR3: Disk 2 in Backplane 1 of Integrated RAID Controller 1 is not functioning correctly.
Detailed Description:
The RAID Controller may not be able to read/write data to the physical disk drive indicated in the message. This may be due to a failure with the physical disk drive or because the physical disk drive was removed from the system.
Recommended Action:
Remove and re-insert the physical disk drive identified in the message and make sure the physical disk drive is inserted properly. If the issue persists, replace the physical disk drive.
然后当天晚上10点多点,Disk 4挂了。。。。。。。。。。。
然后我不在现场就先把机器关了,然后上个周我还在感冒发烧,等到20号周末病还没好就打包跑过去了
前面为什么说不要尝试在远程轻举妄动,因为真的贼危险啊,一开始Disk 2掉了之后,阵列卡就标记offline了,结果一重启Disk 2成removed了,Disk 4掉了offline。最后我20号在现场看的时候, Disk 2和Disk 4都成外来户(Foreign)了???????
注意在DELL PERC H730P这种现代阵列卡上,和之前有点不一样,他可以Force online,但是只要他认为你这块盘被拔出去干过其他事,同时又保留着RAID阵列信息,就会认为这块盘是Foreign configuration
这时候不要担心,大胆往前走,直接import foreign configuration,不会覆盖掉剩下这4块盘的阵列,因为剩下这4块盘的标记也留在这个“外来户”的户口里
需要注意,因为Disk 2是先掉的,如果你import foreign configuration的话,因为这俩foreign是一伙的,所以会把Disk 2也拉上一起import,你没有选择的余地,选择import哪个不import哪个,因为阵列卡看来这俩是一个阵列里的,要import就一起import
所以我先关机,把Disk 2拔出来, 开机,import foreign configuration, 进系统,倒数据,导出配置文件,重新做阵列,重新做系统,导入配置文件,重新连接iSCSI,导入数据,完事
当天搞定,中午我爸出去买了盘饺子回来,下午就美滋滋回家了
# Section End
在强行上线硬盘之后,阵列和虚拟磁盘对于系统来讲就是一个看起来正常运转的物理设备了,这时候就可以读取数据了,所以一定要趁现在读取数据。
来讲两个案例,为什么不要运行fsck或者xfs_repair
我们当时在LA又基础设施,当时有一台核心服务器炸了,也是磁盘的问题,最后拖出来的数据七零八碎的,都没眼看了
当时我们家开发在那拖数据,都是些虚拟机镜像和虚拟磁盘,然后就有一台数据库的虚拟机损坏的特别严重
拖出来之后开机,系统是能进去,但是数据库起不起来了,MySQL Server直接扔一坨错误exit,然后我们家开发就
跑了一波fsck!!!!!!!(reboot 到rescue里)
10个多G的数据啊!!!!fsck完了之后就剩几百兆!!!系统都启动不起来了!!!!
当时大晚上的差点气得我一口血喷屏幕上,这真的是数据连渣渣都不剩了
所以这样恢复出来的磁盘,不管是虚拟磁盘(虚拟化)还是虚拟磁盘(阵列)都不要去跑fsck,真的会literally毁掉你的数据
后来又重新拖了一份虚拟磁盘,我进去之后把innodb修了一波,dump,拿走,恢复,搞定
所以说有些文件系统层面的东西他根本不管你应用层面的数据,他只管这个地方数据怎么怎么,那个地方数据怎么怎么,只要移动到他觉得对的地方就成了
数据库呢,数据库绝对是我见过最耐造的,这虚拟磁盘真的数据都成渣了,系统能起来都是奇迹了,居然innodb还能修好数据库然后完好无损的dump出来,然而如果要fsck修复文件系统的话,那MySQL的数据库文件就会彻底被损坏
# Section End
这就是上面那第一个案例我恢复的时候犯了个天大的错误
我现在真想回去给我一个大耳刮子
这坑我踩了,写出来希望看到的人不要再犯这样的错误
和fsck一样,直接一坨检测到corruption然后就修复,然后修不了的就拖出来扔到lost+found去
最后修复前3.7T,修复后3.5T,lost+found里面就300多MB,还全都是乱码文件,没有后缀,完全无法恢复
然后这也不是虚拟机的磁盘可以再重来,没了就没了。。。
所以我建议大家,先把数据拖出来再说,起码你拖出来了,哪个坏了你能知道是哪个文件损坏了,可以去找备份什么的
这一个xfs_repair直接没了,而且你还不知道他删了哪些,也不给你个manifest
# Section End
嘛,到这里就结束了,希望能帮到大家。也感谢能看到这里的人ww
如果还有什么想让我说说的就在下面给我留言,或者微博上私信我也可以,刚好在放假可以写点经验之谈
#########################################################
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
#########################################################
抱歉⋯我已经 绝对不可能再获得幸福了
因为⋯我发现⋯
其实我⋯
早就已经被幸福包围了
——珂朵莉·诺塔·瑟尼欧里斯《末日时在做什么?有没有空?可以来拯救吗?》
Wikipedia: 末日时在做什么?有没有空?可以来拯救吗?