总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/zhouyu629/p/3734494.html 「zhouyu」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

经历了两天不懈努力，终于恢复了一次误操作删除的生产服务器数据。对本次事故过程和解决办法记录在此，警醒自己，也提示别人莫犯此错。也希望遇到问题的朋友能找到一丝灵感解决问题。

事故背景

安排一个妹子在一台生产服务器上安装Oracle,妹子边研究边安装,感觉装的不对,准备卸载重新安装。从网上找到卸载方法，其中要执行一行命令删除Oracle的安装目录，命令如下：

rm -rf $ORACLE_BASE/*

如果ORACLE_BASE这个变量没有赋值，那命令就变成了

rm -rf /*
等等，妹子使用的可是root账户啊。就这样，把整个盘的文件全部删除了。包括应用Tomcat、MySQL数据库 and so on。。。。

（mysql数据库不是在运行吗?linux能删除正在执行的文件?反正是彻底删除了，最后还剩一个tomcat的log文件，估计是文件过大，一时没有删除成功）

看着妹子自责的眼神，又是因为这事是我安排她做的，也没有跟她讲清厉害关系，没有任何培训，责任只能一个人背了，况且怎么能让美女背负这个责任呢?

打电话到机房，将盘挂到另一台服务器上，ssh上去查看文件全部被清，这台服务器运行的可是一个客户的生产系统啊，已经运行大半年了，得尽快恢复啊。

于是找来脱机备份的数据库，发现备份文件只有1kb，里面只有几行熟悉的mysqldump注释（难道是crontab执行的备份脚本有问题），最接尽的备份也是2013年12月份的了，真是屋漏偏逢连夜雨啊。

想起来一位领导说过的案例：当一个生产系统挂掉以后，发现所有备份都有问题，刻录的光盘也有划痕，磁带机也坏了（一个业界前辈，估计以前还用光盘做备份了），没想到今天真的应验到我的身上了，怎么办??

部门领导知道情况后，已经做了最坏的B计划:领导亲自带队和产品AA周日赶到客户所在的地市，星期一去领导层沟通；BB和CC去客户管理员那边想办法说服客户。。。

救命稻草--ext3grep

赶快到网上去查资料进行误删数据恢复，还真找到一款ext3grep能够恢复通过rm -rf删除的文件，我们磁盘也是ext3格式，且网上有不少的成功案例。

于是燃起了一丝希望，赶快对盘umount，防止重新写入补删文件扇区。

下载ext3grep，安装（编译安装过程艰辛暂且不表）。

先执行扫描文件名命令：

ext3grep /dev/vgdata/LogVol00 --dump-names

打印出了所有被删除文件及路径，心中狂喜，不用执行B计划了，文件都在呢。

这款软件不能按目录恢复文件，只能执行恢复全部命令：

ext3grep /dev/vgdata/LogVol00 --restore-all

结果当前盘空间不足，没办法只能恢复文件，尝试了几个文件，居然部分成功部分失败

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD

心里不禁一凉，难道是删除磁盘上被写过文件了?恢复机率不大了啊，能恢复几个算几个吧，说不定重要数据文件刚好在能恢复的MYD文件中。

于是先将所有文件名重定向到一个文件文件中

ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt

过滤出来所有mysql数据库的文件名存成,mysqltbname.txt

编写脚本恢复文件：

while read LINE
do
    echo "begin to restore file " $LINE
    ext3grep /dev/vgdata/LogVol00 --restore-file $LINE
    if [ $? != 0 ]
    then
        echo "restore failed, exit"
       # exit 1
    fi
done < ./mysqltbname.txt

执行，大概运行了20分钟，恢复了40多个文件，但不够啊，我们将近100张表，每张表frm,myd,myi三个文件，怎么说也有300多个左右啊！！

将找回来的文件附到现有数据库上，更要文件权限为777后，重启mysql，也算是找回一部分数据了，但客户重要的考勤签到数据、手机端上报数据（据说客户按这些数据做员工绩效的）还没找回来啊。

咋 办?中间又试了另一款工具extundelete，跟ext3grep语法基本一致，原理应该也一样了，但是据说能按目录恢复，好吧试一试。

extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh

果然不出所料，恢复不出来！！！！！！！！

那些文件已被破坏了。

跟领导汇报，执行B计划吧。。。

无奈之下下班回家（周末了，回去休息一下，想想办法吧）

灵机一动：binlog

第二天早晨一早就醒了（心里有事啊），背上电脑，去公司（这个周末算是报销了，不挨批，通报，罚款，开除就不错了，还过什么周末啊）。

依旧运行ext3grep，extundelete，也就那几招啊，把系统架到测试服务器上，看看数据能不能想办法补一补吧。

在测试服务器上进行mysqldump，恢复文件，覆盖恢复回来的文件，给文件加权限，重启mysql。

wait,wait，不是有binlog吗?我们服务都要求开启binlog，说不定能通过binlog里恢复数据呢?

于是从dump出来的文件名里找到binlog的文件，一共三个，mysql-binlog0001,mysql-bin.000009,mysql-bin.000010，恢复一下0001

ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001

居然失败了。。。。。。

再看另两个文件，mysql-bin.000010大概几百MB，应该靠谱一点，执行还原命令，居然成功了！！！！！！！！！！！！！

赶快scp到测试服务器。

执行binlog还原。

mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p

输入密码，卡住了（好现象），经过漫长的等待，终于结束了。

打开应用，哦，感谢cctv,mtv，数据回来了！！！！！！！！！！！！！！！

后记

经过此次事故，虽然数据很幸运能找回来了，但是过程却是惊心动迫。

也为自己的错误所带来的后果，给同事和领导带来的连带责任而后怕。

也希望谨记此次事故，以后不再犯同样的错误。

事故反思如下：

  1. 本次安排MM进行服务器维护时没有提前对她进行说明厉害情况，自己也未重视，管理混乱，流程混乱。一个在线的生产系统，任何一个改动一定要先谋而后动。

  2. 自动备份出现问题，没有任何人检查。脱机备份人员每次从服务器上下载1k的文件却从未重视。需要明确大家在工作岗位上的责任。

  3. 事故发生后，没有及时发现，造成部分数据写入磁盘，造成不可恢复问题。需要编写应用监控程序，服务一旦有异常，短信告警相关责任人。

  4. 根据评论提醒,再加一条:

  5. 不能使用root用户来操作。应该在服务器上开设不同权限级别的用户。

通过本次事故，几位跟这个项目和事故没有任何关系的同事，主动前来帮忙，查资料，帮测试，有一位同事还帮忙到晚上1点多钟进行数据恢复测试。

同时产品经理在想到面向客户的巨大压力的情况下，没有慌乱而责怪开发人员和具体操作人，而让大家能静下心来想解决方案。

部门领导也积极主动的帮忙想办法，陪我们加班测试，实时跟踪事情进程。

通过大家的共同努力，终于事情相对圆满结束，接下来，周一上午进行集体反思，总结经验教训，这类事故一定尽量大努力进行避免。

———— e n d ————

本文所用到的工具链接：

  1. ext3grep:https://code.google.com/p/ext3grep/

编译安装依赖包比较多，可以到网上搜索如何安装。可惜的是作者给出的howto被墙了，我FQ将how to 的pdf文档下载下来了，读完后你将会对linux的文件系统有进一步的认识。下载howto。

这个工具有一个bug，出错后不会向下执行ext3grep: init_directories.cc:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.，从而造成恢复失败，作者放出了一个补丁，下载地址：补丁下载。不明白为什么作者新版没有把这个补丁加进去。

  1. extundelete：http://extundelete.sourceforge.net/

功能跟ext3grep差不多，原理应该也差不多。只是号称可以还原目录，我这里没有试验成功。

文章目录
  1. 1. 事故背景
  2. 2. 救命稻草--ext3grep
  3. 3. 灵机一动：binlog
  4. 4. 后记