一
终于迎来了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，防止以后手残。
