关于 rm -rf /有感

2019-12-21 00:50:40 +08:00
 CatCode

刚刚看到了这个帖子 就在刚刚,rm -rf 删软连接的时候后面多加了个 /,现在杯具了 ,又想起了我在 你们平时用 Linux 时喜欢用 root 用户吗 里回复的

我大 root 敢死队什么时候怕过?

结合最近发生的一件事情说一下:
某些发行版的 rm 是默认--preserve-root 的,所以rm -rf /并没有什么卵效果。当然我不确定指定了多个路径的情况。我用过的发行版不多,作死也不多,这一条如果有知道的更多的,欢迎指正。

然后,在讨论rm这个问题的时候,总有人会说alias rm to mv。我想说,其实这样并不能挡住误操作。 这里举一个就前不久在我这里发生的真实例子:
(背景:高校非计算机科学相关专业的科研机群) 在一台节点机上,给新人“练手”:用 root 编译安装一个软件。新人打算备份一下某些数据,但是误操作mv /* bak/(通配符前多打了一个斜杠)新人还真“新”,没搞懂乍回事儿,觉得怎么突然这么慢,也没按 Ctrl +C。等了好久才反应过来,叫来前辈看情况。
此时,各种 bin 已经都被移走了,所有命令都是各种command not found,然后新人居然一个 Ctrl+D 退掉了 SSH——当时那台机器最后一个 SSH 连接。
最后,迫于那台机器上没啥值得抢救的数据,直接重装了,省事儿。

可以看到,rm是有一些重要路径的保护措施的,而mv没有。而总所周知mv是不会丢失数据内容,而rm是可能导致数据丢失的(数据恢复不是 100%保证成功)。

起一个别名并不能解决问题。

然而,删掉了系统,真的有那么可怕吗?我觉得不是,重装系统太简单了。
真正可怕的是删掉、系统上产生的还有价值的数据、删掉部署在系统之上的技术栈、以及机器掉线带来的其他负面影响。
并没有系统命令可以帮你保护这些内容

那我们能做什么呢?老生常谈了:
在敲下回车之前,留个心,多看一眼,仔细一点。
勤备份:不仅仅是备份数据,还有软件架构的冗余、人员的冗余等等。

最后,感谢大家深夜听我逼逼这么多。

9631 次点击
所在节点    Linux
45 条回复
MadHouse
2019-12-21 01:01:04 +08:00
用 rm , 尽量不同 rm-rf
nvkou
2019-12-21 01:11:14 +08:00
所有路径都使用相对路径不好吗? 多 cd 多./不好吗?
iamwho
2019-12-21 01:54:25 +08:00

真正可怕的是删掉、系统上产生的还有价值的数据、删掉部署在系统之上的技术栈、以及机器掉线带来的其他负面影响。
并没有系统命令可以帮你保护这些内容。



alias rm to mv 就不是为了防止误操作,而是防止误操作造成数据丢失,所以你的说法不成立。
wtks1
2019-12-21 01:56:18 +08:00
给新手低权限账号就行了
KentY
2019-12-21 02:01:18 +08:00
关于"喜欢用 root 用户吗"那个帖, 我上来就回复了, 这个听别人怎么劝都没用, 吃一堑才能长一智.

我做过比 rm /这个更蠢的事, 因为写脚本拷贝,粘贴, 结果粘贴的历史记录没弄好, 把无关命令贴进脚本, 把整个硬盘擦了, ssd 很快... 但是机器还正常运行了大概几十秒..我还排错呢..:D 所以在很多方面有教训并不是坏事. 当然要是没备份就另说了.

@MadHouse
当你在做一个工作, 发现截然不同路径的 n 个文件 /目录需要处理(比如说 rm), 你怎么做, cd n 次吗?
实际操作中, 可能 3 次就是极限了
iamverylovely
2019-12-21 04:09:36 +08:00
mv /* bak/也有可能是少打了一个点。mv ./* bak/
carpRed
2019-12-21 06:37:26 +08:00
我也记得是被限制过得,无奈很多人喜欢玩这个梗,看不起我大开源社区
ihipop
2019-12-21 07:54:05 +08:00
pip install trash-cli
mostkia
2019-12-21 09:11:56 +08:00
我删除东西都是用 rm -i 的,就怕删错东西
lcdtyph
2019-12-21 10:09:11 +08:00
多用 tab 补全,可以避免很多路径输入错误的问题
deorth
2019-12-21 10:31:10 +08:00
可以像我司一样,每半个月开一次会,培训安全生产,输出心得。每月抽查安全生产守则和处罚条例。出线上重大事故的,扣 5000 开除。所有上级上管本季度绩效为 C,按级别扣钱。
HuLiY
2019-12-21 11:58:07 +08:00
忘记了从哪看到的一个程序员的原则:在每个文件夹下新建 recycle 文件夹,删除文件统一用 mv ./recycle,然后定期删除 recycle。虽说不能完全避免误删风险,但也相当于多了一道保护。

话说回来,误删这种事情,只能降低风险,没法完全避免。
hoyixi
2019-12-21 12:33:03 +08:00
如果是公司的环境,背后透射出的是管理烂,正规点的公司,员工账号能干些啥规定的死死的,根本没有权限,想删也删不了。 而且通常,环境一般也是专门或者隔离的,最坏情况也造成不了多大灾难。
zr8657
2019-12-21 12:42:09 +08:00
之前有一次上午操作一台生产机器,中午休息完下午再操作的时候发现生产环境的应用都被删了。当时汗都下来了,那感觉真是一言难尽,折腾到半夜也没弄好,随手看了下 rm rf 的命令执行时间发现是中午,然后就回家睡觉了。
yuzenan888
2019-12-21 13:01:03 +08:00
我记得我经历过最惨的一次是 rm -rf ./* 忘了加点,发现问题后 3 秒内按了 Ctrl + C,回过神来发现 /bin、/boot 已经被删掉了,但由于当时根目录下还有个 /data 目录,这个目录挂载到 samba 磁盘上,当时估计 samba 服务器上的硬盘还处于休眠状态没启动,IO 卡在这里了,回过头检查的时候发现 /data 目录毫发无损……真是庆幸!当时用的是 CentOS 系统,/bin 是软链接到 /usr/bin 的,所以 /usr/bin/ln -s /usr/bin /bin 恢复,然后再从新装系统上拷贝 /boot 过来就没事啦。

我觉得可以通过在根目录上建一个名字为 1 的目录,然后往里面塞入大量的零碎小文件(十万个)来减缓损失,当然只是预防手贱而已。
CatCode
2019-12-21 13:24:55 +08:00
@iamwho `mv`就安全了吗?`mv`和`cp`在文件名相同的情况下,默认的行为是覆盖喔。举个例子,
```bash
cp test.conf test.conf.bak #创建备份
vi test.conf #大量的编辑
##略:其他的很多操作
cp test.conf test.conf.bak #原本想 vi test.conf,使用上下箭头键切命令时多切了一个
```
这样,你的备份 test.conf.bak 就没了。

我在文中想引申出来的是:每个命令都是有一定的风险的,只是风险等级不同。
难道只有“误删数据”才叫“事故”吗?
mv、cp、>覆盖掉了已存在的文件
>>追加的内容和原有内容无法区分
UPDATE WHRER 的条件输错修改了不该修改的位置
apt install 把某个依赖升级到了并不兼容的高版本
...
甚至是 Windows 上,删除文件点了“是”,点开了回收站又点到了“清空”,再次确认还点了“是”这样的三重防护都挡不住的没睡醒。

我认为每个用户都应该在执行命令前,能明确这个命令会有哪些作用。
而对于现有的容错设计,我们必须明白其容错能力并非无限。
JamesR
2019-12-21 13:40:55 +08:00
每小时快照一次,怕个球。
no1xsyzy
2019-12-21 14:17:16 +08:00
是在 GNU coreutils 6.2 版本修改的这一默认行为(--preserve-root )
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=log;h=refs/tags/COREUTILS-6_2
BSD、Mac 和非 GNU 的 Linux 都不清楚,Minix 我盲猜是没默认 --preserve-root 的
msg7086
2019-12-21 15:59:39 +08:00
敲下回车之前多留心才是真的。
sudo 也好 mv 也好,管不住自己的回车键,一样总有一天会冲破安全措施的。
养成危险动作前再三确认,以及脑子不好使的时候不要瞎瘠薄操作的习惯。
CivAx
2019-12-21 16:11:12 +08:00
严格上来说 mv 的杀伤性可比 rm 大多了……

rm 看起来就凶神恶煞,对付 rm 的人都小心翼翼

mv 看起来人畜无害,给错参数就直接完蛋

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/630972

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX