宁夏银行系统瘫痪事件还原：
银行二部(2014)187号正式发全国文件，对宁夏银行事故的描述大致如下2014年7月1日，宁夏银行核心系统数据库出现故障，导致该行(含异地分支机构)存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断。
经初步分析，在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机。因宁夏银行应急恢复处置机制严重缺失，导致系统恢复工作进展缓慢，直至7月3日5点40分核心系统才恢复服务，业务系统中断长达37小时40分钟，其间完全依靠手工办理业务。
以上情况亦可以通过有关部门的微博信息佐证：
7月2日，银川市医疗保险事务管理中心官方微博——银川医保发布消息称，因宁夏银行机房出现故障，自2014年7月1日15:30起全市定点医疗机构和定点零售药店共700多家不能刷医保卡(社保卡)就医结算。目前，故障原因还未查明，宁夏银行正在组织人力检查抢修。7月3日，该微博发布消息称，宁夏银行业务系统故障已于2014年7月3日8:30排除，系统现已恢复正常使用，全市定点医疗机构和定点零售药店医保刷卡(社会保障卡)就医结算系统也已恢复正常，广大参保人员医保刷卡业务已可以正常进行。
7月3日，宁夏土地和矿业权网上交易系统发布变更公告称，宁夏银行2014年7月1日15时37分至7月3日8时30分银行业务系统出现故障，导致土地和矿业权网上交易系统无法与银行连接，影响了参与竞买宁地(挂)字[2014]-12号、宁地(挂)字[2014]-13号、灵地挂字[2014]-11号、泾地挂字[2014]-8号四宗国有建设用地使用权竞买人申请及资格确认。现将该4宗国有建设用地保证金截止时间和挂牌截止时间顺延。
事件原因：
网传通知指出，该事件的根本原因在于该行安全生产意识薄弱、应急管理体系缺失、应急处置过程混乱。该行核心系统数据库版本严重老化，且2007年至今未购买核心数据库的维保服务，核心系统长期缺乏维护，事故发生后，无法获得系统供应商及时技术支持。系统恢复过程中，缺乏应急预案和准备，长时间无法实施有效处置，导致业务恢复缓慢，对银行运营产生较为严重影响。
简而概之：
宁波银行系统瘫痪是因为，发现备份系统出现性能问题，于是中断备份作业，结果造成数据库损坏，系统宕机。
为啥没有及时切换到灾备系统上呢？
曾经成功的灾备演练：《敢为天下先，宁夏银行灾备演练》
作为一个中型商业银行，宁夏银行是不可能没有灾备系统的。不但有，还曾经有过样本式的灾备演练：4月24日，宁夏银川，在宁夏银行的大会议室内，一场模拟数据库瘫痪与数据中心火灾的灾难恢复演练正在举行。
在此之前，2010年4月，在短短3个星期的施工期和测试期之后，宁夏银行与飞康公司合作，采用持续数据保护（CDP）技术，建立了本地和异地的一体化、分层次的灾难恢复体系。IT 环境是： IBM AIX UNIX Informix EMC DMX800
当时，演练的两种“突发情况”：数据库系统瘫痪和数据中心发生火灾——前者模拟宁夏银行生产中心数据库系统发生崩溃瘫痪的严重故障，测试根据需要启动应急响应流程，进行本地的数据库系统恢复；后者模拟生产中心发生一场大火，测试根据应急流程进行从银川到西安的异地切换。
为什么这次没有成功？
有句格言，今天的成功不能代表未来的成功，这句话对于灾备演练很适用。哪怕在宕机发生前每一天你的灾备演练都成功，也不能确保宕机的时候，系统真的能切换。不过还是要问下：最后一次演练的时间是什么时候？
中存储网编辑米乐认为：
首先，既然是生产数据库宕机了，那么第一时间应该是切换到你的复制系统上去，现在看来一定是没有切换成功。网络问题？数据库出现了逻辑错误？复制系统不是active的？这仅仅是猜测而已。
ok，既然没切换，那么接下来要做的应该是马上去恢复，银行的生产数据库啊，不会太小的！这个能做录像的CDP备份系统，你的备份性能差我们都知道，那你的恢复速度是咋样的？30多个小时，是不是就是在焦急的数据正在恢复中呢？
本此宕机事件的几个关键点及启示：
1、因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机。
疑问：从事件的信息分析来看，这个备份系统应该是某康公司的CDP，其性能问题在业界一直有质疑。尤其在面对银行生产系统时，数据量大，交易多，I/O操作频繁，这样的CDP备份系统真的适合吗？
2、2007年至今未购买核心数据库的维保服务，核心系统长期缺乏维护。
疑问：亲，你确定不要数据库的维保不是冒险吗？是的，有些厂商的数据库维保很贵，但是为了我们的核心数据，我们的企业命脉，多花点钱恐怕也比裸奔要安全得多啊。
3、在灾备演练的时候多是模拟真实的环境，但是，值得注意的是，模拟和真实总是有差别的。哪怕再细小，都是隐患的。
微博上网友们对宁夏银行宕机事件的评论，可以开阔思路：
唐僧_huangliang：应该是LVM同步镜像，所以会有读操作。按道理已经不一致了应该先断开备份存储，中断录像可能会丢缓冲区数据吧 //@阿里老丛: 这里的备份系统应指灾备存储，但备份存储怎么会有读操作？复制机制是同步还是异步？主备存储不一致那就是异步，可异步复制有必要断开么？另，断开复制导致数据库损坏又是哪般？
雨燕轩12：看了一篇新浪blog 感觉他们的架构是将dmx与cdp下的阵列通过lvm镜像 首先 备份卷读写慢应该只会导致业务io延迟 中断cdp端即可 再次中断录像应该不至于主库损坏 除非恢复lvm时操作失误 最后 出现故障时没有提取几份快照出来报命 也是失误吧！
bbjmmj：设备的major和minor。两个镜像是两个物理卷，可能属于不同的物理设备，major可能不同，即使major相同，minor也会不同，如果ORACLE捆绑了裸设备，而被捆绑的裸设备挂掉，ORACLE就有可能挂掉。LVM创建镜像的时候默认（-M n)是随机指定主设备，后挂上去的LUN可能会无意中成为主设备，这是个坑！
无米不香：估计是开启了飞康的录像功能，备存储的性能又跟不上，导致业务系统慢。但录像功能不应该会导致宕机。宕机的原因可能是飞康CDP卷与主数据卷镜像导致的。不过我始终认为，产品与技术是因素，但核心是管理问题。
类似案例
银行灾备建设一直是走在各行业的前列的，各个银行纷纷搭建自己的容灾平台，大多以两地三中心的灾备解决方案为主，但是这并不表示数据安全了，真正的可靠的容灾系统，是要经受住烈火的考验的。
银行宕机事件也是层出不穷，2013年1月，中行信用卡系统所在的IBM大型机宕机，两地三中心灾备就没起作用。