一
终于迎来了rm -rf /*
,这次发生在生产环境。
起因是做冗余文件清理时,将 rm -rf ./* 误输为 rm -rf /* , 等到一堆 Busy 出来时,才反应过来,出事了!
一如每年的夏天,太阳总是烈的。现在的心情也是如此。
二
这是一台运行CentOS 6.5 x64的生产环境机器的前端机器,主要用于反代内部服务。检查了服务,没有告警,对外的代理仍正常运行。
此时运行大部分常用命令都会提示
/lib64/ld-linux-x86-64.so.2 : bad ELF interpreter: No such file or directory
这些命令都依赖 ld-linux-x86-64.so.2 核心库。
好在cd还能用,通过 cd + tab可以粗略看到目录情况, 对比了同配置的另一台机器,发现 /bin /etc /lib64 /boot /dev 被全部移除了,其他文件不祥。
/bin 和 /lib64 :软连接到 /usr/bin 及 /usr/lib64 目录,进/usr 确认了文件都在。
/boot 存放启动文件,只要当前机器不重启问题不大,可以从另一台机器复制内容。
/dev 同 boot 可以复制另一台的内容来恢复。
第一步要让命令可用,首先想到将 LD_LIBRARY_PATH 设置到 /usr/lib64,实际无效果。
重新 ln 下 /lib64呢,显然 /usr/bin/ls -s /usr/bin /bin 是不行够,但没关系,因为 /usr/lib64/ld-linux-x86-64.so.2 指向的 ld-2.17.so依旧存在,ld-2.17.so非常神奇,它可以直接指定库路径。于是:
/usr/lib64/ld-2.17.so --library-path /usr/lib64 /usr/bin/ln -s /usr/lib64 /lib64
/lib64 链接成功,那么 /usr/bin 下所有命令都能用了。
/usr/bin/ln -s /usr/bin /bin
三
剩下的事情就简单了。
恢复 /boot /dev 直接从另一台机器复制过来即可。
/etc 稍微麻烦些,因为这台机器使用 的nginx 的配置文件位于 /etc/nginx,最后借助gdb 从内存中恢复了回来。
四
最后加上safe-rm,防止以后手残。