记一次生产事故——用户误将根目录移动至子目录

背景：
SaaS层运维人员误操作，本要执行的命令为：

cd /home/bak
mv ./* /data/xxx-iot/mysql/xxx_xxx_xxx

误操作成：

mv /* /data/xxx-iot/mysql/xxx_xxx_xxx

 

造成的情况：

SaaS方无法再通过ssh进行连接至服务器（已连接的终端窗口还能正常连接，不会断开）

无法正常执行命令，执行ls，mv等相关基础命令会抛出异常，输出报错为：
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

该报错指 查找不到lib64目录（64位操作系统依赖库）中的ld-linux-x86-64.so.2文件

 

处理过程：

接到该消息的时候，笔者先是查找了该机器类型（物理机 or 虚拟机），确定了该机器为虚拟机（稍微方便了点，远程就能够处理，如果是物理机的话远程连接不上还得跑机房），接着登录资源池查看该机器是否有开启Site Recovery（备份机制）与快照时间点，结果很遗憾，两者都没有。
在没有开启定时备份功能与快照的情况下，只能先通过VMWare平台中的“启动台”进入到系统摸索解决办法了。

好在还能通过启动台进入到操作系统当中，此时我执行任何命令都会抛出异常（找不到依赖库文件）：

-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

报错信息大致为找不到依赖库文件，那么我们可以使用绝对路径来指定依赖库文件的位置，而依赖库文件通常是放在/usr/lib64/目录下，我们可以试着运行：
# /usr/lib64/ld-linux-x86-64.so.2 --library-path /usr/lib64/ /usr/bin/ls /data/　　　　#根目录被移动，导致环境变量丢失，所以我们必须指定命令的绝对路径
1.txt xxx.txt ...　　# 此时是能够输出正常信息的

接着我们尝试将误移动的根目录复制回原位：

# /usr/lib64/ld-linux-x86-64.so.2 --library-path /usr/bin/cp -rfp  /usr/ /data/xxx-iot/mysql/xxx_xxx_xxx/* /　　#此时命令能够正常执行，光标会持续闪烁...具体执行时间长短与数据量大小有所关系
...　　#而当命令执行完毕，我们再执行基础命令，会发现不需要加绝对路径也能正常使用命令
# ls /data/
1.txt xxx.txt ...

总结：

在缺少依赖文件的情况下，当我们执行任何命令都会抛出找不到依赖文件，而我们可以使用绝对路径指定好该依赖文件位置。
依赖库文件一般会存放在两个位置：
1. /usr/lib64/　　　　　　　　　　　　#原始的路径
2. /data/xxx-iot/mysql/xxx_xxx_xxx 　　#这个路径是你误操作将文件移动到的目录
在开始解决问题之前，应当先确定好依赖库文件位置，可以执行/usr+Tab键补全查看，定位依赖库文件的位置

Tips：
1. 造成生产事故的机器是位于公司VMware资源池下的，虽执行了移动根目录命令，但根目录下的lib64目录尚未被移动至子目录，故依赖文件还是存放在系统最原始的路径（/usr/lib64/）。
2. 而当笔者开始环境模拟的时候，在自己的电脑搭建虚拟机执行了移动根目录操作，此时一整个lib64目录是已经被移动至子目录下的（/data/xxx-iot/mysql/xxx_xxx_xxx/usr/lib64）