翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

2年前 (2022) 程序员胖胖胖虎阿
199 0 0

写在开篇

血案:本地开发机是CentOS 7,本想删除在/usr/lib/下的一个软链,如:/usr/lib/xxx。当正想删除时,突然被别的事情打扰了一下,回过神之后莫名奇妙的执行了命令:“rm -rf /usr/lib/”,忘记指定文件名了,你说尴尬不尴尬?就在千钧一发之际,马上进行了ctrl+c终止了。但,血案还是发生了,现象就是重启后无法正常进入操作系统了。因日常使用的开发机各种环境都已经搭建好,就不想折腾了。虽然它是虚拟机,但我没有每时每刻对它做快照,就算恢复以前做过的快照,那也不是我想要的样子了。所以,决定对它进行抢救。

抢救过程

  1. 找一台同一个ISO安装的、且正常运行的系统进行对比/usr/lib/路径下的文件数量

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

上面的截图中,就是正常运行的OS,/usr/lib下的文件数量是49个。

  1. 已经损坏的操作系统,在救援模式查看/usr/lib/路径下的文件数量

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

发现只有44个了,和正常的OS对比少了5个,虽然当时马上ctrl+c终止了,手速再快也无力回天了,还是丢了文件。关于如何进入救援模式,继续往下看哈。

  1. 接着,从正常的os中,进入/usr目录,直接在相对路径中打包lib目录,最终得到lib.tar.gz文件,并把它sz到本地。
  2. 通过软碟通(UltraISO)打开CentOS7的ISO镜像文件,并添加文件lib.tar.gz文件到其根目录下,最后另存为一个新的ISO镜像文件。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

  1. 通过这个添加了lib.tar.gz文件的CentOS7镜像启动,并进入救援模式,进入救援模式的整个过程如下:

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

到此为止就进入到救援模式下了,且进入的是虚拟系统的根目录,真实的目录存储在/mnt/sysimage下面

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

  1. 使用chroot命令切换到真实的根目录

    chroot /mnt/sysimage/

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

  1. 挂载光驱到/home/isodata目录下

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

挂载光驱成功后,注意到了lib.tar.gz文件了吗?没错了,就是之前把它弄进去的。

  1. 将lib.tar.gz复制出来,并将其解压后,拷贝到/usr/lib/下,且是覆盖其所有。然后关机,并将其的启动顺序设置为从硬盘启动,然后开机

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

  1. 开机后,发现已经正常进入操作系统,完美!成功从棺材边抢救回来了。

翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。

写在最后

从这种小事就可以说明,我是一个大头虾!如果是线上的生产环境这么个搞法,估计要进监狱了。虽然这次的血案是发生在自己本地的开发机中,同时也给我敲响了一个警钟:敬畏生产环境!

本文转载于(喜欢的盆友关注我们):https://mp.weixin.qq.com/s/TF...

相关文章

暂无评论

暂无评论...