将rm改造成mv让删除也有后悔药

历史告诉我们rm慎用啊，百度一搜各种事件多如牛毛，但在我们身上如何避免？很显然这一操作要像修改机器名一样来对待，没错，那就是初始化时就把rm改掉。

分享一个案例，光看文字就能想像出作者当时的表情：

作者：匿名用户
链接：https://www.zhihu.com/question/29438735/answer/101838852
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

某通信公司，HK某运营商项目，某中间件产品，实时系统，三期割接上线。

因为一期二期已经上线，现网系统已经承载C网200w用户。

连续两晚通宵，终于成功割接，系统运行正常。

一觉醒来，下午四点，业务高峰，登录系统检查状态，运行正常，但发现系统后台目录下有11个昨晚操作留下临时文件，一共都不到1M的样子。完美主义者+强迫症患者。没经客户允许，打算直接删除。好了，事情来了。

业务操作员，应用后台home目录下，rm -rf ./*XXXX* 不知道怎么敲成了rm -rf ./* XXXX* 。多了个空格。

rm 3秒没完成，第一反应，麻蛋，不对劲，貌似这次删除时间有点长。

随即系统立即报出rm: cannot remove directory `./mdsfiles’: Device or resource busy，

X，TMD，这可是生产环境啊，完了，出事了，赶紧一顿 Ctrl+C，12个^C，rm操作取消。ls查看文件，不用细看就知道明显少了好多文件。

下图就是SecureCRT记录的当时的操作日志。(16:15:08的操作是Tab，不是回车，16:15:11的操作才是真正的rm操作)

自动草稿

其实之前身边已经有人因为rm文件出过事故，自己也曾多次脑补过这个场景，也因为好奇使用root用户在测试镜像下搞过rm -rf /。

但第一时间还是懵了。也许是HK的空调太低，并没有惊出一身汗，只是手有点抖。

赶紧登录Web前台监控系统状态，发现监控进程自己都已经挂掉了，业务进程状态无法查询。不行，要Hold不住。

通知身边同事，和PM汇报上升问题，看看能不能让客户上游请求系统先暂时自己缓存请求，给我们半小时时间恢复之后再下发。后来据说当时PM正在和客户开会，和客户说了我们系统出了问题，客户脸都白了，本想联系他主管，但又觉得不够，直接打了电话给主管的主管，说赶紧下发紧急告警，启动应急预案。

同时我这边Web前台查询请求状态，发现还在处理业务请求。数据库查询请求数量，发现并无明显积压。感觉主进程应该暂时还在，我们应该还可以自己Hold一会。赶紧让同事和PM说让客户先不要操作，我们自己再压一会儿。PM和正在给领导打电话的客户谎称是我们自己看错了。客户又在电话里大喊告警解除。有种电影里发射核弹的感觉，很遗憾当时没在场。如果启动应急预案，估计可以去客户官网看公告了。

凭直觉直接脚本拉起监控进程，命令敲完一半，Tab联想不出来，才发现启动脚本都已经删没了，Fxxx。因为生产环境为双机，本来可以切换到备机，但双机管理软件因为这次上线已经冻结，现在恢复管理未必成功，如果中间出现问题无法完全启动将会更加麻烦，而且切换过程中必定存在业务中断，现在是业务高峰，所以不到万不得已，绝对不能切！

全量下载备机环境，并和主机比对，批量上传缺失文件，更新权限777。脚本拉起监控进程，启动正常。重新登录web前台，已经可以查看系统状态，发现两个主进程的确还在。

初步Hold住，赶紧联系机关R&D，手机热点，远程共享桌面，逐一反馈修复之后后台目录下文件信息，确认主要文件都在，并评估部分缺失文件及本次操作影响。

目前系统状态基本正常，CPU占用率较高，原因还需定位，预计后续可能会出现报错，但应该不至于影响业务。再次和PM汇报情况，但PM已经气得不接我电话了…

误删文件之后，系统依旧坚挺，这应该是这次不幸中的万幸，一直被我们抱怨不靠谱的新系统，这次终于靠谱了一把，也救了我一命。也幸好内部消化，否则饭碗肯定不保了。

现在监控系统状态中，感觉应该趁加班写个脚本，以后更安全的调用rm。

2016.07.20 更新：
因为当时是业务高峰，且并没有有效定位思路，所以虽然CPU已经飙到300+%，但依旧决定进一步监控看下。当天夜里CPU使用率居高不下，但一切正常。第二天凌晨两点，爬起来监控，发现Web前台监控进程又挂了。深深呼了一口气，冷静。VPN远程登录服务器，看了下日志，有磁盘空间不足的报错。df一下，果然磁盘空间不足。du一下发现，是系统日志目录过大，后台一晚上打了几百G的日志。
拉一个下来，同时删除其余日志文件。再次手动拉起监控进程，系统监控页面恢复，日志仍在迅速增长。

看了下拉下来的日志，发现全是x个文件请求监控线程的报错，请求路径不存在。登上服务器看了下，发现文件请求目录的确不存在。下午恢复的时候，只恢复了主路径，并未恢复子路径(子路径为系统启动时自动创建，备机环境并无子路径)。mkdir手动创建目录。ll日志不再迅速增长，tail一下可以看到正常请求日志。感觉CPU使用率居高不下的原因肯定也是因为这个，登录Web前台，发现果然已经降到80%左右。

夜深人静，一个人偷偷摸摸擦屁股的感觉真不好。

睡觉。

自动草稿

第二天早上起来，VPN监控，系统状态正常，请求处理正常。七点，背着笔记本去见异地的女友。中午登录系统检查状态的时候发现，进程一切正常，CPU使用率在30%左右，的确不高，但是这低得也有点夸张啊。紧接着查询了下请求状态。妹的，从早上八点50之后就再也没有新请求过来。这他妹的少说也丢了几十万条的请求了。完了，饭碗又不保了。
正打算联系客户，客户的WhatsApp就过来了。很奇怪的是，客户语焉不详，感觉似乎是早上很快就发现了，只是一直不确定是不是他们自己请求系统(客户自己开发，和我们同时上线)的问题，所以直到下午才找到我们，这帮孙子…现在要拉上我们一起联合定位，定位个鬼，赶紧力荐客户重启。反正现在环境文件已经完全恢复，只要重启，昨天下午删除操作的一切可能的隐患都可以规避掉。

结果是重启之后果然就好了。后续定位这次的工单丢失4个小时是因为客户自己请求系统的Bug导致的，和那次误删没关系。但是两件事碰巧先后发生，真的是不得不让人紧张。
突然想到了我“岳父”的一段话：有时候，“虚惊一场”这四个字是人世间最美好的成语，比起什么兴高采烈，五彩缤纷，一帆风顺都要美好百倍。你可懂什么叫失去。这些时间来，更觉如此。愿悲伤恐惧能够过去，事外之人更懂珍惜。

终：后来在不久之后的一次和客户申请的正式升级操作过程中已将系统全部重新部署，现在已经稳定运行。我也于2016年7月结束14个月的HK项目交付工作，外人看来的“功成身退”，只有我自己知道这段日子有多难熬。

2017.02.03更新

不知道是不是因为这两天的gitlab rm -rf事故让大家对这个问题产生了兴趣，但两天500+的点赞量着实让我有点受宠若惊。
其实这次经历很大一部分原因在于我自己的手残，而且处理的方式也并无什么值得借鉴之处，所以这么高的点赞量让我更加惭愧。

于心有愧，所以我觉得应该和大家分享自己的一些思考…

1.工作的时候尽量保持清醒，进行高危操作的时候一定要保持清醒

2.建议每次执行rm操作前，核对一遍之后再敲回车(虽然这个动作可能已经成为很多程序员神经回路的一部分)。如有必要，可对rm命令设置alias，设置别名为mv到指定目录，crontab定时清理

3.做好用户权限控制，root不公开，使用低权限业务用户进行日常操作。需要高权限使用密码sudo (当时使用的业务用户，操作的是应用后台根目录，误删文件的数量，用途和影响至少都大致了解，风险可控)

4.操作窗口之外，不要乱动生产，我现在觉得最好登都不要登

怎么样，这个命令不好玩吧，那么接下来我们来改造一下，让rm也有一个回收站。

1. 在/home目录下新建两个目录，命名为：.trash，tools
2. 在/home/tools/目录下，新建一个shell文件，命名为： remove.sh
PARA_CNT=$#
TRASH_DIR="/home/.trash"
 
for i in $*; do
    STAMP=`date +%s`
    fileName=`basename $i`
    mv $i $TRASH_DIR/$fileName.$STAMP
done
 
3. 修改~/.bashrc， 增加一行
alias rm="sh /home/tools/remove.sh"
用我们自建的remove.sh替代rm命令
  
4. 设置crontab，定期清空垃圾箱，如：
0 0 * * * rm -rf /home/.trash/*
每天0点清空垃圾箱
  
5. source ~/.bashrc 使替换立即生效
经过上面的步骤后，执行rm删除的文件，会被放入垃圾箱。如果误删除，可以从中恢复。
 
3. 修改~/.bashrc， 增加一行
alias rm="sh /home/tools/remove.sh"
用我们自建的remove.sh替代rm命令
  
4. 设置crontab，定期清空垃圾箱，如：
0 0 * * * rm -rf /home/.trash/*
每天0点清空垃圾箱
  
5. source ~/.bashrc 使替换立即生效
经过上面的步骤后，执行rm删除的文件，会被放入垃圾箱。如果误删除，可以从中恢复。

测试如下：

自动草稿

在当前目录下创建了一个del_test目录，然后执行rm del_test后结果如下:

自动草稿

可见被删除的del_test在/home/.trash目录里，这样误删除的文件就能在这里找到。没试过比较大的文件，小文件测试都没问题。

写在后面：防止服务器上文件误操作的办法感觉没有，只能把风险降到最低，比如可以利用sudo限制账号的使用命令权限，把rm命令改造成mv命令，培训相关需要使用服务器人员linux命令操作，root权限最小化，服务器密码只掌握在公司重要的人手上，其他一律不给密码等。