共计 3062 个字符，预计需要花费 8 分钟才能阅读完成。
经验了两天不懈努力，终于复原了一次误操作删除的生产服务器数据。
对本次事变过程和解决办法记录在此，警醒本人，也提醒他人莫犯此错。
也心愿遇到问题的敌人能找到一丝灵感解决问题。
01
事变背景
安顿一个妹子在一台生产服务器上安装 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 去客户管理员那边想方法压服客户……
02
救命稻草：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"
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 打算吧……无奈之下上班回家。（周末了，回去劳动一下，想想方法吧）
03
眉头一皱; 计上心来：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，数据回来了！
04
后记
也心愿谨记此次事变，当前不再犯同样的谬误。事变反思如下：
- 本次安顿 MM 进行服务器保护时没有提前对她进行阐明厉害状况，本人也未器重，管理混乱，流程凌乱。一个在线的生产零碎，任何一个改变肯定要先谋而后动。
- 主动备份呈现问题，没有任何人查看。脱机备份人员每次从服务器上下载 1K 的文件却从未器重。须要明确大家在工作岗位上的责任。
- 事变产生后，没有及时发现，造成局部数据写入磁盘，造成不可复原问题。须要编写利用监控程序，服务一旦有异样，短信告警相干责任人。
- 依据评论揭示，再加一条：不能应用 Root 用户来操作。应该在服务器上开设不同权限级别的用户。
通过本次事变，分享下 本文所用到的工具链接：
- https://code.google.com/p/ext…
- http://extundelete.sourceforg…
性能跟 ext3grep 差不多，原理应该也差不多。编译装置依赖包比拟多，能够到网上搜寻如何装置。
最初，心愿各位同行的小伙伴们能谨记本文事件，开心敲代码，永远不出错～
PS：如果感觉我的分享不错，欢送大家顺手点赞、在看。
