无法在这个位置找到: head2.htm
当前位置: 建站首页 > 新闻 > 产业新闻 >

胆战心惊!1次服务器误删数据信息的修复全过程

时间:2021-04-07 06:47来源:未知 作者:jianzhan 点击:
短视頻,自新闻媒体,达人种草1站服务亲身经历了两天不懈勤奋,终究修复了1次误实际操作删掉的生产制造服务器数据信息。对本次安全事故全过程调解决方法纪录在此,警省自身,也

胆战心惊!1次服务器误删数据信息的修复全过程


短视頻,自新闻媒体,达人种草1站服务

亲身经历了两天不懈勤奋,终究修复了1次误实际操作删掉的生产制造服务器数据信息。对本次安全事故全过程调解决方法纪录在此,警省自身,也提醒他人莫犯此错。也期待遇到难题的盆友能寻找1丝设计灵感处理难题。

安全事故情况

分配1个妹子在1台生产制造服务器上安裝Oracle,妹子边科学研究边安裝,觉得装的不对,提前准备卸载再次安裝。从在网上寻找卸载方式,在其中要实行1行指令删掉Oracle的安裝文件目录,指令以下:

rm -rf $ORACLE_BASE/*

假如ORACLE_BASE这个自变量沒有取值,那指令就变为了

rm -rf /*

==||,妹子应用的但是root账户啊。就这样,把全部盘的文档所有删掉了,包含运用Tomcat、MySQL数据信息库 and so on。。。。

(mysql数据信息库并不是在运作吗?linux能删掉正在实行的文档?总之是完全删掉了,最终还剩1个tomcat的log文档,估算是文档过大,1时沒有删掉取得成功)

看着妹子自责的眼神,又是由于这事是我分配她做的,也沒有跟她讲明强大关联,沒有任何学习培训,义务只能1本人背了,更何况如何能让漂亮美女背负这个义务呢?

打电話到主机房,将盘挂到另外一台服务器上,ssh上去查询文档所有被清,这台服务器运作的但是1个顾客的生产制造系统软件啊,早已运作一大半年了,得尽快修复啊。因而找来离线备份数据的数据信息库,发现备份数据文档仅有1kb,里边仅有几行熟习的mysqldump注解(难道说是crontab实行的备份数据脚本制作有难题),最接尽的备份数据也是2013年12月份的了,简直屋漏偏逢连夜雨啊。

想起来1位领导说过的实例:当1个生产制造系统软件挂掉之后,发现全部备份数据都有难题,刻录的光盘也是有划痕,磁带机也坏了(1个业界老前辈,估算之前还用光盘做备份数据了),想不到今日真的应验到我的身到了,如何办??

单位领导了解状况后,早已做了最坏的B方案:领导亲身带队和商品AA星期日赶到顾客所属的地市,礼拜1去领导层沟通交流;BB和CC去顾客管理方法员那边想方法说动顾客。。。

救命稻草--ext3grep

赶紧到在网上去查材料开展误删数据信息修复,还真寻找1款ext3grep可以修复根据rm -rf删掉的文档,大家硬盘也是ext3文件格式,且在网上有很多的取得成功实例。因而燃起了1丝期待,赶紧对盘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

内心禁不住1凉,难道说是删掉硬盘上被写过文档了?修复机率不大了啊,能修复几个算几个吧,说不确定关键数据信息文档恰好在能修复的MYD文档中。因而先将全部文档名重定项到1个文档文档中

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

过虑出来全部mysql数据信息库的文档名存成,mysqltbname.txt

撰写脚本制作修复文档:


  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,myi3个文档,如何说也是有300好几个上下啊!!将找到来的文档附到现了解据库上,更要文档管理权限为777后,重新启动mysql,也算是找到1一部分数据信息了,但顾客关键的考勤签到数据信息、手机上端上报数据信息(听说顾客按这些数据信息做职工业绩考核的)还没找到来啊。

咋 办?正中间又试了另外一款专用工具extundelete,跟ext3grep英语的语法基础1致,基本原理应当也1样了,可是听说能按文件目录修复,好吧试1试。

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

果真略见一斑,修复不出来!!!!!!!!那些文档已被破坏了。跟领导报告,实行B方案吧。。。无可奈何之下下班回家了(周末了,回去歇息1下,想一想方法吧)

灵机1动:binlog

第2天凌晨1早就醒了(内心有事啊),背上电脑上,去企业(这个周末算是报销了,不挨批,通报,罚款,开除就非常好了,还过甚么周末啊)。

依然运作ext3grep,extundelete,也就那几招啊,把系统软件架到检测服务器上,看看数据信息能不可以想方法补1补吧。在检测服务器勤奋行mysqldump,修复文档,遮盖修复回家的文档,给文档加管理权限,重新启动mysql。

wait,wait,并不是有binlog吗?大家服务都规定打开binlog,说不确定能根据binlog里修复数据信息呢?

因而从dump出来的文档名里寻找binlog的文档,1共3个,mysql-binlog0001,mysql-bin.000009,mysql-bin.000010,修复1下0001

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

竟然不成功了。。。。。。

再看另两个文档,mysql-bin.000010大约几百MB,应当可靠1点,实行复原指令,竟然取得成功了!!!!!!!!!!!!!

赶紧scp到检测服务器。实行binlog复原。

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

键入登陆密码,卡住了(好状况),历经悠长的等候,终究完毕了。开启运用,哦,谢谢tv,mtv,数据信息回家了!!!!!!!!!!!!!!!

续篇

历经此次安全事故,尽管数据信息很好运能找到来了,可是全过程确是惊动心迫。也为自身的不正确所带来的不良影响,给朋友和领导带来的连带义务然后怕。也期待切记此次安全事故,之后已不犯一样的不正确。安全事故反思以下:

1.本次分配MM开展服务器维修时沒有提早对她开展表明强大状况,自身也未高度重视,管理方法错乱,步骤错乱。1个线上的生产制造系统软件,任何1个修改1定要先谋然后动。

2.全自动备份数据出現难题,沒有任何人查验。离线备份数据人员每次从服务器左右载1k的文档却从未高度重视。必须确立大伙儿在工作中职位上的义务。

3.安全事故产生后,沒有立即发现,导致一部分数据信息写入硬盘,导致不能修复难题。必须撰写运用监管程序流程,服务1旦有出现异常,短消息告警有关义务人。

依据评价提示,再加1条:

4.不可以应用root客户来实际操作。应当在服务器上设立不一样管理权限级別的客户。

根据本次安全事故,几位跟这个新项目和安全事故沒有任何关联的朋友,积极前来帮忙,查材料,帮检测,有1位朋友还帮忙到夜里1点多钟开展数据信息修复检测。另外商品主管在想起朝向顾客的极大工作压力的状况下,沒有忙乱而指责开发设计人员和实际实际操作人,而让大伙儿能静下心来想处理计划方案。单位领导也积极主动积极的帮忙想方法,陪大家加班检测,即时追踪事儿过程。

根据大伙儿的相互勤奋,终究事儿相对性完满完毕,接下来,周1上午开展团体反思,总结工作经验经验教训,这类安全事故1定尽可能大勤奋开展防止。

传输门

本文所用到的专用工具连接:

1.ext3grep:

编译程序安裝依靠包较为多,能够到在网上检索怎样安裝。可是的是作者得出的howto被墙了,我翻墙将how to 的pdf文本文档免费下载下来了,读完后你可能对linux的文档系统软件有进1步的了解。免费下载howto()。

这个专用工具有1个bug,错误后不容易向下实行ext3grep: init_directories:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.,从而导致修复不成功,作者放出了1个补钉,免费下载详细地址:补钉免费下载()。不搞清楚为何作者新版沒有把这个补钉加进去。

2.extundelete:

作用跟ext3grep类似,基本原理应当也类似。只是号称能够复原文件目录,我这里沒有实验取得成功。


(责任编辑:admin)
织梦二维码生成器
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
无法在这个位置找到: ajaxfeedback.htm
栏目列表
推荐内容


扫描二维码分享到微信

在线咨询
联系电话

400-888-8866