一次心惊肉跳的服务器误删文件的恢复过程
来源:互联网 发布:免费小说阅读软件 编辑:程序博客网 时间:2024/05/19 14:17
rm -rf $ORACLE_BASE/*
如果ORACLE_BASE这个变量没有赋值,那命令就变成了
rm -rf /*
==||,使用的可是root账户啊。就这样,把整个盘的文件全部删除了,包括应用Tomcat、MySQL数据库 and so on。。。。
(mysql数据库不是在运行吗?linux能删除正在执行的文件?反正是彻底删除了,最后还剩一个tomcat的log文件,估计是文件过大,一时没有删除成功)
救命稻草--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 fidone < ./mysqltbname.txt
执行,大概运行了20分钟,恢复了40多个文件,但不够啊,我们将近100张表,每张表frm,myd,myi三个文件,怎么说也有300多个左右啊!!将找回来的文件附到现有数据库上,更要文件权限为777后,重启mysql,也算是找回一部分数据了,但客户重要的考勤签到数据、手机端上报数据(据说客户按这些数据做员工绩效的)还没找回来啊。
咋 办?中间又试了另一款工具extundelete,跟ext3grep语法基本一致,原理应该也一样了,但是据说能按目录恢复,好吧试一试。
extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh
果然不出所料,恢复不出来!!!!!!!!那些文件已被破坏了。
灵机一动: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.ext3grep:https://code.google.com/p/ext3grep/
编译安装依赖包比较多,可以到网上搜索如何安装。可惜的是作者给出的howto被墙了,我翻墙将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差不多,原理应该也差不多。只是号称可以还原目录,我这里没有试验成功
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次心惊肉跳的服务器误删文件的恢复过程
- 一次误删数据的恢复过程
- 记一次服务器宕机后数据库恢复的过程
- 一次sql server数据库的恢复过程
- 记录由于一次强制断电导致的服务器无法启动的恢复过程
- 记录如何把服务器误删数据的恢复过程
- 记一次惊险的文件恢复
- 一次Mac Pro操作系统(Mavericks)恢复的痛苦过程
- 一次oracle数据库断电受损后的恢复过程
- 一次oracle数据库断电受损后的恢复过程
- 记一次有惊无险的Linux数据恢复过程
- 记一次揪心的MySQL数据恢复过程
- 简单的记事本日志类
- Android ListView实现下拉刷新、加载更多
- Android 测试工具------ monkeyrunner工具
- Unity将来时:IL2CPP是什么?
- 强大的响应式jQuery消息通知框和信息提示框插件
- 一次心惊肉跳的服务器误删文件的恢复过程
- php B KB MB TB
- 期权交易自由之路
- 快捷键
- 15HD_OJ——不容易系列之(4)——考新郎(组合+错排公式)
- Android常用的工具类
- jdk中的logging
- 使用Tortoise SVN版本控制Eclipse工作区的Android项目
- 素数算法的优化之路