原文位址：http://www.cppblog.com/dancefire/archive/2011/03/09/fix-bad-superblock-in-linux.html
前幾天接到朋友聯系，說他的伺服器壞了，啟動不起來了。這是一個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 "VolGroup_ID_17253" using metadata type lvm2
File descriptor 3 left open
8 logical volume(s) in volume group "VolGroup_ID_17253" now active
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!
_
詢問了一下，癱瘓之前都發生了些什麼。朋友提到了一個情況，在癱瘓前，他發現有一個目錄存儲了太多的檔案了(确實非常的多，大約是幾百萬到上千萬個檔案，程式設計上有問題)，這是他寫的一個php做緩存的腳本生成的字尾為.php的檔案，絕大多數都已經是垃圾檔案了。他覺得太占磁盤空間了，想清理一下，于是用下面的指令删除這些生成的檔案:
find . -name "*.php" -exec rm -f {} \;
可是執行指令後，等了幾分鐘，發現系統沒有反應。于是就Ctrl-C了，後來發現系統還是很慢，于是就執行reboot了。接下來，系統就啟動不起來了。
當時朋友有些慌張了，因為他認為這是他操作失誤導緻伺服器癱瘓，有些不知道該怎麼辦了，那天我有事情比較忙，打算晚些時候再回來幫他。随後的操作中可以看到他做了很多危險的操作，我會一一提出來，大家有類似情況的時候，一定要注意。
這問題就大了。買的SCSI卡的穩定性如何？别是雜牌的，卡再造成硬碟的二次資料損失。用Windows備份可能損壞的硬碟的資料是非常危險的，explorer2fs這類Windows挂載ext2/3分區的軟體從來就沒成熟過，至今為止還有大量的特性不支援，隻是試驗産品。使用他們挂載分區，很可能會造成資料損失。另外，之前說過，問題很可能是superblock出問題了，這種情況下，不修複 superblock ，誰也别想挂載成功，而Windows上顯然沒有這類軟體。
碰到這類問題，比較好的辦法是使用另一台具有SCSI接口的Linux，進行修複、挂載、備份。當然，對于朋友而言，這不現實。那就折中，還在原伺服器上修複，但是使用 Linux LiveCD 進行修複，将資料備份到外置 USB 硬碟上。
這裡需要注意的是，即使硬碟有幾個分區，隻壞了一個，備份到其它貌似還好的分區似乎也不是什麼大問題。但是，在修複、備份的時候，一定要盡可能的避免被修複磁盤的寫操作，無論是哪個分區。因為在問題确認修複前，你并不能肯定隻有那個報錯的分區有故障，其它一切正常。
那天朋友在機房的時候，他什麼都沒有帶，隻能眼睜睜的一次次的重新開機，看錯誤日志，試着能不能進系統。這是很不好的，如果懷疑硬碟出了故障，那麼這麼一次次重新開機很容易加重問題，是以一定要避免。
沒有任何修複環境是沒有辦法工作的。我讓朋友回去準備幾張CD光牒，都是可引導的修複盤。朋友對 Linux 有一些經驗但不是很熟悉，折中起見，我讓朋友準備了 Fedora 14、Ubuntu 10.10、UBCD等CD光牒備用，并且打算使用 Fedora 14 的 Live CD 進行修複。并且第二天帶一個大容量的，最好是空的USB硬碟來，備份資料。并且，在家用 Fedora 14 啟動一下，看看怎麼進入指令行模式，第二天啟動的時候，不要進入圖形界面。在指令行模式下修複。
第二天約好時間後，看了他的gtalk留言，感覺是一身冷汗啊。
首先是告訴我，在伺服器上 Fedora 啟動後直接進桌面了，沒有選項，點了點不知道怎麼修複，甚至打開了故障硬碟的幾個分區，沒找到需要備份的檔案。于是乎，又啟動了Ubuntu選擇了修複壞系統，結果發現要安裝檔案，然後報錯說沒有硬碟，于是退出了。
敢情這哥們直接把我說的話當耳旁風，在故障伺服器上直接啟動圖形界面，更甚的是，他還嘗試讓 Ubuntu 覆寫安裝 RHEL 4。幸好分區的 superblock 是壞的，不然全毀了。
這裡面有三個錯誤。首先是不應該啟動圖形界面，其次是錯誤的了解了 Ubuntu 中修複系統選項的含義，然後是在菜單上點選伺服器分區進而激發了綁定操作，很可能直接造成寫入操作。
這些都應該是前一天晚上回家琢磨的，他顯然偷懶了，直接拿故障環境練手。如果不是這哥們命大，而且系統出的問題沒有那麼嚴重，那麼這些連續的錯誤，很可能造成不可挽回的結果。
雖然對于 Windows 使用者來說，看着純指令行覺得無從下手，但是，得到了美麗的界面往往意味着你得付出些什麼。在以前的某些 LiveCD 中，加載圖形界面的時候，由于各種驅動和程式的加載，錯誤的進行了硬碟的寫操作，進而導緻有些人抱怨過啟動 LiveCD 導緻硬碟資料二次損壞，最終使得修複無望。雖然，最近這些版本的 LiveCD 可能沒有這類問題，但是為了避免萬一，應當盡量減少對硬碟寫入操作的可能性。既然所有修複行為都會在指令行模式下進行，那就沒必要啟動圖形界面冒風險。
我讓他帶着 Ubuntu 的盤就是以防萬一，萬一 Fedora 啟動出現奇怪的問題，我們可以用 Ubuntu 啟動然後修複系統。而不是進入 Ubuntu的修複系統選項。那個選項是給 Ubuntu 系統準備的，是以CD光牒上的系統檔案及配置覆寫硬碟上的系統檔案及配置，進而達到修複系統的目的。這顯然和我們要修複的 RHEL 驢唇不對馬嘴。修複系統所需要的隻是一個 Linux 環境而已。
至于最後在菜單上點選硬碟分區，甚至還打開裡面的檔案看看，這就是純屬找死了。系統已經報錯了，即使能夠挂載成功，檔案系統也很可能是有問題的，必須在通路前先fsck，否則很可能會引發更大的問題。畢竟預設 Fedora 挂載可不是隻讀，而是可讀寫，混亂後，誰也無法預測會把硬碟寫成啥樣。
該準備的CD光牒準備了，不該操作的操作也做了，這讓我很無語，雖然懷疑僅僅是邏輯錯誤導緻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}，LogVol3 好像就是那個壞的分區，想綁也綁不上，除了它，他全綁上了。
我需要确定 LVM 總共有哪些分區，lvscan 指令可以告訴我們LVM下面的分區情況。
[root@localhost liveuser]# lvscan
ACTIVE '/dev/VolGroup_ID_17253/LogVol3' [10.00 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol4' [1.06 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol7' [53.56 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol6' [5.38 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol1' [2.00 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol0' [2.00 GiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVol2' [64.00 MiB] inherit
ACTIVE '/dev/VolGroup_ID_17253/LogVolHome' [29.44 GiB] inherit
嗯，LogVol{0,1}是交換分區，LogVol2肯定不是我們的目标，那麼缺失的是LogVol3，這個分區出問題了。如此，我們手動綁定一下 LogVol3 看一下報錯資訊。
[root@localhost liveuser]# mkdir /media/myroot
[root@localhost liveuser]# mount -t ext3 /dev/mapper/VolGroup_ID_17253-LogVol3 /media/myroot
mount: wrong fs type, bad option, bad superblock on /dev/mapper/VolGroup_ID_17253-LogVol3,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
這裡我們可以直接看到報錯說 'bad superblock' 資訊。
然後我們再看一下核心報錯。
[root@localhost liveuser]# dmesg | tail -n 20
[ 343.583694] EXT3-fs (dm-3): mounted filesystem with ordered data mode
[ 343.585926] SELinux: initialized (dev dm-3, type ext3), uses xattr
[ 346.179128] EXT3-fs: barriers not enabled
[ 346.183702] kjournald starting. Commit interval 5 seconds
[ 346.189688] EXT3-fs (dm-4): using internal journal
[ 346.189694] EXT3-fs (dm-4): mounted filesystem with ordered data mode
[ 346.193216] SELinux: initialized (dev dm-4, type ext3), uses xattr
[ 348.911539] EXT3-fs: barriers not enabled
[ 348.918113] kjournald starting. Commit interval 5 seconds
[ 348.918151] EXT3-fs (dm-9): warning: mounting fs with errors, running e2fsck is recommended
[ 348.922722] EXT3-fs (dm-9): using internal journal
[ 348.922728] EXT3-fs (dm-9): mounted filesystem with ordered data mode
[ 348.922738] SELinux: initialized (dev dm-9, type ext3), uses xattr
[ 350.225535] EXT3-fs: barriers not enabled
[ 350.230730] kjournald starting. Commit interval 5 seconds
[ 350.236075] EXT3-fs (dm-5): using internal journal
[ 350.236081] EXT3-fs (dm-5): mounted filesystem with ordered data mode
[ 350.241386] SELinux: initialized (dev dm-5, type ext3), uses xattr
[ 1957.796112] EXT3-fs (dm-2): error: can't find ext3 filesystem on dev dm-2.
[ 2688.247855] EXT3-fs (dm-2): error: can't find ext3 filesystem on dev dm-2.
這裡我們看到，核心報錯說無法在 dm-2 上找到 ext3 檔案系統。這很有可能就是 superblock 損壞造成的問題。
另外，我們看到，正如我所擔心的那樣，不僅僅是 dm-2 (LogVol3) 有故障， dm-9 分區也有故障。很可能其它分區也有問題，都需要在使用前，進行磁盤檢查 fsck。冒失的通路，很可能會造成資料損壞或丢失。
如此，我們基本上可以确定是 superblock 的損壞，至于是否還有其它故障，以及是否有資料損失，需要在 fsck 之後才能知道了。
執行 fsck 會對磁盤進行寫操作，我們需要在此之前對磁盤進行鏡像備份。這樣萬一 fsck 的修複造成了更大的損失，我們還可以恢複原始狀态。
我讓朋友插上 USB 硬碟，桌面上會自動出現這個硬碟的圖示，如果沒有菜單上也會有，點選菜單項打開這個 USB 硬碟，會觸發 Fedora 自動綁定該硬碟。這麼操作省的朋友敲指令了 (心裡想，反正之前不該點的也都點了，破罐破摔吧～～)。
通過 mount 指令找到新綁定的磁盤路徑：
/dev/sdb1 on /media/BACKUP type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096,default_permissions)
然後，開始鏡像 LogVol3：
[root@localhost ~]# dd if=/dev/VolGroup_ID_17253/LogVol3 | gzip > /media/BACKUP/server_root_image.gz
20971520+0 records in
20971520+0 records out
10737418240 bytes (11 GB) copied, 666.429 s, 16.1 MB/s
确認一下檔案确實存在：
[root@localhost ~]# ls -l /media/BACKUP/*.gz
-rwxrwxrwx. 1 liveuser liveuser 5943229016 Feb 10 17:29 /media/BACKUP/server_root_image.gz
先進行第一次修複嘗試。
[root@localhost liveuser]# fsck.ext3 -B 1024 /dev/mapper/VolGroup_ID_17253-LogVol3
e2fsck 1.41.12 (17-May-2010)
fsck.ext3: Superblock invalid, trying backup blocks
fsck.ext3: Bad magic number in super-block while trying to open /dev/mapper/VolGroup_ID_17253-LogVol3
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
這裡面說無法修複，原因是 superblock 損壞了，是以 fsck 無法定位相關分區資料。建議使用備份的 superblok。
我們知道，superblock 對于分區而言非常重要，是以 ext2/3 檔案系統将 superblock 備份到了磁盤的各個位置，如此多的備份，降低了所有 superblock 備份都損壞的機率。
可是問題是，這些備份在哪裡呢？superblock 的備份是和 block size 相關的。詢問後得知，這個伺服器上的分區的參數都是預設設定，隻是調整了一下大小和個數。既然如此，那麼所有的分區都應該是同樣的 block size，那麼它們備份 superblock 的相對位置也都一樣。
鑒于此，我們打算通過 LogVol7 分區給出一個superblock 備份相對位置的清單：
[root@localhost liveuser]# dumpe2fs /dev/VolGroup_ID_17253/LogVol7 | grep -i superblock
dumpe2fs 1.41.12 (17-May-2010)
Primary superblock at 0, Group descriptors at 1-4
Backup superblock at 32768, Group descriptors at 32769-32772
Backup superblock at 98304, Group descriptors at 98305-98308
Backup superblock at 163840, Group descriptors at 163841-163844
Backup superblock at 229376, Group descriptors at 229377-229380
Backup superblock at 294912, Group descriptors at 294913-294916
Backup superblock at 819200, Group descriptors at 819201-819204
Backup superblock at 884736, Group descriptors at 884737-884740
Backup superblock at 1605632, Group descriptors at 1605633-1605636
Backup superblock at 2654208, Group descriptors at 2654209-2654212
Backup superblock at 4096000, Group descriptors at 4096001-4096004
Backup superblock at 7962624, Group descriptors at 7962625-7962628
Backup superblock at 11239424, Group descriptors at 11239425-11239428
嘗試使用 32768 的備份：
[root@localhost liveuser]# fsck.ext3 -B 1024 -b 32768 /dev/mapper/VolGroup_ID_17253-LogVol3
e2fsck 1.41.12 (17-May-2010)
fsck.ext3: Bad magic number in super-block while trying to open /dev/mapper/VolGroup_ID_17253-LogVol3
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
這個備份還是不行，再換一個：
[root@localhost liveuser]# fsck.ext3 -b 98304 /dev/VolGroup_ID_17253/LogVol3
e2fsck 1.41.12 (17-May-2010)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/VolGroup_ID_17253/LogVol3: recovering journal
Adding dirhash hint to filesystem.
Pass 1: Checking inodes, blocks, and sizes
Inode 81, i_blocks is 8, should be 0. Fix<y>?
不錯，98304 這個備份是好的。已經修複了一些内容了，隻要繼續就很有可能修複系統。不過，當我讓朋友點選 y 确認的時候，悲劇又發生了。他在複制粘貼傳回資訊的時候，習慣了 Windows 的 Ctrl-C 和 Ctrl-V，呃，我們要知道，Ctrl-C 在 指令行下有另外的含義，就是終止程式運作。結果，他按 Ctrl-C 了……
[1]+ Stopped fsck.ext3 -b 98304 /dev/VolGroup_ID_17253/LogVol3
磁盤修複一半的時候強行終止退出？我現在非常不确定系統目前的狀态和磁盤的狀态，我隻好讓朋友重新啟動，重來。重新開機前跟他說，千萬不要再做任何異常的操作了，否則可能系統會無法恢複的。
很不幸，我的話又變成了耳旁風。重新開機後，他興高采烈的告訴我說，可以看見 LogVol3 啦，不過有些檔案夾還是打不開啊。我暈倒～～
我非常懷疑他是不是關心硬碟的資料。這個硬碟僅僅是恢複了 superblock，但是必然還有很多其它的問題，冒然以可寫形式綁定，磁盤很可能會丢資料的。我給了他嚴重警告，再這麼做我就不幫忙了，我替你擔心半天，你反而不聽我勸，混不在乎。
重新開始修複硬碟：
[root@localhost liveuser]# fsck.ext3 -y -b 98304 /dev/VolGroup_ID_17253/LogVol3
Free blocks count wrong for group #78 (32254, counted=5049).
Fix? yes
Free blocks count wrong for group #79 (32254, counted=4724).
Fix? yes
Free blocks count wrong (2566343, counted=1869026).
Fix? yes
Free inodes count wrong for group #0 (16373, counted=16288).
Fix? yes
/dev/VolGroup_ID_17253/LogVol3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/VolGroup_ID_17253/LogVol3: 229199/1310720 files (1.6% non-contiguous), 752414/2621440 blocks
經過了一段時間的等待，LogVol3 修複終于完成了。由于得知當時LogVolHome進行了大量的讀寫，是以，雖然可以挂載，但是非常懷疑其中也有故障，是以也許進行磁盤檢查和修複：
[root@localhost /]# fsck.ext3 /dev/VolGroup_ID_17253/LogVolHome
e2fsck 1.41.12 (17-May-2010)
/dev/VolGroup_ID_17253/LogVolHome contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/VolGroup_ID_17253/LogVolHome: 2301889/3859072 files (9.9% non-contiguous), 2554717/7716864 blocks
果然，确實有錯誤，并且修複了。
然後，嘗試挂載 LogVol3，看這次是否沒有問題了：
[root@localhost /]# mkdir /media/myroot
[root@localhost /]# mount -t ext3 /dev/VolGroup_ID_17253/LogVol3 /media/myroot
一切正常，沒有任何報錯。磁盤修複基本可以宣告完成，接下來就是備份和重新啟動了。
重新啟動系統，如果一切正常，系統會正常加載所有的伺服器，并且開始提供服務，那時資料就會發生改變了，在還不知道伺服器是否正常的情況下貿然啟動伺服器，而沒有備份，這是危險的。是以，我們先備份重要資料。
[root@localhost /]# cd /media/myroot
[root@localhost myroot]# tar -czvf /media/BACKUP/www.tgz www
[root@localhost myroot]# tar -czvf /media/BACKUP/server_lampp.tgz opt/lampp
[root@localhost myroot]# tar -czvf /media/BACKUP/server_mysql.tgz opt/lampp/var/mysql
最後确認一下資料是否已經備份好了。
[root@localhost myroot]# ls l /media/BACKUP
total 6287380
-rwxrwxrwx. 1 liveuser liveuser 92690926 Feb 10 19:35 server_lampp.tgz
-rwxrwxrwx. 1 liveuser liveuser 28670158 Feb 10 19:30 server_mysql.tgz
-rwxrwxrwx. 1 liveuser liveuser 5943229016 Feb 10 17:29 server_root_image.gz
-rwxrwxrwx. 1 liveuser liveuser 373677732 Feb 10 19:34 www.tgz
分區修好了，fsck檢查各個分區也都沒問題了，該備份的都備份了。可以嘗試重新啟動系統了，祈禱吧……
很不幸，沒起來。:(
啟動的過程，系統報錯：
Remounting root filesystem in read-write mode:
Setting up Logical Volume Management:
Checking filesystems
/boot: clean, 38/26208 files, 15754/104420 blocks
/dev/VolGroup_ID_17253/LogVol4: clean, 22/139392 files, 12950/278528 blocks
/dev/VolGroup_ID_17253/LogVol7: clean, 132904/7028736 files, 882601/14041088 blocks
/dev/VolGroup_ID_17253/LogVol6: clean, 22314/704512 files, 168941/1409024 blocks
/dev/VolGroup_ID_17253/LogVolHome contains a file system with errors, check forced.
/dev/VolGroup_ID_17253/LogVolHome:
Inode 1340876 is too big.
/dev/VolGroup_ID_17253/LogVolHome: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
[FAILED]
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Give root password for maintenance
(or type Control-D to continue): _
經過Google，發現這是 e2fsprogs，也就是 fsck.ext3 所在包，早期版本的一個bug。如果inode節點很大，會觸發這個bug。1.40以後就沒有這個問題了，
這也看出來我一直堅持要更新的原因之一。越早的版本的軟體包含的bug就越多，每年新的版本都會修複大量的bug。而那些堅持版本越老越穩定的人，實際上是非常錯誤的。太新和太老都是不合理的，要取一個合适的折中。像 RHEL 4，甚至5，就太老了。其内很多版本包含了大量的bug，可是由于沒有更新到新的版本，RedHat不得不花大力氣去将修複bug的更新檔打到老的軟體上，而有相當數量的更新檔是完全基于新版本API的，那些更新檔就沒有辦法打在老軟體上。RHEL/CentOS所謂的長期穩定，也就是因為RedHat有大量的人力在做這種将新軟體的更新檔打到老軟體上的事情。可是，有些時候，我們直接用新的版本會更好。
我沒心思在LiveCD裡面更新e2fsprogs，這是個危險的操作。觸發這個bug的條件是一個目錄下的檔案太多，進而導緻inode過大。了解了一下，那個目錄正好是伺服器故障前正在清理的目錄。那麼我們就先把這個目錄清理掉再說。
由于這個目錄包含有太多的檔案，計算了一下清理這個目錄會花1-2個小時。已經是淩晨了，寫了個腳本，開始執行，清理完檔案後，會自動重新開機。基本上該做的都做了，應該沒有什麼問題了。腳本執行後，就讓朋友回家好了。
很幸運，朋友到家後，給我發來消息，伺服器正常啟動了，Web應用也都開始正常提供服務了。一切似乎都恢複正常了。很慶幸，沒有機會用上備份(那就意味着要重裝系統之類的大操作了)。
這次系統故障導緻我朋友很緊張的原因之一就是系統沒有備份。最近一次備份也是幾個月前，是以如果硬碟無法恢複，那麼直接造成的結果就是這幾個月的工作全部丢失。其實使用Linux備份還是比較容易的。最簡單的辦法是用crontab，定義的壓縮一份重要資料，傳到别的伺服器上去，或者複制到别的實體硬碟上。可惜由于他們公司對 Linux 熟悉的人不多，是以沒有人去做而已。
這也反映了一個問題。我們經常看到類似于，“什麼伺服器最安全快速？”、“什麼程式設計語言效率最高？”的問題。這類問題實際上問題本身就有問題。沒有最安全的伺服器，沒有最好的程式設計語言，隻有最合适你的。
很多人都說 Linux 如何如何安全，Windows 如何如何脆弱。真不知道這些人從哪得到的資料？還是大腦進水了？如果你說的是精心配置下的伺服器，那麼很難說誰更安全，Windows 的核心非常健壯，相比 Linux 而言，更穩定和安全。你隻要查一下 Linux 核心在過去幾年内所出現的安全漏洞的數量，對比一下 Windows 2000/2003核心的漏洞的數量，你就會發現這個問題。而 IIS 出現的安全漏洞，和 Apache 比起來，誰也不敢說誰更安全。而就配置而言，我們都可以對每個伺服器配置執行賬戶，限定使用者權限。相比而言，Windows 的 ACL 比 Linux 的要更複雜和完善。當然，Linux 也有 Linux 的優勢。它們是處于一個安全等級上的。無論哪個系統，都可以配置出安全、高效的伺服器。
但是，你得精心配置啊。我想大多數人對二者的安全配置并不熟悉，也似乎沒有花大量的經曆和試驗去熟悉。那麼對大多數人而言，似乎預設配置就是最好的。就像我這個朋友，問他各個配置為什麼這樣，為什麼那樣，他幾乎都是一個答案，不知道和預設就是這樣，沒改。這讓我很無語。
安全界上，凡是預設配置的，基本都是有隐患的。大多數入侵啊、蠕蟲啊，也都是針對預設配置的機器做的。不管你是 Linux 也好，Windows 也罷。隻要是預設配置，你就不要提什麼誰更安全，那是扯淡。
還有一個問題就是更新。這個伺服器用的是 RHEL，貌似國内好像比較喜歡用這個。雖然其内的軟體很老，但是這個釋出确實比較穩定，你要是用正版的，有售後支援，我也覺得沒什麼。但是問題是，國人似乎用盜版成瘾。覺得既然能買 RHEL的盜版盤(甚至是下載下傳，都不用買)，為什麼還花錢？這個伺服器就是如此。可是，你用盜版，如何更新？而且，盜版的售後找誰？國外用RHEL的人多，那是沖着售後去的，人家有24小時應急響應，伺服器出了問題很快就能解決。國内人用 RHEL，還不用帶售後，這是為啥？百思不得其解。哪怕你用CentOS呢，雖然沒有售後，但起碼可以更新啊。呵呵，也許人性使然。
不論如何，伺服器修好了。一切似乎又恢複了正常。但是，真的如此麼？造成這次故障的，緻使那個累積了太多檔案的php緩存代碼還在按照以往工作着，今天出現的問題，說不定什麼時候就又會出現。問題需要進一步的挖掘，才能真正的讓伺服器，健康的運作。當然，今天那個朋友可以好好睡個覺了，下一次出問題，起碼也是半個月後了，還有時間來分析和解決深層次的問題。
![Apache配置SSLApache配置SSL[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)