我是盘阵，我叫raid10，我down了

一、先说教训

如果不能接受数据库down机器导致数据无法找回造成的后果，那么：
重要数据一定要异地备份！！！
重要数据一定要异地备份！！！
重要数据一定要异地备份！！！

二、背景介绍

业务系统

业务系统是我公司为JIA方BB开发的互联网APP，我公司负责系统运维，本人是主要系统运维人员。

业务系统使用两个数据库，一个Sybase ASE数据库，一个SQL server数据库（俩数据库均是单机运行，这里不对系统架构设计做吐槽），SQL server库运行在一台Hyper v虚拟机上，整个虚拟机的文件是挂载到盘阵上的，Sybase数据库服务器是单独一台linux物理机也是同样挂载在盘阵上的（再次强调不对系统架构设计吐槽）。整个系统没有专用的备份服务器，没有多余的存储介质，数据库备份在本地。盘阵是使用的一台8年高龄以前其他系统淘汰下来的。

业务系统所使用的硬件设备均部署在JIA方BB的本地机房。

整个事件中我们作为现场一线、开发团队作为二线远程支持。

三、事情经过

清明节最后一天假，凌晨，一台连接着2台业务系统核心数据库的高龄盘阵down机了，遂开始了7*24紧急抢修。

第一天

事故发生后，两台数据库服务器均down机无法ping通导致系统瘫痪，随即前往机房进行排查，发现是盘阵down机了，联系设备厂商LC进行咨询，厂商说：“你这玩意儿过保了，先打钱再上门！”（开玩笑的😝）。厂商发了个操作手册，通过管理口连上了盘阵，乍一看卷名是raid10心里狂喜，结果...仔细一看竟然发现这玩意是raid0（相当于就是一块大硬盘，坑啊）。

这？？？

通过管理平台发现共8块硬盘中有一块损坏了导致整个存储无法正常使用了。

问题原因找到了，那么下一步就是解决问题了。

解决问题分成两个线程做，一组人把盘阵拿到电脑城去做数据恢复。我们现场重新搭建两套新数据库争取尽快恢复业务，但问题也来了，数据库备份文件都在本地，现在俩机器都开不了机也拿不到啊。绞尽脑汁之后终于想起我曾经留过一手，去年9月的时候做过一次恢复性测试，SQL server库的备份文件在ftp上存着一个，sybase库在一台测试服务器上也有到去年9月的数据都没有清理，这俩数据恢复出来应该有原来的8成左右，也算是幸运吧，不然...

数据恢复那边说100%能恢复数据，并已经恢复了4块硬盘，其中包括坏的那块硬盘，好消息呀。

第一天进展
Sybase数据库服务器系统重装，安装数据库软件。
晚上存储厂商人员也来到现场上架了一套新盘阵（此套盘阵原本是其他系统更新换代后准备使用的被提前征用了）。
祈祷数据恢复完成。

早上回去睡觉做梦都梦到数据库恢复成功了。

第二天

Sybase数据库数据库从测试环境中导入了核心业务表并恢复了8成数据。

数据库恢复那边传来了坏消息，又有一块盘坏了并且数据无法恢复，给出的原因是：原本那块盘本可能已经有损坏了，但是在高速运转平衡的状态下没有问题，但是一断电失衡了磁道就受损了。这原因也是有理有据！

本来SQL server数据库是等着数据恢复了直接用恢复的虚拟硬盘开机使用，现在也只能重装SQL server数据库了，为了效率高又又又在物理机上新装了一台Hyper v虚拟机并还原了数据库备份恢复8成数据。

第三天

两个数据库准备库之后，第三天主要是二线开发团队那边进行评估，检查应用及配置，开了测试端口，打了测试包，跑了一遍没有问题之后，正式恢业务。

后续

后续就是解决未恢复的2成数据造成的问题了，这里就不细说了。

数据库恢复那边的情况是：那哥们儿3天3夜没睡觉，一直在做数据恢复，牛逼👍，但最终结果也并不是很理想，只恢复了部分SQL server库的一些表数据，对Sybase库没辙，但还在研究中。

四、总结回顾

1.本次故障暂未造成直接经济损失，只是给用户带来非常差的体验。
2.信息系统资源不充足导致无法做异地备份。
3.信息系统的不重视，这次事故的发生是个偶然也是个必然这里我要吐槽了，其实大概在2年前我在巡检时就发现盘阵有告警了，当时联系了厂商，厂商说设备过保了上门检查要收费，如实汇报给JFBB后没有引起重视，结果不了了之，没想到在我即将要离职之前就爆发了，不过也算人生中不可多得的经验及教训吧。
4.本次事发生后系统计划上云。