修复系统

Linux下文件系统superblock故障修复

记一次superblock损坏导致服务器无法启动的故障修复

前几天接到朋友联系，说他的服务器坏了，启动不起来了。这是一个RHEL4的服务器，

而且是那种盗版RHEL4，也就是说没有售后服务的，联系我问问能不能帮帮忙。我也很久

没有弄过Linux系统上的东西了。只好尝试一下，庆幸的是，修好了，并帮朋友维护了一

段时间，在此记录一些修复和维护中碰到的问题。修复superblock本身并不复杂，我觉

得值得记录的是修复过程中的思考过程，和修复所需要注意的问题。

一、启动故障

系统无法启动，启动时内核panic：

UncompressingLinuxOk,bootingthekernel.

audit(1297269214.612:0):initialized

ide2:I/Oresource0x3F6-0x3F6notfree.

ide2:portsalreadyinu,skippingprobe

RedHatnashversion4.1.18starting

Filedescriptor3leftopen

ytakeawhile

/dev/hda:openfailed:Nomediumfound

Foundvolumegroup"VolGroup_ID_17253"usingmetadatatypelvm2

Filedescriptor3leftopen

8logicalvolume(s)involumegroup"VolGroup_ID_17253"nowactive

Filedescriptor3leftopen

VFS:Can'tfindext3filesystemondevdm-0.

mount:error22mountingext3

mount:error2mountingnone

switchroot:mountfailed:22

umount/initrd/devfailed:2

Kernelpanic-notsyncing:Attemptedtokillinit!

_

看到这个报错，我Google了一下，很快就发现，这很有可能是硬盘的superblock[1]

坏了，因此感觉需要修复superblock。

询问了一下，瘫痪之前都发生了些什么。朋友提到了一个情况，在瘫痪前，他发现有一个目

录存储了太多的文件了(确实非常的多，大约是几百万到上千万个文件，程序设计上有问题)，

这是他写的一个php做缓存的脚本生成的后缀为.php的文件，绝大多数都已经是垃圾文件

了。他觉得太占磁盘空间了，想清理一下，于是用下面的命令删除这些生成的文件:

find.-name"*.php"-execrm-f{};

可是执行命令后，等了几分钟，发现系统没有反应。于是就Ctrl-C了，后来发现系统还是

很慢，于是就执行reboot了。接下来，系统就启动不起来了。

可以推断，其实并不是系统没有反应，而是删除如此大量的文件，需要相当的时间，当Ct

rl-C后，磁盘写入行为并没有因此而立即停止，在如此密集磁盘写入时执行reboot，确实

比较容易引起磁盘上的故障。再加上这块硬盘虽然是ext3，但是日志使用的是默认的ord

ered[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有一些经验但不是很熟悉，折中起见，我让朋友准备了Fedora14、Ubu

ntu10.10、UBCD等光盘备用，并且打算使用Fedora14的LiveCD进行修复。并

且第二天带一个大容量的，最好是空的USB硬盘来，备份数据。并且，在家用Fedora1

4启动一下，看看怎么进入命令行模式，第二天启动的时候，不要进入图形界面。在命令

行模式下修复。

第二天约好时间后，看了他的gtalk留言，感觉是一身冷汗啊。

首先是告诉我，在服务器上Fedora启动后直接进桌面了，没有选项，点了点不知道怎么

修复，甚至打开了故障硬盘的几个分区，没找到需要备份的文件。于是乎，又启动了Ubu

ntu选择了修复坏系统，结果发现要安装文件，然后报错说没有硬盘，于是退出了。

敢情这哥们直接把我说的话当耳旁风，在故障服务器上直接启动图形界面，更甚的是，他还

尝试让Ubuntu覆盖安装RHEL4。幸好分区的superblock是坏的，不然全毁了。

这里面有三个错误。首先是不应该启动图形界面，其次是错误的理解了Ubuntu中修复系

统选项的含义，然后是在菜单上点击服务器分区从而激发了绑定操作，很可能直接造成写入

操作。

这些都应该是前一天晚上回家琢磨的，他显然偷懒了，直接拿故障环境练手。如果不是这哥

们命大，而且系统出的问题没有那么严重，那么这些连续的错误，很可能造成不可挽回的结

果。

虽然对于Windows用户来说，看着纯命令行觉得无从下手，但是，得到了美丽的界面往

往意味着你得付出些什么。在以前的某些LiveCD中，加载图形界面的时候，由于各种驱

动和程序的加载，错误的进行了硬盘的写操作，从而导致有些人抱怨过启动LiveCD导致

硬盘数据二次损坏，最终使得修复无望。虽然，最近这些版本的LiveCD可能没有这类问

题，但是为了避免万一，应当尽量减少对硬盘写入操作的可能性。既然所有修复行为都会在

命令行模式下进行，那就没必要启动图形界面冒风险。

我让他带着Ubuntu的盘就是以防万一，万一Fedora启动出现奇怪的问题，我们可以

用Ubuntu启动然后修复系统。而不是进入Ubuntu的修复系统选项。那个选项是给Ub

untu系统准备的，是以光盘上的系统文件及配置覆盖硬盘上的系统文件及配置，从而达到

修复系统的目的。这显然和我们要修复的RHEL驴唇不对马嘴。修复系统所需要的只是一

个Linux环境而已。

至于最后在菜单上点击硬盘分区，甚至还打开里面的文件看看，这就是纯属找死了。系统已

经报错了，即使能够挂载成功，文件系统也很可能是有问题的，必须在访问前先fsck，否

则很可能会引发更大的问题。毕竟默认Fedora挂载可不是只读，而是可读写，混乱后，

谁也无法预测会把硬盘写成啥样。

三、确认问题

该冻结首行怎么设置 准备的光盘准备了，不该操作的操作也做了，这让我很无语，虽然怀疑仅仅是逻辑错误导

致superblock坏掉，应该不会有大问题，但还是让我对这次修复的可能性感到怀疑。至少

这朋友完全不按照我说的办，经常的做些自己觉得没什么的危险操作，哎，前景黯淡啊。

既然他已经改点的都点了，该造成的损坏基本上也造成了。那就在FedoraLiveCD的图

形界面下修复吧，至少他还可以更方便的把命令返回结果通过firefox给我发过来。比用

android手机通讯好多了。

首先我需要知道，都有哪些文件系统被他挂载了，另外，系统上有哪些分区。

[root@localhostliveur]#mount|grepLogVol

/dev/mapper/VolGroup_ID_17253-LogVol4on/media/0edef924-567f-45fc-9609-

51722cad6e9etypeext3(rw,nosuid,nodev,uhelper=udisks)

/dev/mapper/VolGroup_ID_17253-LogVol7on/media/ee0c40c6-d9d1-4a81-9806

-9991621db1ddtypeext3(rw,nosuid,nodev,uhelper=udisks)

/dev/mapper/VolGroup_ID_17253-LogVolHomeon/media/f524534e-3d24-4a22-

b475-9e4b7dac0d35typeext3(rw,nosuid,nodev,uhelper=udisks)

/dev/mapper/VolGroup_ID_17253-LogVol6on/media/12953c57-baba-4358-baeb

-cdd17d6513a2typeext3(rw,nosuid,nodev,uhelper=udisks)

好嘛，据我所知，服务器上好像有5个绑定目录的分区，LogVol{3,4,6,7,Home}，Log

Vol3好像就是那个坏的分区，想绑也绑不上，除了它，他全绑上了。

我需要确定LVM总共有哪些分区，lvscan命令可以告诉我们LVM下面的分区情况。

[root@localhostliveur]#lvscan

ACTIVE'/dev/VolGroup_ID_17253/LogVol3'[10.00GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVol4'[1.06GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253年会策划 /LogVol7'[53.56GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVol6'[5.38GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVol1'[2.00GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVol0'[2.00GiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVol2'[64.00MiB]inherit

ACTIVE'/dev/VolGroup_ID_17253/LogVolHome'[29.44GiB]inherit

嗯，LogVol{0,1}是交换分区，LogVol2肯定不是我们的目标，那么缺失的是LogVol3，

这个分区出问题了。如此，我们手动绑定一下LogVol3看一下报错信息。

[root@localhostliveur]#mkdir/media/myroot

[root@localhostliveur]#mount-text3/dev/mapper/VolGroup_ID_17253-Log

Vol3/media/myroot

mount:wrongfstype,badoption,badsuperblockon/dev/mapper/VolGroup_ID_

17253-LogVol3,

missingcodepageorhelperprogram,orothererror

Insomecasufulinfoisfoundinsyslog-try

dmesg|tailorso

这里我们可以直接看到报错说'badsuperblock'信息。

然后我们再看一下内核报错。

[root@localhostliveur]#dmesg|tail-n20

[343.583694]EXT3-fs(dm-3):mountedfilesystemwithordereddatamode

[343.585926]SELinux:initialized(devdm-3,typeext3),usxattr

[346.179128]EXT3-fs:barriersnotenabled

[346.183702]interval5conds

[346.189688]EXT3-fs(dm-4):usinginternaljournal

[346.189694]EXT3-fs(dm-4):mountedfilesystemwithordereddatamode

[346.193216]SELinux:initialized(devdm-4,typeext3),usxattr

[348.911539]EXT3-fs:barriersnotenabled

[348.918113]interval5conds

[348.918151]EXT3-fs(dm-9):warning:mountingfswitherrors,runninge2fsc

kisrecommended

[348.922722]EXT3-fs(dm-9):usinginternaljournal

[348.922728]EXT3-fs(dm-9):mountedfilesystemwithordereddatamode

[348.922738]SELinux:initialized(devdm-9,typeext3),usxattr

[350.225535]EXT3-fs:barriersnotenabled

[350.230730]interval5conds

[350.236075]EXT3-fs(dm-5):usingintern谁劈山救母 aljournal

[350.236081]EXT3-fs(dm-5):mountedfilesystemwithordereddatamode

[350.241386]SELinux:initialized(devdm-5,typeext3),usxattr

[1957.796112]EXT3-fs(dm-2):error:can'tfindext3filesystemondevdm-2.

[2688.247855]EXT3-fs(dm-2):error:can'tfindext3filesystemondevdm-2.

这里我们看到，内核报错说无法在dm-2上找到ext3文件系统。这很有可能就是supe

rblock损坏造成的问题。

另外，我们看到，正如我所担心的那样，不仅仅是dm-2(LogVol3)有故障，dm-9分

区也有故障。很可能其它分区也有问题，都需要在使用前，进行磁盘检查fsck。冒失的访

问，很可能会造成数据损坏或丢失。

如此，我们基本上可以确定是superblock的损坏，至于是否还有其它故障，以及是否有

数据损失，需要在fsck之后才能知道了。

四、镜像备份损坏的硬盘

执行fsck会对磁盘进行写操作，我们需要在此之前对磁盘进行镜像备份。这样万一fsck

的修复造成了更大的损失，我们还可以恢复原始状态。

我让朋友插上USB硬盘，桌面上会自动出现这个硬盘的图标，如果没有菜单上也会有，

点击菜单项打开这个USB硬盘，会触发Fedora自动绑定该硬盘。这么操作省的朋友敲

命令了(心里想，反正之前不该点的也都点了，破罐破摔吧～～)。

通过mount命令找到新绑定的磁盘路径：

/dev/sdb1on/media/BACKUPtypefublk(rw,nosuid,nodev,allow_other,blksize

=4096,default_permissions)

然后，开始镜像LogVol3：

[root@localhost~]#ddif=/dev/VolGroup_ID_17253/LogVol3|gzip>/media/BA

CKUP/rver_root_

20971520+0recordsin

20971520+0recordsout

1bytes(11GB)copied,666.429s,16.1MB/s

确认一下文件确实存在：

[root@localhost~]#ls-l/media/BACKUP/*.gz

-rwxrwxrwx.1liveurliveur5943229016Feb1017:29/media/BACKUP/rve

r_root_

五、修复

先进行第一次修复尝试。

[root@localhostliveur]#3-B1024/dev/mapper/VolGroup_ID_17253-

LogVol3

e2fsck1.41.12(17-May-2010)

3:Superblockinvalid,tryingbackupblocks

3:Badmagicnumberinsuper-blockwhiletryingtoopen/dev/mapper/Vo

lGroup_ID_1725团结合作 3-LogVol3

Thesuperblockcouldnotbereadordoesnotdescribeacorrectext饿了吗创始人 2

eviceisvalidanditreallycontainsanext2

filesystem(andnotswaporufsorsomethingel),thenthesuperblock

iscorrupt,andyoumighttryrunninge2fsckwithanalternatesuperblock:

e2fsck-b8193

这里面说无法修复，原因是superblock损坏了，所以fsck无法定位相关分区数据。建

议使用备份的superblok。

我们知道，superblock对于分区而言非常重要，因此ext2/3文件系统将superblock

备份到了磁盘的各个位置，如此多的备份，降低了所有superblock备份都损坏的概率。

可是问题是，这些备份在哪里呢？superblock的备份是和blocksize相关的。询问后得

知，这个服务器上的分区的参数都是默认设置，只是调整了一下大小和个数。既然如此，那

么所有的分区都应该是同样的blocksize，那么它们备份superblock的相对位置也都一

样。

鉴于此，我们打算通过LogVol7分区给出一个superblock备份相对位置的列表：

[root@localhostliveur]#dumpe2fs/dev/VolGroup_ID_17253/LogVol7|grep-

isuperblock

dumpe2fs1.41.12(17-May-2010)

Primarysuperblockat0,Groupdescriptorsat1-4

Backupsuperblockat32768,Groupdescriptorsat32769-32772

Backupsuperblockat98304,Groupdescriptorsat98305-98308

Backupsuperblockat163840,Groupdescriptorsat163841-163844

Backupsuperblockat229376,Groupdescriptorsat229377-229380

Backupsuperblockat294912,Groupdescriptorsat294913-294916

Backupsuperblockat819200,Groupdescriptorsat819201-819204

Backupsuperblockat884736,Groupdescriptorsat884737-884740

Backupsuperblockat1605632,Groupdescriptorsat1605633-1605636

Backupsuperblockat2654208,Groupdescriptorsat2654209-2654212

Backupsuperblockat4096000,Groupdescriptorsat4096

Backupsuperblockat7962624,Groupdescriptorsat7962625-7962628

Backupsuperblockat11239424,Groupdescriptorsat11239425-11239428

尝试使用32768的备份：

[root@localhostliveur]#3-B1024-b32768/dev/mapper/VolGroup_I

D_17253-LogVol3

e2fsck1.41.12(17-May-2010)

3:Badmagicnumberinsuper-blockwhiletryingtoopen/dev/mapper/Vo

lGroup_ID_17253-LogVol3

Thesuperblockcouldnotbereadordoesnotdescribeacorrectext2

eviceisvalidanditreallycontainsanext2

filesystem(andnotswaporufsorsomethingel),thenthesuperblock

iscorrupt,andyoumighttryrunninge2fsckwithanalternatesuperblock:

e2fsck-b8193

这个备份还是不行，再换一个：

[root@localhostliveur]#3-b98304/dev/VolGroup_ID_17253/LogVol3

e2fsck1.41.12(17-May-2010)

Superblockneeds_recoveryflagisclear,butjournalhasdata.

Recoveryflagnottinbackupsuperblock,sorunningjournalanyway.

/dev/VolGroup_ID_17253/LogVol3:recoveringjournal

Addingdirhashhinttofilesystem.

Pass1:Checkinginodes,blocks,andsizes

Inode81,i_blocksis8,?

不错，98304这个备份是好的。已经修复了一些内容了，只要继续就很有可能修复系统。

不过，当我让朋友点击y确认的时候，悲剧又发生了。他在复制粘贴返回信息的时候，习

惯了Windows的Ctrl-C和Ctrl-V，呃，我们要知道，Ctrl-C在命令行下有另外的含

义，就是终止程序运行。结果，他按Ctrl-C了……

[1]+3-b98304/dev/VolGroup_ID_17253/LogVol3

磁盘修复一半的时候强行终止退出？我现在非常不确定系统当前的状态和磁盘的状态，我只

好让朋友重新启动，重来。重启前跟他说，千万不要再做任何异常的操作了，否则可能系统

会无法恢复的。

很不幸，我的话又变成了耳旁风。重启后，他兴高采烈的告诉我说，可以看见LogVol3

啦，不过有些文件夹还是打不开啊。我晕倒～～

我非常怀疑他是不是关心硬盘的数据。这个硬盘仅仅是恢复了superblock，但是必然还有

很多其它的问银行员工年终总结 题，冒然以可写形式绑定，磁盘很可能会丢数据的。我给了他严重警告，再这

么做我就不帮忙了，我替你担心半天，你反而不听我劝，混不在乎。

重新开始修复硬盘：

[root@localhostliveur]#3-y-b98304/dev/VolGroup_ID_17253/LogV

ol3

Freeblockscountwrongforgroup#78(32254,counted=5049).

Fix?yes

Freeblockscountwrongforgroup#79(32254,counted=4724).

Fix?yes

Freeblockscountwrong(2566343,counted=1869026).

Fix?yes

Freeinodescountwrongforgroup#0(16373,counted=16288).

Fix?yes

/dev/VolGroup_ID_17253/LogVol3:*****FILESYSTEMWASMODIFIED*****

/dev/VolGroup_ID_17253/LogVol3:229199/1310720files(1.6%non-contiguou

s),752414/2621440blocks

经过了一段时间的等待，LogVol3修复终于完成了。由于得知当时LogVolHome进行了

大量的读写，因此，虽然可以挂载，但是非常怀疑其中也有故障，因此也许进行磁盘检查和

修复：

[root@localhost/]#3/dev/VolGroup_ID_17253/LogVolHome

e2fsck1.41.12(17-May-2010)

/dev/VolGroup_ID_17253/LogVolHomecontainsafilesystemwitherrors,checkf

orced.

Pass1:Checkinginodes,blocks,andsizes

Pass2:Checkingdirectorystructure

Pass3:Checkingdirectoryconnectivity

Pass4:Checkingreferencecounts

Pass5:Checkinggroupsummaryinformation

/dev/VolGroup_ID_17253/LogVolHome:2301889/3859072files(9.9%non-contig

uous),2554717/7716864blocks

果然，确实有错误，并且修复了。

然后，尝试挂载LogVol3，看这次是否没有问题了：

[root@localhost/]#mkdir/media/myroot

[root@localhost/]#mount-text3/dev/VolGroup_ID_17253/LogVol3/media/my

root

一切正常，没有任何报错。磁盘修复基本可以宣告完成，接下来就是备份和重新启动了。

六、备份重要数据

重新启动系统，如果一切正常，系统会正常加载所有的服务器，并且开始提供服务，那时数

据就会发生改变了，在还不知道服务器是否正常的情况下贸然启动服务器，而没有备份，这

是危险的。因此，我们先备份重要数据。

[root@localhost/]#cd/media/myroot

[root@localhostmyroot]#tar-czvf/media/BACKUP/

[root@localhostmyroot]#tar-czvf/media/BACKUP/rver_/lampp

[root@localhostmyroot]#tar-czvf/media/BACKUP/rver_/lampp/

var/mysql

最后确认一下数据是否已经备份好了。

[root@localhostmyroot]#lsl/media/BACKUP

total6287380

-rwxrwxrwx.1liveurliveur92690926Feb1019:35rver_

-rwxrwxrwx.1liveurliveur28670158Feb1019:30rver_

-rwxrwxrwx.1liveurliveur5943229016Feb1017:29rver_root_

-rwxrwxrwx.1liveurliveur373677732Feb1019:

七、重新启动

分区修好了，fsck检查各个分区也都没问题了，该备份的都备份了。可以尝试重新启动系

统了，祈祷吧……

很不幸，没起来。:(

启动的过程，系统报错：

Remountingrootfilesysteminread-writemode:

SettingupLogicalVolumeManagement:

Checkingfilesystems

/boot:clean,38/26208files,15754/104420blocks

/dev/VolGroup_ID_17253/LogVol4:clean,22/139392files,12950/278528blocks

/dev/VolGroup_ID_17253/LogVol7:clean,132904/7028736files,882601/140410

88blocks

/dev/VolGroup_ID_17253/LogVol6:clean,22314/704512files,168941/140902

4blocks

/dev/VolGroup_ID_17253/LogVolHomecontainsafilesystemwitherrors,checkf

orced.

/dev/VolGroup_ID_17253/LogVolHome:

Inode1340876istoobig.

/dev/VolGroup_ID_17253/LogVolHome:UNEXPECTEDINCONSISTENCY;RUNfsc

kMANUALLY.

(i.e.,without-aor-poptions)

[FAILED]

***Anerroroccurredduringthefilesystemcheck.

***Droppingyoutoashell;thesystemwillreboot

***whenyouleavetheshell.

***Warning--SELinuxisactive

***Disablingcurityenforcementforsystemrecovery.

***Run'tenforce1'toreenable.

Giverootpasswordformaintenance

(ortypeControl-Dtocontinue):_

经过Google，发现这是e2fsprogs，也就是3所在包，早期版本的一个bug。

如果inode节点很大，会触发这个bug。1.40以后就没有这个问题了，

这也看出来我一直坚持要升级的原因之一。越早的版本的软件包含的bug就越多，每年新

的版本都会修复大量的bug。而那些坚持版本越老越稳定的人，实际上是非常错误的。太

新和太老都是不合理的，要取一个合适的折中。像RHEL4，甚至5，就太老了。其内很

多版本包含了大量的bug，可是由于没有升级到新的版本，RedHat不得不花大力气去将修

复bug的补丁打到老的软件上，而有相当数量的补丁是完全基于新版本API的，那些补丁

就没有办法打在老软件上。RHEL/CentOS所谓的长期稳定，也就是因为RedHat有大量

的人力在做这种将新软件的补丁打到老软件上的事情。可是，有些时候，我们直接用新的版

本会更好。

我没心思在LiveCD里面升级e2fsprogs，这是个危险的操作。触发这个bug的条件是一

个目录下的文件太多，从而导致inode过大。了解了一下，那个目录正好是服务器故障前

正在清理的目录。那么我们就先把这个目录清理掉再说。

由于这个目录包含有太多的文件，计算了一下清理这个目录会花1-2个小时。已经是凌晨

了，写了个脚本，开始执行，清理完文件后，会自动重启。基本上该做的都做了，应该没有

什么问题了。脚本执行后，就让朋友回家好了。

很幸运，朋友到家后，给我发来消息，服务器正常启动了，Web应用也都开始正常提供服

务了。一切似乎都恢复正常了。很庆幸，没有机会用上备份(那就意味着要重装系统之类的

大操作了)。

八、后记

这次系统故障导致我朋友很紧张的原因之一就是系统没有备份。最近一次备份也是几个月

前，因此如果硬盘无法恢复，那么直接造成的结果就是这几个月的工作全部丢失。其实使用

Linux备份还是比较容易的。最简单的办法是用crontab，定义的压缩一份重要数据，传到

别的服务器上去，或者复制到别的物理硬盘上。可惜由于他们公司对Linux熟悉的人不多，

因此没有人去做而已。

这也反映了一个问题。我们经常看到类似于，“什么服务器最安全快速？”、“什么编程语言

效率最高？”的问题。这类问题实际上问题本身就有问题。没有最安全的服务器，没有最好

的编程语言，只有最合适你的。

很多人都说Linux如何如何安全，Windows如何如何脆弱。真不知道这些人从哪得到的

数据？还是大脑进水了？如果你说的是精心配置下的服务器，那么很难说谁更安全，Wind

ows的内核非常健壮，相比Linux而言，更稳定和安全。你只要查一下Linux内核在过

去几年内所出现的安全漏洞的数量，对比一下Windows2000/2003内核的漏洞的数量，

你就会发现这个问题。而IIS出现的安全漏洞，和Apache比起来，谁也不敢说谁更安

全。而就配置而言，我们都可以对每个服务器配置执行账户，限定用户权限。相比而言，W

indows的ACL比Linux的要更复杂和完善。当然，Linux也有Linux的优势。它们

是处于一个安全等级上的。无论哪个系统，都可以配置出安全、高效的服务器。

但是，你得精心配置啊。我想大多数人对二者的安全配置并不熟悉，也似乎没有花大量的经

历和试验去熟悉。那么对大多数人而言，似乎默认配置就是最好的。就像我这个朋友，问他

各个配置为什么这样，为什么那样，他几乎都是一个答案，不知道和默认就是这样，没改。

这让我很无语。

安全界上，凡是默认配置的，基本都是有隐患的。大多数入侵啊、蠕虫啊，也都是针对默认

配置的机器做的。不管你是Linux也好，Windows也罢。只要是默认配置，你就不要提

什么谁更安全，那是扯淡。

还有一个问题就是升级。这个服务器用的是RHEL，貌似国内好像比较喜欢用这个。虽然

其内的软件很老，但是这个发布确实比较稳定，你要是用正版的，有售后支持，我也觉得没

什么。但是问题是，国人似乎用盗版成瘾。觉得既然能买RHEL的盗版盘(甚至是下载，都

不用买)，为什么还花钱？这个服务器就是如此。可是，你用盗版，如何升级？而且，盗版

的售后找谁？国外用RHEL的人多，那是冲着售后去的，人家有24小时应急响应，服务器

出了问题很快就能解决。国内人用RHEL，还不用带售后，这是为啥？百思不得其解。哪

怕你用CentOS呢，虽然没有售后，但起码可以升级啊。呵呵，也许人性使然。

不夏朝皇帝列表 论如何，服务器修好了。一切似乎又恢复了正常。但是，真的如此么？造成这次故障的，

致使那个累积了太多文件的php缓存代码还在按照以往工作着，今天出现的问题，说不定

什么时候就又会出现。问题需要进一步的挖掘，才能真正的让服务器，健康的运行。当然，

今天那个朋友可以好好睡个觉了，下一次出问题，起码也是半个月后了，还有时间来分析和

解决深层次的问题。

参考

[1]

/tips/understanding-unixlinux-filesystem-superblock.

html

[2]/wiki/Ext3#Journaling_levels

[3]

/developerworks/cn/linux/filesystem/lvm/lvm-1/

ml