在生产数据库服务器上执行 delete 语句的时候,很开心地少打了一个 where 条件,导致整个表被清空。
防火墙配置限制 ip 访问,复制粘贴的时候出错,导致数据库服务器断开了所有的链接。
和同事一起维护,他用 root 账户清理一些文件,以为在/tmp 目录下面,执行了 rm . -rf,看到屏幕飞快地刷,我忽然有一种很不好的感觉,赶紧喊 ctrl+c,然后过 1 秒等他明白过来狂按的时候,才发现服务器的 IO 性能太好有时候也是一种错误...
本人亲历...楼下继续...
早期在服务器上停 mysql,嫌 mysql 停的慢,直接 kill 掉,结果起不来了。 切换邮件发送服务,本地测试换成自己邮箱,忘记改回来,第二天自己邮箱爆满。 在 mac 上用 BSD 的 sed 写了个文本处理的,到服务器用 GNU 的 sed 上一跑,把一堆数据跑没了。
生产环境上好像还没啥太吓人的事情,不过学习 linux 的时候自己找了很多麻烦啊,/usr, /bin, 数据库关键文件,分区表,mbr ...... 数不过来的说
补充:说到分区表倒是想起来了,以前曾经把学校实验室的一台服务器的分区表搞坏,然后就学会了使用 diskman)
除了在华顺原帖下写的两个勿删数据的糗事外,还有一次, 在客户的服务器上打开了 eclipse,把项目(很古老的代码)重新编译了一遍…幸好 src 中不包含 view 代码,然后打车飞去公司…幸好中间没人重启…
刚开始工作时,项目使用 ssh 框架比较老,用的是配置文件的方式,工作三月,实在是受不了了,随即将所有 jar 包换着最新,用注解方式替换了配置文件,删掉了很多文件,上线之后,出现一点小问题,花了一天时间纠错,被老大训了一顿。不过最后还是保留了注解的使用方式。
线上 Rails Console 下跑一段代码。。删除了所有的 User 数据。。。 吓尿后,通过 mysql binlog 恢复了数据。。。 然后才知道 Rails Console 有沙箱模式 So
Learning from mistakes
一个 10086 的短信接收项目,网速卡 rm -fr 时文件名多打了个空格,把执行程序删了。关键是找不着源码。(源码不知道是不是上次离职的人没移交,操蛋。)
早年曾经给 prd 做发布包,把负载均衡判断 server 是否健康的文件没有排除,而 move in team 的发布流程是先把该文件拿掉,再做 move in , 则负载均衡就不会理该 server 了,move in 完毕再把该文件复原。
克悲剧的是:我的发布包里带上了这个文件...
幸运的是 move in team 的 自动化脚本包含一个 check,我的发布包被退回来了
rm -rf * 过,最后发现系统 shutdown 了,再用光盘启动一看,整个服务器卷没有了。教训两点,不要用,最好用 a b*. 第二,不要在很疲倦的时候在生产环境下操作。
两个数据库刚设置为远程相互同步,结果发现有一边的数据库少了一些东西,然后打算把这个不全的数据库删了,用 rake 重新 load 生成一个。结果是两边的数据库都被删了,当时就蒙了。。。。。还好,发现导数据的时候还有个备份
曾經 rm ﹣rf 刪除過 /opt 結果裏面的程序,代碼全沒了,好險有部份重要的在 local 上還有 曾經更新公司的服務器的 nginx,結果所有網站都成了 welcome for nginx! 曾經修改防火牆配置,結果速度打的去機房。。。。
rm -rf * 删除备份文件夹 发现好慢。等了有 10 秒,想不应该这么慢,停止了。 看看了。网站的用户头像没有移动过去。删了一小部分。
我也很 2,生产环境远程升级 archlinux,init 转 sytemd,第一台成功了,第 2 台把 sytemd 装上,结果 initscripts 没删除,重启机器后系统就没起来。。。。跑机房去手动升级,幸运的是一共有 10 台应用服务器,挂掉的只是一台
刚接触 Linux 时,符号链接上面吃过亏。
原本打算备份符号链接指向的目录,cp 时,习惯性的多加了 -a 参数。结果只是备份了符号链接而已。
下一步就是 rm -rf ... 你懂的...
这虽然不算事单纯意义上的 rm -rf 误操作,但是实际造成的损失是一样的。