昨天UPS检修时间太长, 服务器掉电, 硬盘自检不通过, 机器起不来的处理过程

Question

昨天UPS检修时间太长, 服务器掉电,

起来之后, 刚开始10分钟是正常的, 10分钟之后出现问题:
1) 数据库读写不正常;
2) RAID-1中的其中1块硬盘灯不亮, 报警灯也没闪; (这个是后来人去机房才看到, 远程连接的时候不清楚这个情况)

查看了一番, 决定重启一下机器, 但是重启之后, 就起不来了, 晕 -_-#!

接下来就只有远程了,
让机房切上KVM发现, 卡在CentOS挂载硬盘上, 系统自检硬盘有报错, 不通过, 需要输入root密码手动修复, 报错信息类似下面的:

Your system appears to have shut down uncleanly
Press Y within 1 seconds to force file system integrity check...
Checking root filesystem

/dev/sda2:UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(I.E., without -a or -p options)

***An error occurred during the file system check.
***Dropping you to a shell; the system will reboot
***when you leave the shell.
Give root password for maintenance
(or type Control-D continue):

输入密码, 居然不正确, 也没改过阿, 晕

接下来google, baidu查找不要密码的方案:
1) grub中添加singel, 进入singel模式也一样需要root密码
2) grub中添加init=/bin/bash, 能够进入系统, 但是进去之后就卡住不动了, 晕死
3) 上光盘用rescue模式, 修改/etc/passwd, pwconv
(这时才发现可能KVM的键盘处理有问题, 我输个df, 结果出来ddffffffffffffffffffffffffffff, 狂晕阿)
让机房的人手工输入root密码后, 进入临时系统了

fsck /dev/sda2, 修复根分区吧, 再漫长的自检等了可能有半小时之后, 终于重启通过
进去系统后, 把不亮灯的SCSI硬盘拔下来, 又插上, 数据又开始同步了 ... 修复硬盘的日志类似如下:

Here the console-output:
==================================================================
rescue:~# fsck /dev/hda3
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
/dev/hda3 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Duplicate blocks found... invoking duplicate block passes.
Pass 1B: Rescan for duplicate/bad blocks
Duplicate/bad block(s) in inode 4784430: 9569668 9569669 9569670 9569671 9569672 9569673 9569674 9569675 9569676 9569677
Duplicate/bad block(s) in inode 4784807: 9569668 9569669 9569670 9569671 9569672 9569673 9569674 9569675 9569676 9569677
Pass 1C: Scan directories for inodes with dup blocks.
Pass 1D: Reconciling duplicate blocks
(There are 2 inodes containing duplicate/bad blocks.)

File ... (inode #4784807, mod time Wed Dec 29 23:20:59 2004)
  has 10 duplicate block(s), shared with 1 file(s):
        ... (inode #4784430, mod time Wed Dec 29 23:20:40 2004)
Clone duplicate/bad blocks<y>? no

Delete file<y>? yes

File ... (inode #4784430, mod time Wed Dec 29 23:20:40 2004)
  has 10 duplicate block(s), shared with 1 file(s):
        ... (inode #4784807, mod time Wed Dec 29 23:20:59 2004)
Duplicated blocks already reassigned or cloned.

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 4784430
Connect to /lost+found<y>? yes

Inode 4784430 ref count is 2, should be 1.  Fix<y>? yes

Unattached zero-length inode 4784804.  Clear<y>? yes

Unattached zero-length inode 4784806.  Clear<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  +5211533 +5218027 +5218036 +5219907 +5220360 +5221306 +5232339 +5232360 +5232511 +5232574 +5232990 +5234810 +(5238579--5238582) +5245529 +5245830 +5248928 +5249234 -(5355824--5355827) -(5364267--5364271) -(5366592--536659 -(5366685--5366689) -(5400399--5400405) -(5414077--5414083) -(5438621--5438626) -5440654 -(5440664--5440670) -(5440678--5440679) -(5440682--5440687) +(9569668--9569677)
Fix<y>? yes

Free blocks count wrong for group #163 (409, counted=430).
Fix<y>? yes

Free blocks count wrong for group #164 (2528, counted=2535).
Fix<y>? yes

Free blocks count wrong for group #165 (7575, counted=7589).
Fix<y>? yes

Free blocks count wrong for group #166 (31243, counted=31259).
Fix<y>? yes

Free blocks count wrong for group #292 (30999, counted=30989).
Fix<y>? yes

Free blocks count wrong (3942158, counted=3942196).
Fix<y>? yes

Inode bitmap differences:  -66005 +4784430
Fix<y>? yes

Free inodes count wrong for group #4 (15249, counted=15250).
Fix<y>? yes

Free inodes count wrong for group #292 (15705, counted=15706).
Fix<y>? yes

Free inodes count wrong (4740607, counted=4740611).
Fix<y>? yes

/dev/hda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda3: 158205/4898816 files (2.1% non-contiguous), 5843397/9785593 blocks
==================================================================

接下来总结一下教训吧, 希望大家补充:
1) 密码一定要定期登录, 检查可用性
2) 需要找一个检测硬件状态的软件, 定期检查硬件的状态, 包括KVM, 千万不要出了故障还浪费时间弄这些小问题
3) 掉电以后, 检查到问题, 一定不要轻易重启, 最好在电就把问题解决

Answer 1

慢慢修煉吧，人家都說百煉可以成精……

Answer 2

不错不错，学习了。

Answer 3

ext3这么不稳定？ ext4和xfs如何？

Answer 4

下面转贴一封:

2010-8
14
系统管理员的3大黄金法则
发表于: Linux, Shell, Tools, UNIX | 作者: 谋万世全局者
标签: 系统管理员,黄金法则

当我为这篇文章打草稿的时候，我本来提出了七个系统管理员的习惯，但是在那七个习惯中，最后只有三个脱颖而出。虽然习惯是好的，但是有时法则更好，尤其在系统管理员处理生产环境的时候。

法则1：备份所有的东西（并定期的验证备份）

有经验的系统管理员都知道，无论我们多么有前瞻性，生产系统总有一天会崩溃的。为这种情况做准备的最好办法是做一个有效的备份。

如果你没有备份你的关键性系统，你应该马上开始做计划。在给备份做计划的同时，你应该经常考虑如下问题：

   1. 你要使用什么软件（或自定义脚本）来做备份？
   2. 你有足够的硬盘空间来保存备份吗？
   3. 你多久轮换一次备份？
   4. 除了完全备份，你还需要定期的进行增量备份吗？
   5. 你要怎样执行你的备份？比如使用crontab还是其他的schedulers?

如果你没有备份你的关键性系统，不要读这篇文章了，快回去工作，马上开始给你的备份做计划。

前阵子，在某个小组进行的一项研究中，我记得他们提到：只有70%的生产性应用程序得到了备份。其余的30%的备份都是无效的或是损坏的。

假设Sam定期的备份了关键性的应用程序，但是没有验证他的备份。而Jack没有为他的关键性应用程序做任何的备份。听上去好像做了备份的Sam比 没有做备份的Jack的情况要好很多。在我看来，Sam和Jack的情况都一样，因为Sam从来都没有验证他的备份以确保当灾难发生的时候可以用它来进行 恢复。

如果你是一个系统管理员，并且不想遵守这条黄金法则1（或想要打破这条法则），你应该认真的考虑一下放弃系统管理员的工作，而去做一个开发人员。

法则2：精通命令行（如果可能的话尽量避免使用UI）

在Unix/Linux服务器上，任何一个任务都可以通过命令行来执行。虽然有一些UI可以很容易的完成一些管理员任务，但是你真的不需要他们，你应该一直使用命令行。

所以，如果你是一个Linux系统管理员，你应该精通命令行。

在任何一个系统上，如果你想变得“fluent（流畅）”和“productive（高产）”,你应该精通命令行。Windows系统管理员和 Linux系统管理员的主要区别是——GUI Vs 命令行。Windows系统管理员并不是很喜欢命令行，而Linux系统管理员很喜欢命令行。

即使你有一个可以完成某个任务的UI，你也应该优先选择命令行，因为如果你使用命令行，你可以了解一个特定的服务是如何工作的。在许多生产**器环境中，系统管理员通常会卸载所有的GUI服务和工具。

如果你是Unix/Linux系统管理员，并且不想遵守这个法则，可能在你的内心深处你想成为一个Windows系统管理员。

法则3：让所有事情自动化（并变得懒惰）

懒惰的系统管理员才是最好的系统管理员。

据我所知，没有一个系统管理员喜欢打破这个法则。要想变得懒惰，可能还有一些事情要做。

花几分钟时间想一想，并列出所有你可能每天，每周或每月都要做的例行公事的任务。一旦你有了这样一张明细表，想一想你如何使它们自动化。最好的系统管理员通常不喜欢繁忙。他更喜欢让系统来为他做工作，而让自己变得很轻松。

原文：http://www.thegeekstuff.com/2010/07/three-sysadmin-rules/

翻译：周雪峰