关于linux:翻车误删usrlib引发的血案从棺材边成功抢救的过程分享

36次阅读

共计 1039 个字符,预计需要花费 3 分钟才能阅读完成。

写在开篇

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

抢救过程

  1. 找一台同一个 ISO 装置的、且失常运行的零碎进行比照 /usr/lib/ 门路下的文件数量

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

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

发现只有 44 个了,和失常的 OS 比照少了 5 个,尽管过后马上 ctrl+ c 终止了,手速再快也无力回天了,还是丢了文件。对于如何进入救济模式,持续往下看哈。

  1. 接着,从失常的 os 中,进入 /usr 目录,间接在相对路径中打包 lib 目录,最终失去 lib.tar.gz 文件,并把它 sz 到本地。
  2. 通过软碟通(UltraISO)关上 CentOS7 的 ISO 镜像文件,并增加文件 lib.tar.gz 文件到其根目录下,最初另存为一个新的 ISO 镜像文件。
  1. 通过这个增加了 lib.tar.gz 文件的 CentOS7 镜像启动,并进入救济模式,进入救济模式的整个过程如下:

到此为止就进入到救济模式下了,且进入的是虚构零碎的根目录,实在的目录存储在 /mnt/sysimage 上面

  1. 应用 chroot 命令切换到实在的根目录

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

挂载光驱胜利后,留神到了 lib.tar.gz 文件了吗?没错了,就是之前把它弄进去的。

  1. 将 lib.tar.gz 复制进去,并将其解压后,拷贝到 /usr/lib/ 下,且是笼罩其所有。而后关机,并将其的启动程序设置为从硬盘启动,而后开机

  1. 开机后,发现曾经失常进入操作系统,完满!胜利从棺材边抢救回来了。

写在最初

从这种小事就能够阐明,我是一个大头虾!如果是线上的生产环境这么个搞法,预计要进监狱了。尽管这次的血案是产生在本人本地的开发机中,同时也给我敲响了一个警钟:敬畏生产环境!

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

正文完
 0