这个备份还是不行，再换一个：
[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
不错，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不得不花大力气去将修