Linux下文件系统superblock故障修复
记一次 superblock 损坏导致服务器无法启动的故障修复
前几天接到朋友联系，说他的服务器坏了，启动不起来了。这是一个RHEL 4的服务器，而且是那种盗版RHEL 4，也就是说没有售后服务的，联系我问问能不能帮帮忙。我也很久没有弄过Linux系统上的东西了。只好尝试一下，庆幸的是，修好了，并帮朋友维护了一段时间，在此记录一些修复和维护中碰到的问题。修复 superblock 本身并不复杂，我觉得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。
一、启动故障
系统无法启动，启动时内核panic：
Uncompressing Linux Ok, booting the kernel.
audit(1297269214.612:0): initialized ide2: I/O resource 0x3F6-0x3F6 not free. ide2: ports already in use, skipping probe Red Hat nash version 4.1.18 starting File descriptor 3 left open
Reading all physical volumes. This may take a while /dev/hda: open failed: No medium found
Found volume group \File descriptor 3 left open
8 logical volume(s) in volume group \File descriptor 3 left open
VFS: Can't find ext3 filesystem on dev dm-0. mount: error 22 mounting ext3 mount: error 2 mounting none switchroot: mount failed: 22 umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init! _
看到这个报错，我Google了一下，很快就发现，这很有可能是硬盘的superblock [1] 坏了，因此感觉需要修复superblock。
询问了一下，瘫痪之前都发生了些什么。朋友提到了一个情况，在瘫痪前，他发现有一个目录存储了太多的文件了(确实非常的多，大约是几百万到上千万个文件，程序设计上有问题)，这是他写的一个php做缓存的脚本生成的后缀为.php的文件，绝大多数都已经是垃圾文件了。他觉得太占磁盘空间了，想清理一下，于是用下面的命令删除这些生成的文件:
find . -name \;
可是执行命令后，等了几分钟，发现系统没有反应。于是就Ctrl-C了，后来发现系统还是很慢，于是就执行reboot了。接下来，系统就启动不起来了。
可以推断，其实并不是系统没有反应，而是删除如此大量的文件，需要相当的时间，当Ctrl-C后，磁盘写入行为并没有因此而立即停止，在如此密集磁盘写入时执行reboot，确实比较容易引起磁盘上的故障。再加上这块硬盘虽然是ext3，但是日志使用的是默认的ordered [2]，出问题的几率就更大了，所以怀疑是 superblock 的可能性就更大了。
二、修复环境
当时朋友有些慌张了，因为他认为这是他操作失误导致服务器瘫痪，有些不知道该怎么办了，那天我有事情比较忙，打算晚些时候再回来帮他。随后的操作中可以看到他做了很多危险的操作，我会一一提出来，大家有类似情况的时候，一定要注意。
首先是他把硬盘直接拆下来来了，打算拿回公司备份。备份的想法是好的，如果有合适的服务器，拆下来接过去备份也是对的。但是问题就在于，这是一块SCSI接口的硬盘，是一堆
Linux分区，使用的还是LVM [3]，而他公司没有一个SCSI接口的机器，他可能还需要去市场上买个SCSI卡，而且，他也没有一台Linux的机器，全是Windows，他甚至打算使用explore2fs之类的不成熟的软件来挂载这块硬盘。
这问题就大了。买的SCSI卡的稳定性如何？别是杂牌的，卡再造成硬盘的二次数据损失。用Windows备份可能损坏的硬盘的数据是非常危险的，explorer2fs这类Windows挂载ext2/3分区的软件从来就没成熟过，至今为止还有大量的特性不支持，只是试验产品。使用他们挂载分区，很可能会造成数据损失。另外，之前说过，问题很可能是superblock出问题了，这种情况下，不修复 superblock ，谁也别想挂载成功，而Windows上显然没有这类软件。
碰到这类问题，比较好的办法是使用另一台具有SCSI接口的Linux，进行修复、挂载、备份。当然，对于朋友而言，这不现实。那就折中，还在原服务器上修复，但是使用 Linux LiveCD 进行修复，将数据备份到外置 USB 硬盘上。
这里需要注意的是，即使硬盘有几个分区，只坏了一个，备份到其它貌似还好的分区似乎也不是什么大问题。但是，在修复、备份的时候，一定要尽可能的避免被修复磁盘的写操作，无论是哪个分区。因为在问题确认修复前，你并不能肯定只有那个报错的分区有故障，其它一切正常。
那天朋友在机房的时候，他什么都没有带，只能眼睁睁的一次次的重启，看错误日志，试着能不能进系统。这是很不好的，如果怀疑硬盘出了故障，那么这么一次次重启很容易加重问题，因此一定要避免。
没有任何修复环境是没有办法工作的。我让朋友回去准备几张光盘，都是可引导的修复盘。朋友对 Linux 有一些经验但不是很熟悉，折中起见，我让朋友准备了 Fedora 14、Ubuntu 10.10、UBCD等光盘备用，并且打算使用 Fedora 14 的 Live CD 进行修复。并且第二天带一个大容量的，最好是空的USB硬盘来，备份数据。并且，在家用 Fedora 14 启动一下，看看怎么进入命令行模式，第二天启动的时候，不要进入图形界面。在命令行模式下修复。
第二天约好时间后，看了他的gtalk留言，感觉是一身冷汗啊。
首先是告诉我，在服务器上 Fedora 启动后直接进桌面了，没有选项，点了点不知道怎么修复，甚至打开了故障硬盘的几个分区，没找到需要备份的文件。于是乎，又启动了Ubuntu选择了修复坏系统，结果发现要安装文件，然后报错说没有硬盘，于是退出了。
敢情这哥们直接把我说的话当耳旁风，在故障服务器上直接启动图形界面，更甚的是，他还尝试让 Ubuntu 覆盖安装 RHEL 4。幸好分区的 superblock 是坏的，不然全毁了。
这里面有三个错误。首先是不应该启动图形界面，其次是错误的理解了 Ubuntu 中修复系统选项的含义，然后是在菜单上点击服务器分区从而激发了绑定操作，很可能直接造成写入操作。
这些都应该是前一天晚上回家琢磨的，他显然偷懒了，直接拿故障环境练手。如果不是这哥们命大，而且系统出的问题没有那么严重，那么这些连续的错误，很可能造成不可挽回的结果。
虽然对于 Windows 用户来说，看着纯命令行觉得无从下手，但是，得到了美丽的界面往往意味着你得付出些什么。在以前的某些 LiveCD 中，加载图形界面的时候，由于各种驱动和程序的加载，错误的进行了硬盘的写操作，从而导致有些人抱怨过启动 LiveCD 导致硬盘数据二次损坏，最终使得修复无望。虽然，最近这些版本的 LiveCD 可能没有这类问题，但是为了避免万一，应当尽量减少对硬盘写入操作的可能性。既然所有修复行为都会在命令行模式下进行，那就没必要启动图形界面冒风险。
我让他带着 Ubuntu 的盘就是以防万一，万一 Fedora 启动出现奇怪的问题，我们可以用 Ubuntu 启动然后修复系统。而不是进入 Ubuntu的修复系统选项。那个选项是给 Ubuntu 系统准备的，是以光盘上的系统文件及配置覆盖硬盘上的系统文件及配置，从而达到修复系统的目的。这显然和我们要修复的 RHEL 驴唇不对马嘴。修复系统所需要的只是一个 Linux 环境而已。
至于最后在菜单上点击硬盘分区，甚至还打开里面的文件看看，这就是纯属找死了。系统已经报错了，即使能够挂载成功，文件系统也很可能是有问题的，必须在访问前先fsck，否则很可能会引发更大的问题。毕竟默认 Fedora 挂载可不是只读，而是可读写，混乱后，谁也无法预测会把硬盘写成啥样。
三、确认问题
该准备的光盘准备了，不该操作的操作也做了，这让我很无语，虽然怀疑仅仅是逻辑错误导致superblock坏掉，应该不会有大问题，但还是让我对这次修复的可能性感到怀疑。至少这朋友完全不按照我说的办，经常的做些自己觉得没什么的危险操作，哎，前景黯淡啊。
既然他已经改点的都点了，该造成的损坏基本上也造成了。那就在 Fedora LiveCD 的图形界面下修复吧，至少他还可以更方便的把命令返回结果通过 firefox 给我发过来。比用 android 手机通讯好多了。
首先我需要知道，都有哪些文件系统被他挂载了，另外，系统上有哪些分区。
[root@localhost liveuser]# mount |grep LogVol
/dev/mapper/VolGroup_ID_17253-LogVol4 on /media/0edef924-567f-45fc-9609-51722cad6e9e type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/mapper/VolGroup_ID_17253-LogVol7 on /media/ee0c40c6-d9d1-4a81-9806-9991621db1dd type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/mapper/VolGroup_ID_17253-LogVolHome on /media/f524534e-3d24-4a22-b475-9e4b7dac0d35 type ext3 (rw,nosuid,nodev,uhelper=udisks)
/dev/mapper/VolGroup_ID_17253-LogVol6 on /media/12953c57-baba-4358-baeb-cdd17d6513a2 type ext3 (rw,nosuid,nodev,uhelper=udisks)
好嘛，据我所知，服务器上好像有5个绑定目录的分区，LogVol{3,4,6,7,Home}，Log