那些真实的翻车现场#

最有名的受害者，大概是 1998 年的皮克斯。当时《玩具总动员 2》还在制作中，一名工程师在清理文件时，误触了删除命令。动画文件以肉眼可见的速度一个接一个消失，包括主角伍迪的建模——那可是全片的核心。就在团队几乎崩溃时，技术总监 Galyn Susman 想起自己在家办公的电脑上有一份备份，才挽救了这部电影。据说那份备份来自她「为了方便在家哄娃时顺便工作」而同步的副本。

比动画更惨的是 2017 年的 GitLab。一位运维工程师在修复数据库主从同步问题时，误把删除命令打在了主库上，而不是出问题的从库。结果 300GB 的生产数据被删掉了约 6 小时的数据，最终只靠一份「恰好一周前」的备份勉强救回——那次事故后来成了 DevOps 圈子里「备份永远不嫌多」的经典教材。

还有一个著名的「自杀式」事故来自游戏平台 Steam。2015 年，一段安装脚本里的清理命令写成了：

1
rm -rf "$STEAMROOT/"*

看起来没问题，对吧？问题在于：如果 $STEAMROOT 这个变量恰好是空的，这条命令就会展开成：

1
rm -rf /*

翻译成人话就是「删掉根目录下的所有东西」。好在这个 Bug 只在极少数 Linux 发行版上被触发，且当时脚本需要 root 权限，才没有酿成大祸——但它足以让所有写脚本的人后背发凉。

为什么「小失误」总是代价惨重#

这些事故有一个共同点：命令本身没写错，错的是执行它的环境——多敲了一个空格、变量为空、打错了主机名。而 rm -rf 之所以可怕，是因为它删得又快又彻底，几乎不给反悔的机会。

所以老手们的「保命习惯」往往很朴素：

1
# 删除前先 pwd 确认自己在哪
2
pwd
3

4
# 关键路径删除前，先 ls 看一眼要删的是不是这个
5
ls -l /data/production
6

7
# 用「演习」代替直接执行：先 echo 出来，确认无误再去掉 echo
8
echo rm -rf /data/production/old

最稳的一招，是把 rm 换成「移到回收站」，或者干脆用版本控制 + 定期备份兜底。毕竟连皮克斯和 GitLab 都栽过跟头，谁也不敢说自己永远手稳。

结语#

rm -rf 本身没有错，它只是一件被设计得极其高效的工具。真正该敬畏的，是「自动化 + 高权限」叠加起来时的破坏力。下次你准备敲下回车之前，不妨多看一眼光标前那个目录——这一眼，可能值 300GB。

参考来源

• GitLab.com 数据库事故事后复盘（2017-02-01） — 官方 Postmortem，记录了误删主库的完整过程
• Toy Story 2 被误删又被救回的故事 — 皮克斯动画文件险些丢失的著名往事
• Steam 的 rm -rf / 漏洞公告（2015） — 变量为空导致删除根目录的 Bug 讨论