没有执行过rm -rf /*的开发不是好运维

起因
突然收到用户反馈说网站在手机端打开是白屏, 很奇怪的问题.

在电脑端试了下,确实也是白屏,HTML加载进来了,好像有个核心JS加载失败.

看到一个错误是: We‘re sorry but house doesn‘t work properly without JavaScript enabled. Please enable it to continue.

还有一个http请求的错误是: ERR_INCOMPLETE_CHUNKED_ENCODING

于是尝试了一下的解决方案:

无脑重启看看能不能解决问题?重启了一下对应Docker容器,无果

可能是现在版本引入的Bug?回滚代码重新build,无果.

nginx的问题? 重启nginx,无果.

查看nginx日志,没什么有用的东西,无果.

灵机一闪,不会是磁盘空间满了吧.

df -h 看了一眼,99.99%的磁盘使用率.

某个Docker容器的磁盘空间用掉了34G.

看一眼Docker容器,直觉告诉我应该是Elasticsearch服务...

不算太重要的服务,先停了清理空间再说.

删掉了容器删了data文件,重启nginx,一切都正常Work了.

问题解决!!!

不过Elasticsearch总要重新回复回来嘛,看了下腾讯云云硬盘盘价格,也不是很贵嘛.

单独给Elasticsearch 起个数据盘吧.

作死开始
首先根据腾讯云的指示,挂在了数据盘到服务器上面.

然后给数据盘分区,接着mount到对应的路径.

嗯,好像有个警告.

难道不是这个磁盘么?换另外一个看看.

执行另外一个mount.

全程命令如下:

进入对应目录清空一下云盘数据吧.(PS:脑子有病才做这个,刚刚初始化的云盘哪有东西.)

ls 看一下,咋这么多奇奇怪怪的文件,难道是原来Elasticsearch docker 容器留下来的.

先删了再说.

执行 rm -rf ./*

咦,怎么有文件busy无法删除.

额,咋ls都没有了.

哈?cat 也没有了.

噗,copy也炸了.

cd 还在.

哇卡,这可咋办了.

先复盘一下做了什么事情
初始化磁盘的时候没有格式化,但是mount失败

mount失败后没有检查原因,直接尝试把另一个磁盘mount进去

mount系统盘到指定文件夹后并没有检查内容,直接rm -rf ./*

rm -rf ./* 此时已经基本没救了

拯救尝试
还在跑的服务基本是活着的,所以暂时来说API和Web网站都是好的。

服务器上面跑的基本都是Docker容器, Docker镜像都在阿里云上面存着,基本不怕丢失的问题。

不过应用配置文件/服务器证书之类的东西都在上面,这个估计要折腾一下了。

cd 还能用,ls没了,cat也没了。

尝试cat xxx.conf也没用了,难道只能一点点翻配置文件么.

群里的朋友提了一句,看看你的云盘有没有备份之类的.

咦,好像两个星期前找腾讯云技术支持的时候做过一次系统镜像.

是不是可以直接拿回来直接用?

看了下具体的镜像版本和备注信息,看起来那时候上面的内容和现在的估计没太多变化.

直接重装之后更新一下各个服务的镜像到最新版本应该就好了.

放弃拯救,直接使用备份的系统镜像重装
Work...

系统备份镜像拯救世界!!!

后续操作 + 总结
数据盘和系统盘分开,不要让程序的数据导致系统不可用

在费用允许的情况下设置磁盘快照策略,我这边最极端的情况下也应该能回滚到一个星期前的版本

下次大影响操作前先手动备份系统镜像,救命稻草一般的存在

原文地址:http://blog.51cto.com/13842645/2321819

时间: 2024-10-21 14:41:47

没有执行过rm -rf /*的开发不是好运维的相关文章

centos rm -rf 恢复删除的文件

Linux有时候执行了 rm -rf 等操作误删了文件绝对是一件可怕的事情,好在有一些解决的办法可以临时救急.这时我们就要用到一款叫做extundelete的工具了. 目录[-] 依赖 安装 查找要恢复的驱动器名 运行恢复 恢复单个文件 恢复一个目录 恢复整个分区 Linux下执行 rm 并不会真正删除,而是将inode节点中的扇区删除,同时释放数据块.在数据块被系统重新分配前,这部分数据还是可以找回来的. 网上说在删除文件后要立即unmount这个分区,这样做其实是为了让外界不再写入,我们也可

find ~/ -name "*.aic" -exec rm -rf {} \;请问里面的各项是什么意思--?

这个命令是find的基本用法,可以分两部分,find ~/ -name "*.aic"和 -exec rm -rf {} \;  ~/:在根目录下查找  -name 查找文件名的方式  "*.aic"文件名中要求后缀是aic的所有文件 -exec 找到后执行命令 rm -rf {}命令就是删除文件 \;这是格式要求的,没有具体含义.

前端js正则的一个实例:过滤“rm -rf /”

最近开发cmdb,有个需求是要求脚本中不能含有"rm -rf /"命令,如果含有这个命令,前端弹出警告框提示. 这里需要用test方法来测试字符串,符合模式时返回true,否则返回false. 我先从控制台调试一下: 可以看到,匹配OK了. 前端代码如下: var re = /rm -rf \/$/;  //匹配"rm -rf /"命令 if (re.test('your commands')) {     alert('您输入的命令含有"rm -rf /

rm -rf误删文件的恢复(extundelete工具的使用)

实战:extundelete恢复数据的过程 在数据被误删除后,第一时间要做的是卸载被删除数据所在的磁盘或磁盘分区,如果是系统根分区的数据遭到误删除,就需要将系统进入单用户,并且将根分区以只读模式挂载.这样做的原因很简单,因为将文件删除后,仅仅是将文件的inode结点中的扇区指针清零,实际文件还存储在磁盘上,如果磁盘以读写模式挂载,这些已删除的文件的数据块就可能被操作系统重新分配出去,在这些数据块被新的数据覆盖后,这些数据就真的丢失了,恢复工具也回力无天.所以,以只读模式挂载磁盘可以尽量降低数据块

rm -rf / 好屌!

我真的做了这个实验,结果是,系统彻底坏了.. 不管怎样,总算体验了一把- $sudo rm -rf / --no-preserve-root 执行命令: 执行中: 执行结束,系统彻底用不了了: 谢谢虚拟机^_^ 其实,我搜了下,有不少人也做过这个实验,这个 BBGamerUK 还录了像: https://www.youtube.com/watch?v=SIIweirHwek 这里还有一个发了很久的,比较热烈的讨论: http://serverfault.com/questions/587102/

用ext3grep恢复rm -rf 误删除的文件

Linux作为企业级服务器,数据安全性至关重要,任何有价值的数据被误删除都是不能容忍的,甚至可能带来大的灾难!作为linux系统管理员,一定要有 数据保护意思,不但要做好数据备份工作,还应该有在将重要数据误删除后恢复的能力.在这里给大家介绍一个开源的数据恢复工具ext3grep,该工具可以 恢复rm –rf误删除的文件 一.ext3grep的原理:利用ext3grep恢复文件并不依赖于任何文件格式,首先ext3grep利用root的inode来获取文件系统中所有的文件信息,包括存在的或已删 除的

rm -rf /

今天看了篇文章,说rm -rf / 是不能直接执行的,我怀着忐忑的心情,测试了一下: [[email protected] ~]# rm -rf / rm: it is dangerous to operate recursively on `/' rm: use --no-preserve-root to override this failsafe [[email protected] ~]# unset $foo [[email protected] ~]# unset $bar [[em

谨慎使用 rm -rf /* 命令!

转载:http://www.kwx.gd/VpsPrimary/CentOS-rm-rf.html 经常逛VPS主机交流论坛的朋友可以看到,在用户发帖询问命令相关的问题时,个别想整恶作剧的用户会回答在SSH执行"rm -rf /*",若不了解这个命令,可能导致整个Linux系统文件全部被删除. 这个删除命令只有 "root" 权限的帐号才可以执行,其它未取得"root"权限的帐户只能删除属于自己用户或用户组内的文件. Linux的目录是使用 /

Linux 防止rm -rf 误删Shell脚本

#!/bin/bash #:set ff=unix #:set nobomb #-*- coding:utf-8 -*- ###################################################################### ## Filename:     Trash.py ## ## Copyright (C) 2014.6 ## Author:        [email protected]@qq.com ## ## Description:   S