08年的8月5号，我在电信担任数据通信事业部IDC的项目经理，这一天对我来说是记忆深刻的一天，集团邮件服务器DOWN掉了，而且很难RECOVER，无法忘记这一段历史。
下面是我当年写的报告原文：
8月5日早上8点接到客户的EMAIL报障，报障内容为企业邮箱无法使用，随后立即进入机房检查发现COREMAIL邮件系统（IP地址为61.142.15.58）已经宕机。
机器不断产生如下提示：
XFS mounting filesystem sda1
Starting XFS recovery on filesystem: sda1 (dev: sda1)
3w-9xxx: scsi0: ERROR: (0x03:0x0202): Data ECC error:.
scsi0: ERROR on channel 0, id 4, lun 0, CDB: Read (10) 00 65 db d7 3f 00 00
08 00
Current sda: sense key Medium Error
Additional sense: Unrecovered read error
end_request: I/O error, dev sda, sector 1708906303
3w-9xxx: scsi0: ERROR: (0x03:0x0202): Data ECC error:.
scsi0: ERROR on channel 0, id 4, lun 0, CDB: Read (10) 00 65 db d7 40 00 00
07 00
Current sda: sense key Medium Error
Additional sense: Unrecovered read error
end_request: I/O error, dev sda, sector 1708906304
3w-9xxx: scsi0: ERROR: (0x03:0x0202): Data ECC error:.
scsi0: ERROR on channel 0, id 4, lun 0, CDB: Read (10) 00 65 db d7 41 00 00
06 00
Current sda: sense key Medium Error
Additional sense: Unrecovered read error
end_request: I/O error, dev sda, sector 1708906305
3w-9xxx: scsi0: ERROR: (0x03:0x0202): Data ECC error:.
scsi0: ERROR on channel 0, id 4, lun 0, CDB: Read (10) 00 65 db d7 42 00 00
05 00
根据这些数据可以初步判定硬盘出现问题。由于硬盘为RAID1镜像阵列，进入系统BIOS的RAID控制程序，查看到系统检测出了RAID阵列是正常的，查看两块硬盘，均能检查出硬盘容量及型号。因此故障原因非单个硬盘硬件损坏，而是硬盘数据出现问题和分区表损坏。
于是运行fdisk指令，查看系统能找到的分区：
Disk /dev/hda: GB,bytes
16 heads, 63 sectors/track, 79656 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 4161 2097112+ 83 Linux
/dev/hda2 4162 8328 2100168 82 Linux swap
/dev/hda3 8329 12489 2097144 83 Linux
/dev/hda4 12490 79656 33852168 f W95 Ext'd (LBA)
/dev/hda5 12490 16650 2097112+ 83 Linux
/dev/hda6 16651 79656 31754992+ 83 Linux
发现目前硬盘分区只挂载了一个，其余都不能正常挂载。其他硬盘分区均有可能存在坏扇区。
之后运行磁盘检查指令 chkdsk 检查磁盘分区数据并试图修复分区，均告无效。且系统随着重新启动次数的增加，坏的分区越来越多，多数分区都无法正常挂载。
在无法恢复硬盘分区并正常启动的情况下，我们立即找了了替代方案，在9点左右为另外一台服务器安装Redhat Adavnced Server 4，并于10点通知COREMAIL供应商广州安岭公司做好重装和恢复COREMAIL数据的准备工作。
在为另 外一台服务器安装Redhat Adavnced Server 4的过程中，原有的DVD版的Redhat Adavnced Server 4无法在该服务器的普通CDROM上安装，后找到CD版的Redhat Adavnced Server 4，安装第三张盘时又提示光盘无法读取，只能重刻第三张光盘。在整个安装系统的过程中耽误了不少时间。
系统安装完毕后，通知COREMAIL供应商广州安岭公司，又遇到无故拖延。为了尽快为客户提供基本的收发邮件的服务，我们请他们先行恢复用户数据。但 他们告诉我们原先备份的用户数据库里没有INDEX数据表，就此问题我们跟他们做了严正交涉，指出此INDEX表在我们运行的系统数据库中根本不存在。此后广州安岭公司采取了手工建立INDEX表的方式，最终于下午15:00之前帮我们恢复了用户数据库。用户至此可以正常收发邮件。
总结以上的检查过程，分析出现此种宕机问题的原因如下：
1：此服务器使用4年多，且服务器硬盘每天读取写入邮件数据多且频繁，因此硬盘可靠性急剧降低。
2：机房该机柜内服务器表面温度平时都在40度以上，服务器机箱内温度更高，工作温度明显过高，硬盘在这个温度区间工作的比较不稳定，易产生读写错误。
3：我们对出现这种故障的风险估计不足，没有做好备份系统，并将数据及时备份保存。在这中间耽误了不少宝贵的抢修时间。
4：和供应商沟通中出现不少问题。
综上所述，IDC网管在这个故障的过程中存在比较多不足的地方。而且此次故障之前，邮件系统在升级后有比较多的一些小故障，可能都预示着系统发生问题的方向，结果我们没有在意，导致出了这么大事故。
经过痛定思痛，我们针对目前的状况做如下的总结和改进：
1：对于COREMAIL邮件系统我们要加深一步理解，此次恢复系统过程中出现的INDEX索引导致只能手工恢复数据的问题，我们以后必须深刻重视。做到对邮件系统的了解万无一失。
2：防患于未然，备份机器和备份系统要时刻准备好。以免在这个问题上耽误恢复系统的时间。
3：做好所有用户的每日备份工作，争取备份到每天的数据。在出现问题时，将用户的损失降低到最小。
4：定期巡检系统，针对系统可能出现的异常情况做好准备工作，做好安全生产工作。
在全公司安全生产的大前提下，IDC网管组应当严格遵守安全生产的规章制度，并结合实际情况，总结经验教训，以保障系统的稳定运行。
2008-8-7
