问题的根源
    去年六月，一个磁盘阵列处理器报错了，王东给硬件的厂商打了一个电话，得到的建议是运行后台校验来修复RAID数据，这个建议非常合理，但是实际操作中却并没有奏效。

    要修复RAID数据，首先必须先解除LUN绑定，然后重新绑定两个损坏的LUNs。因此，王东必须把损坏的LUNs上存储的数据库文件组移动到另外一个准备好的LUN上。这个步骤是修复RAID数据必不可少的步骤，然而无法挽回的损失也正是发生在这个步骤。

    王东通过一台远程计算机上进行解除和重新绑定的操作，与此同时还有一个厂商工程师在帮助做相同的操作，在实际操作中，由于以前备份策略的设置的文档已经完全丢失，无论是王东还是厂商工程师都很难把LUN编号和服务器驱动器编号对应起来，而且有些文件被错误的挪到了要重新绑定的LUNs上。两个人最终勉强完成了重新绑定的工作，他们却发现有一个重新绑定的LUN里面错误的包含了数据文件和SQL备份文件。

    王东试图从磁带上恢复数据库的备份文件，有一个重要的文件，对于社保基金中心的数据库来说最主要的文件组（MDF），在正常的备份过程中被不经意地忽视了，这个文件就没有备份到磁带上。而如果没有这个文件，数据库就不能恢复并正常工作。这个时候王东才意识到，要想从备份磁带中把数据恢复完成，已经彻底不可能了。而他们平时所依赖的数据备份系统，在真正的问题来临的时候，并不能保护数据安全。

    王东在周末加班，使用以前手工备份的MDF文件把所有只读的历史文件都恢复了，也就是2000年至2005年的数据，但是2006年的所有数据却永远丢失了，因为即使有2006年当前的备份和事务日志的备份，相对应的MDF文件的备份也是需要的。为了尽快恢复业务，系统先调用了一个没有数据的2006年的文件组。2006年夏天，王东和他的同事们用了三个半月的时间把纸质文档重新进行了扫描。