“新员工入职仅一个月，以敏锐的技术眼光完成了令人瞩目的任务：敲完了 rm -rf /bin，展现了出色的技术能力和决策胆识

自述  

        没错，这件事情说的就是小编，在寒风凛冽的的一个晚上，要下班临走了，结果误操作敲了rm -rf /bin 这条命令，整个大脑瞬间都空了。

        当然，遇到这件事的时候先冷静下来，寻找解决问题的办法，如果怕自己解决不了，一定要第一时间上报给，公司如果有经验的运维师傅，那完全可以求助一下，做为一名合格的运维人员这应该是比较常见也比较严重的误操作。

        很多人会问了，为什么公司会给你一个新人root权限。我们公司是做站群的，有若干的子站点，如果用普通用户权限的话，需要每台机器都要给普通用户受一下权限，这样是比较繁琐的，而且业务刚刚起步，使用root在执行一些初始化操作的使用也更加灵活。但是这里我想说，给了root权限之后，就相当于给了一个定时炸弹，这个炸弹随时可能会爆炸。

        那你为什么无缘无故删除bin目录呢，没什么人会去专门的删除它。我在做业务的时候根据脚本，py文件以及日志文件，划分了三个子目录，分别为config，logs，bin，其实懂的人不用解释，一个放配置文件，一个放日志文件，另一个放可执行文件或者变量，所以我的脚本就放在了bin目录下，后来经过优化，这个脚本不需要了，于是我打算删除这个目录，我想要的是删除当前目录的bin，也就是 rm -rf bin/   没成想多带了个/，就一/之隔，职业生涯差点结束了。

做为老程序员来说其实删的这个目录并非致命，而且完全可以恢复，我们先来了解一下/bin目录里有什么呢？

可以看到，这个目录下都是一些可执行的文件，用cat去打开的时候，我们发现，文件其实并不能被直接查看。

         所以也就是说，这个目录下，全都是一些用于存放系统命令的可执行文件（二进制文件），删除或者移动目录的位置之后整个系统命令都没了，只是命令没有了，服务器内的业务，数据也都是存在的，但是基本上整个业务都会崩溃掉，甚至说关机之后系统就打不开了。

        那么这么严重的问题是怎么解决的呢，有以下几种解决方法：

       1、有快照的回复快照

        2、插入一块光盘，进入救援模式，在修复模式里挂载光盘（只适用于线下实体服务器）

        3、云上的服务器，比如阿里云，挂载一块光盘或者镜像文件，进入 Rescue 模式，在Rescue 模式内恢复。

        4.   备份恢复，将整个系统的完全备份覆盖掉当前的系统状态。

当然根据优先级，我们先把2、或者3放在最前，把快照放在最后，不到万不得已才使用快照，一定要保障业务的最小损失。

那么这里我来具体讲一下方法2和方法3

        方法2：

                1、绑定一块光盘或者镜像。

                2、进入Rescue 模式

                        ①登录到阿里云管理控制台。

                        ②找到你的实例，点击实例名称进入实例详情页。

                        ③在左侧导航栏中，选择“更多” > “实例状态” > “系统修复”。

                        ④按照页面提示选择 Rescue 模式，并重启实例。

                3、挂载根分区：

                        进入 Rescue 模式后，你需要挂载包含根文件系统的分区。常见的根分区设备可能是 /dev/vda1 或 /dev/sda1。执行以下命令

mount /dev/vda1 /mnt

                4、还原/bin目录：

                        获取 /bin 目录的备份或从其他相同系统的实例中复制 /bin 目录的内容，并将其复制到 /mnt/bin/ 目录下。你可以使用 cp 命令或 rsync 命令。

cp -r  /mnt/bin/  /bin/

或者

rsync -a /mnt/bin/ /bin/

                5、修复权限：

                              记住这一步非常关键，没有权限整个系统命令照样没有办法使用。

                              确保 /bin 目录及其内容的权限正确。使用 chmod 命令进行修复：

chmod 755 /bin/*

                6、卸载根分区：

umount /mnt

                7、重启服务器：

                        退出 Rescue 模式，并重启服务器。你可以通过控制台或命令行执行重启操作

        方法3：

                1、挂载镜像

首先我们要挂载光盘过着镜像，以下的挂载路径可以根据自己实际的路径去修改

                2、进入救援模式

重启实体服务器，选择菜单栏，进入救援模式

                

               

                3、进入shell模式：

        接下来系统将试图查找根分区，出现如下图所示。默认在救援模式，硬盘的根分区将挂载到光盘Linux环境的/mnt/sysimage目录下。选项’continue’表示挂载权限为读写，‘Read_only’为只读，如果出现检测失败可以选择’skip to shell’跳过。 此时，因为要对系统进行修复，所以需要读写权限，一般选择默认选项’continue’，输入1，回车
                

        可以看到系统提示’your system has been mounted under /mnt/sysimage.‘此时挂载成功。我们还可以选择执行’chroot /mnt/sysimage’命令，可以将根目录挂载到我们硬盘系统的根目录中去。此时我们不执行这条命令，按enter直接进入shell。

                4、进入shell之后我们执行这几条命令

mount --bind /proc /mnt/sysimage/proc
mount --bind /sys /mnt/sysimage/sys
mount --bind /dev /mnt/sysimage/dev

                5、然后通过cp将文件恢复，前边加反斜杠的原因是在cp指令前面加反斜杠可以不弹出是否覆盖的询问而直接覆盖。

\cp -rp /bin/ /mnt/sysimage/bin

                 6、授权

chmod 655 -R /bin/

               7、重启服务器，这个目录即可恢复了。

总结：

        在这里小编要提醒一下大家，使用rm ，mv这样的高危命令一定要慎重考虑，自己创建文件或者目录的时候尽量避开与系统目录或者业务目录重名，如果我自己不会去创建一个叫bin的普通目录，这个问题也就可以避免了，会有很大的容错空间。

        出现了这种大问题，哪怕自己能解决也不要先自作主张，因为毕竟是公司的新人，有问题一定要及时上报，相信老运维的技术，而且有时候还能避免背锅。（误操作除外*--*）

        总之，我的运维生涯虽然差点结束，不过这样开来算是完整了，以后可能还会面临更多紧张刺激的挑战。