原文地址：
https://copyfuture.com/blogs-details/201909061555306597xvo4pefwz7sy68
删库不要跑，学学下面的操作，每天执行一次rm -rf /*不是梦
上午删完，下午恢复，一天就过去了，还不用加班
前些日子在菜鸟架构上看到一篇服务器误删文件的恢复过程文章，感觉挺有意思的，在这里进行分享一波。
事故背景
大佬:"这里有个在生产服务器上安装Oracle的任务，部门的哪个妹子接一下"
然后有个妹子接受了大佬的安装Oracle的任务，妹子未注意到shell的语法，当变量未被赋值的时候，会是个空值。注意了，圈起来要考的。
妹子执行命令如下：
rm -rf $ORACLE_BASE/*看到这条命令，你就知道有多危险了，更何况妹子用的是root账号??what？
“很幸运”，ORACLE_BASE不存在或者未赋值，上面命令变成大家熟悉的:
rm -rf /*root用户？执行后，可以跑路了...
（插个小技巧：使用${var:=初始值}，可以让未定义的变量或者空值进行赋初值）
当然，妹子没跑路，那个大佬也没跑路，稳稳的背下了恢复数据的大锅。
整个盘的文件都被删了，咋办~ ~
大佬的原文是：
mysql数据库不是在运行吗?linux能删除正在执行的文件?反正是彻底删除了，最后还剩一个tomcat的log文件，估计是文件过大，一时没有删除成功
看着妹子自责的眼神，又是因为这事是我安排她做的，也没有跟她讲清厉害关系，没有任何培训，责任只能一个人背了，况且怎么能让美女背负这个责任呢? 打电话到机房，将盘挂到另一台服务器上，ssh上去查看文件全部被清，这台服务器运行的可是一个客户的生产系统啊，已经运行大半年了，得尽快恢复啊。于是找来脱机备份的数据库，发现备份文件只有1kb，里面只有几行熟悉的mysqldump注释（难道是crontab执行的备份脚本有问题），最接近的备份也是2013年12月份的了，真是屋漏偏逢连夜雨啊。想起来一位领导说过的案例：当一个生产系统挂掉以后，发现所有备份都有问题，刻录的光盘也有划痕，磁带机也坏了（一个业界前辈，估计以前还用光盘做备份了），没想到今天真的应验到我的身上了，怎么办??
部门领导知道情况后，已经做了最坏的B计划:领导亲自带队和产品AA周日赶到客户所在的地市，星期一去领导层沟通；BB和CC去客户管理员那边想办法说服客户。。。
大佬接下来试了两种方法恢复数据：
ext3grep和extundelete，都是只能恢复一部分数据（原因：事故发生后，没有及时发现，造成部分数据写入磁盘，造成不可恢复问题。）
两个工具的下载地址（寄希望于工具？送四个字：听天由命）：
ext3grep：https://code.google.com/p/ext3grep/
extundelete：http://extundelete.sourceforge.net/
庆幸的是：
binlog文件还在。没看到大佬说的是恢复的binlog文件还是说该文件存在另外的盘，反正就是binlog文件找到了。
那不用说，数据是没问题了。普及下binlog文件的认识。
binlog 基本认识
MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
一般来说开启二进制日志大概会有1%的性能损耗，这点消耗完全是可以接受的，为了数据的安全。
从binlog日志恢复数据
恢复语法格式：
mysqlbinlog mysql-bin.0000xx | mysql -u用户名 -p密码 数据库名
常用选项：
--start-position=953 起始pos点
--stop-position=1437 结束pos点
--start-datetime="2013-11-29 13:18:54" 起始时间点
--stop-datetime="2013-11-29 13:21:53" 结束时间点
--database=zyyshop 指定只恢复zyyshop数据库(一台主机上往往有多个数据库，只限本地log日志)
不常用选项：
-u --user=name Connect to the remote server as username.连接到远程主机的用户名
-p --password[=name] Password to connect to remote server.连接到远程主机的密码
-h --host=name Get the binlog from server.从远程主机上获取binlog日志
--read-from-remote-server Read binary logs from a MySQL server.从某个MySQL服务器上读取binlog日志小结：实际是将读出的binlog日志内容，通过管道符传递给mysql命令。这些命令、文件尽量写成绝对路径；
总结一波
说实话，错误挺低级的。应该比我以前写的一篇，redis key*的那种错误更加低级。
先看看大佬的总结：
- 本次安排MM进行服务器维护时没有提前对她进行说明厉害情况，自己也未重视，管理混乱，流程混乱。一个在线的生产系统，任何一个改动一定要先谋而后动。
- 自动备份出现问题，没有任何人检查。脱机备份人员每次从服务器上下载1k的文件却从未重视。需要明确大家在工作岗位上的责任。
- 事故发生后，没有及时发现，造成部分数据写入磁盘，造成不可恢复问题。需要编写应用监控程序，服务一旦有异常，短信告警相关责任人。
- 不能使用root用户来操作。应该在服务器上开设不同权限级别的用户。
我也简单的总结一下：
猜想，这个妹子应该是运维的小姐姐，不是开发人员（运维吗？过分了呀，那我也要转运维）
- root用户，一定是不能随便用来用的，而且还是生成环境，按照需要来分配不同权限的账号使用
- shell语法熟知过少？还是疏忽了，我猜应该是没重视
- 不过直接用变量来rm -rf来调用，其实也是有问题的，需要把变量输出一下瞅瞅是啥值。建议是，如果是变量的路径需要rm -rf的，先把变量输出，再拷贝变量的值路径，进行删除
- 了解下binlog是必要的
- shell命令可以再熟悉熟悉
另外，出了这么大的事故，部门领导的做法不错
原文:
通过本次事故，几位跟这个项目和事故没有任何关系的同事，主动前来帮忙，查资料，帮测试，有一位同事还帮忙到晚上1点多钟进行数据恢复测试。同时产品经理在想到面向客户的巨大压力的情况下，没有慌乱而责怪开发人员和具体操作人，而让大家能静下心来想解决方案。部门领导也积极主动的帮忙想办法，陪我们加班测试，实时跟踪事情进程
真不知道我在线上环境来个rm -rf /*会背多大的锅，可能会n+1吧、
不过毕竟没有权限~ ~（跃跃欲试的表情此刻变成了弯眉）
建议在执行 rm -rf /* 类似的命令的时候，自己检查3遍，请小伙伴看看，有未知变量的，把变量输出一遍，就不会出现这种情况了。
吾非大神，与汝俱进
最后插播广告时间：公众号未关注的贝贝们可以来一波关注
感谢关注
