上周，有客户的数据库系统遭遇到了一次严重的灾难。主机访问不到硬盘，系统在本地硬盘残存了三个文件，其余文件存储于SSD构成的RAID组上，客户在出现问题后，草率的重构了RAID，导致了数据不可恢复；然后开发商介入恢复了2个月前的一个备份，又毫无心机的覆盖了没有备份残存的三个文件；最终结果的是无法恢复。
然后召集人马，开始重新补录数据。
这个故事的警戒之处在于：
客户第一次找我的时候，我告诉他，把硬盘拿给我们，我们可以将其中的数据恢复出来。
第二天客户说，硬盘被格式化重做了系统。
客户第二次找我时，我说，把剩余的三个文件给我，我可以帮你挽救其中残存的有用数据。
第二天客户说，已经拿备份，把那三个文件刷新覆盖了。
这个故事给我们的警戒是：备份，备份，备份，再多一份也不算多；故障处理，再加一万个小心也不算多。
最初的一个简单故障，在层层错误之后，彻底不可挽回，这是多年来我见到最富有戏剧性的恢复案例。
看一看这个故障的信息，首先是一个写错误，Windows中比较典型和常见的存储访问错误：
Sat Sep 23 18:44:51 2011KCF: write/open error block=0x35673a online=1Sat Sep 23 18:44:51 2011KCF: write/open error block=0x25eba4 online=1file=124 D:\\DTA\\PRODTA02.DBFerror=27070 txt: 'OSD-04016: 异步 I/O 请求排队时出错。O/S-Error: (OS 2) 系统找不到指定的文件。'ORA-01242: data file suffered media failure: database in NOARCHIVELOG modeORA-01114: IO error writing block to file 124 (block # 24856)ORA-01110: data file 124: 'D:\\DTA\\PRODTA02.DBF'ORA-27070: skgfdisp: async read/write failedOSD-04016: 异步 I/O 请求排队时出错。O/S-Error: (OS 2) 系统找不到指定的文件。
再然后，恢复使用了一个4月份的备份，又覆盖了挽救回来的文件：
Sun Sep 24 20:58:32 2011The input backup piece G:\\BCK\\DB_T20110421_S111_P1 is in compressed format.
然后，就没有然后了。
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
