共计 1039 个字符，预计需要花费 3 分钟才能阅读完成。
写在开篇
血案：本地开发机是 CentOS 7，本想删除在 /usr/lib/ 下的一个软链，如：/usr/lib/xxx。当正想删除时，忽然被别的事件打搅了一下，回过神之后莫名微妙的执行了命令：“rm -rf /usr/lib/”，遗记指定文件名了，你说难堪不难堪？就在千钧一发之际，马上进行了 ctrl+ c 终止了。但，血案还是产生了，景象就是重启后无奈失常进入操作系统了。因日常应用的开发机各种环境都曾经搭建好，就不想折腾了。尽管它是虚拟机，但我没有每时每刻对它做快照，就算复原以前做过的快照，那也不是我想要的样子了。所以，决定对它进行抢救。
抢救过程
- 找一台同一个 ISO 装置的、且失常运行的零碎进行比照 /usr/lib/ 门路下的文件数量
下面的截图中，就是失常运行的 OS，/usr/lib 下的文件数量是 49 个。
- 曾经损坏的操作系统，在救济模式查看 /usr/lib/ 门路下的文件数量
发现只有 44 个了，和失常的 OS 比照少了 5 个，尽管过后马上 ctrl+ c 终止了，手速再快也无力回天了，还是丢了文件。对于如何进入救济模式，持续往下看哈。
- 接着，从失常的 os 中，进入 /usr 目录，间接在相对路径中打包 lib 目录，最终失去 lib.tar.gz 文件，并把它 sz 到本地。
- 通过软碟通（UltraISO）关上 CentOS7 的 ISO 镜像文件，并增加文件 lib.tar.gz 文件到其根目录下，最初另存为一个新的 ISO 镜像文件。
- 通过这个增加了 lib.tar.gz 文件的 CentOS7 镜像启动，并进入救济模式，进入救济模式的整个过程如下：
到此为止就进入到救济模式下了，且进入的是虚构零碎的根目录，实在的目录存储在 /mnt/sysimage 上面
-
应用 chroot 命令切换到实在的根目录
chroot /mnt/sysimage/
- 挂载光驱到 /home/isodata 目录下
挂载光驱胜利后，留神到了 lib.tar.gz 文件了吗？没错了，就是之前把它弄进去的。
- 将 lib.tar.gz 复制进去，并将其解压后，拷贝到 /usr/lib/ 下，且是笼罩其所有。而后关机，并将其的启动程序设置为从硬盘启动，而后开机
- 开机后，发现曾经失常进入操作系统，完满！胜利从棺材边抢救回来了。
写在最初
从这种小事就能够阐明，我是一个大头虾！如果是线上的生产环境这么个搞法，预计要进监狱了。尽管这次的血案是产生在本人本地的开发机中，同时也给我敲响了一个警钟：敬畏生产环境！
本文转载于（喜爱的盆友关注咱们）：https://mp.weixin.qq.com/s/TF…