前记: 此文是博客园一位博主亲身经历, 小编确实很佩服居然能恢复当年小编我也是在生产环境误删了一个文件夹, 导致整个生产环境瘫痪不能使用, 这个项目当时是整个公司的命, 公司此前刚刚凭此项目拿了 2000 万美元融资全公司乱成了一锅粥领导的脸我还是历历在目, 我整个人半天没有恢复过来最后还是各位兄弟姐妹的帮忙下, 集体奋斗了一整天把这个窟窿给补上了, 尤其是当时的开发 leader 帮我顶住了上面的压力, 一直铭记在心自此, 我对 rm -rf 这个命令深深的恐惧感
经历了两天不懈努力, 终于恢复了一次误操作删除的生产服务器数据对本次事故过程和解决办法记录在此, 警醒自己, 也提示别人莫犯此错也希望遇到问题的朋友能找到一丝灵感解决问题
事故背景
安排一个妹子在一台生产服务器上安装 Oracle, 妹子边研究边安装, 感觉装的不对, 准备卸载重新安装从网上找到卸载方法, 其中要执行一行命令删除 Oracle 的安装目录, 命令如下:
rm -rf $ORACLE_BASE/*
如果 ORACLE_BASE 这个变量没有赋值, 那命令就变成了
rm -rf /*
==||, 妹子使用的可是 root 账户啊就这样, 把整个盘的文件全部删除了, 包括应用 TomcatMySQL 数据库 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 LINEdo
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. 不能使用 root 用户来操作应该在服务器上开设不同权限级别的用户
通过本次事故, 几位跟这个项目和事故没有任何关系的同事, 主动前来帮忙, 查资料, 帮测试, 有一位同事还帮忙到晚上 1 点多钟进行数据恢复测试同时产品经理在想到面向客户的巨大压力的情况下, 没有慌乱而责怪开发人员和具体操作人, 而让大家能静下心来想解决方案部门领导也积极主动的帮忙想办法, 陪我们加班测试, 实时跟踪事情进程
通过大家的共同努力, 终于事情相对圆满结束, 接下来, 周一上午进行集体反思, 总结经验教训, 这类事故一定尽量大努力进行避免
/************************************** 传送门 ************************************************/
本文所用到的工具链接:
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., 从而造成恢复失败, 作者放出了一个补丁, 下载地址: 补丁下载不明白为什么作者新版没有把这个补丁加进去
2.extundelete:http://extundelete.sourceforge.net/
功能跟 ext3grep 差不多, 原理应该也差不多只是号称可以还原目录, 我这里没有试验成功
后记: 现在越来越多的大公司都是禁用 rm 的, 如果你要移除一个文件, 他们会选择 mv 至一个垃圾文件, 隔一段时间来集中处理避免误删导致众多囧相!
来源: http://www.sangeng.org/news/detail_116.html