江苏龙网

  1. 主页 > 生活百科 > >

妹子在生产服务器执行了 rm -rf /*，还好有我帮她恢复了( 二 )

rm -rf /*


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点多钟进行数据恢复测试 。同时产品经理在想到面向客户的巨大压力的情况下 ， 没有慌乱而责怪开发人员和具体操作人 ， 而让大家能静下心来想解决方案 。部门领导也积极主动的帮忙想办法 ， 陪我们加班测试 ， 实时跟踪事情进程 。
通过大家的共同努力 ， 终于事情相对圆满结束 ， 接下来 ， 周一上午进行集体反思 ， 总结经验教训 ， 这类事故一定尽量大努力进行避免 。

【妹子在生产服务器执行了 rm -rf /*，还好有我帮她恢复了】


推荐阅读


上一篇：欧盟新规,我国茶叶出口遭遇新门槛

下一篇：谢荣,真想做个桐木的茶人