2019独角兽企业重金招聘Python工程师标准>>> 
上周由于公司两次突然的断电,导致公司内部的linux服务器出现异常.
表现为 终端出现： host kernel: journal commit I/O error 的报警信息
然后所有的文件都变为了只读.也无法再通过ssh登陆到服务器. 无奈之下只好关机硬重启.
重启之后一切恢复正常.于是也没有太在意这个事.唉, 看没还是没有运维敏锐的嗅觉,于是错过了最佳的时机.
第二天上午突然又报了 host kernel: journal commit I/O error 的错误.表现和昨天一样.这时候开始意识到问题可能有些严重.
而刚此时终端是链接在服务器上的.于是 极其错误的输入了 reboot指令.寄希望于重启之后可以恢复正常.
然后reboot失败.一直报错. 大概就是 main kernel: BUG: soft lockup CPU#1 stuck for 10s! 一类的提示
没办法 于是只好又关电源重新开机.
于是灾难性的后果发生了.无法进入系统了.
提示如上图..右边本身对linux系统不是太熟悉..于是只好临时抱佛脚 一边上网查资料一边请教做运维的朋友.
于是知道了linux rescue 知道了 centos live cd.不过对live cd不是很熟悉,所以虽然公司有一张live cd的光盘,但太会使用于是又错过了一次机会
最后手动刻了张启动盘,进了救援模式.终于看到了 挂载的原来的系统的目录.
尝试 chroot..失败
尝试切换到 普通的shell , 失败
没办法只能先把数据备份出来.
于是现通过网络装了个新的centos系统.
然后通过 scp 把挂载的整个系统目录发送过来.
经过20多个小时之后,确认这样发送大概需要一周的时间,于是终止.
想先把重要的数据备份.然后悲哀的发现最重要的数据目录都无法进入 提示: NO such file or directory.
彻底杯具了.
然后不死心,死马当活马医. fsck 尝试修复.提示是mount的目录,只能用e2fsck.而使用e2fsck 可能损坏文件系统.
这时也顾不了这么多了.按下了 yes
然后一大堆的 错误提示以及修复成功的信息之后 所有进不去的目录就被彻底删除了..一丝痕迹也见不到了..
系统恢复彻底失败了...
只能在新的系统上重新配置.但是已经丢失的重要数据却再也找不回来了...
隔行如隔山,不懂的东西千万不要乱操作.百度也不是万能的.一味按照网上的操作,结果可能是灾难性的.
运维这东西 经验是灰常灰常重要的..
以上就是这次的惨痛经验和总结教训了