慌的一逼！一次惊心动魄的服务器误删文件的恢复过程

慌的一逼！一次惊心动魄的服务器误删文件的恢复过程

图片来自网络

文本

经过两天的不懈努力，终于恢复了误删除的生产服务器数据。 这里记录一下这次事故的过程和解决办法，以警示自己，也提醒别人不要犯这样的错误。 也希望遇到问题的朋友能够找到一点解决问题的灵感。

事故背景

安排一个女孩将其安装在生产服务器上。 女孩在研究时安装了它。 她感觉安装错了，准备卸载重装。 从网上找到卸载方法，其中需要执行一行命令来删除安装目录，命令如下：

rm -rf $ORACLE_BASE/*

如果该变量没有被赋值，则命令变为

rm -rf /*

等等，女孩正在使用 root 帐户。

这样整个磁盘上的所有文件都被删除了，包括应用程序、MySQL数据库等。 。 。 。

mysql数据库没有运行吗？ linux可以删除正在执行的文件吗？ 反正都被彻底删除了，最后还剩下一个日志文件。 估计是文件太大，一时没有删除成功。

看女孩自责的眼神，都是我安排她这么做的，没有跟她解释清楚这件事。 未经任何培训，责任只能由一个人承担。 再说了，怎么能让美丽的女人承担这个责任呢？ ？ 打电话到机房，将磁盘挂载到另一台服务器上，ssh查看是否所有文件都被清除了。 该服务器正在运行客户的生产系统。 已经运行半年多了，需要尽快恢复。 于是找到了离线备份的数据库，发现备份文件只有1kb，里面只有几行熟悉的注释（难道是执行的备份脚本有问题），和最接近的备份也是在2013年12月，巧合的是整晚都下雨。 我想起一个领导说的一个案例：当一个生产系统挂了，发现所有的备份都有问题，刻录的光盘也被划伤，磁带机也坏了（一位业内资深人士，我猜他是以前都是用CD备份的。），没想到今天真的会发生在我身上，我该怎么办？？

部门领导了解情况后，已经做好了最坏的B计划：周日领导亲自带领团队和产品AA到客户所在城市，周一与领导沟通； BB和CC去找客户管理员寻求解决方案说服客户。 。 。

救命稻草/

赶紧在网上搜索资料来恢复误删除的数据吧。 我真的找到了一个可以恢复通过rm -rf删除的文件的文件。 我们的盘也是ext3格式的，网上也有很多成功的案例。 于是一线希望被点燃了，我赶紧对齐磁盘，防止补写和删除的文件扇区被重写。 下载并安装（更不用说艰难的编译和安装过程了）。 首先执行扫描文件名命令：

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文件中。所以首先将所有文件名重定向到一个文件file

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

过滤掉mysql数据库的所有文件名，保存为.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"
       # exit 1
    fi
done < ./mysqltbname.txt

执行，大约花了20分钟，恢复了40多个文件，但是还不够，我们有近100个表，每个表有frm、myd、myi三个文件，怎么说就有300多个文件！ ！ 将恢复的文件附加到已有的数据库中，并将文件权限设置为777后，重启mysql，算是恢复了部分数据，但是客户重要的考勤签到数据和移动端上报的数据（据说客户按这些数据（那些从事员工绩效工作的人）还没有找到。 我应该怎么办？ 中间我尝试了另一个工具，语法基本一样，原理应该也是一样的，不过据说可以按目录恢复，所以试试吧。

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

果然是无法挽回了！ ！ ！ ！ ！ ！ ！ ！ 这些文件已损坏。 向领导汇报并实施B计划。 。 无奈下班回家（周末了，回去休息吧，想想办法）

头脑风暴/

第二天一早起了床（脑子里有事），装上电脑，去了公司（这个周末算报销，不审批，举报，罚款，解雇，真是一个周末）。 还在运行，就几个技巧，把系统放到测试服务器上，看看能不能通过什么方式补充数据。 在测试服务器上做，恢复文件，覆盖恢复的文件，给文件添加权限，重启mysql。 等等，等等，不是有吗？ 我们的服务需要开启，也许我们可以通过它来恢复数据？ 所以从dump的文件名中找到了三个文件，mysql-,mysql-bin.,mysql-bin., 0001

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

它失败了。 。 。 。 。 。 查看另外两个文件，mysql-bin. 大概几百MB，应该比较靠谱，执行恢复命令，成功了！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ 快速 scp 到测试服务器。 执行恢复。 /usr/mysql-bin。 | mysql -uroot -p 输入密码，卡住了（好兆头），经过漫长的等待，终于结束了。 打开应用，哦，感谢cctv、mtv，数据回来了！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！ ！

后记

这次事故发生后，虽然数据幸运地能够找回，但过程却惊心动魄。 我也害怕自己的错误带来的后果以及给同事和领导带来连带的责任。 我也希望我能记住这次事故，以后不要再犯同样的错误。 现就事故情况进行反思如下：

通过这次事故，几位与项目和事故无关的同事挺身而出，帮忙查找资料，帮忙测试。 一位同事甚至在晚上1点帮忙进行数据恢复测试。 同时，当产品经理想到客户面临的巨大压力时，他并没有惊慌、责怪开发人员和具体运营人员，而是让大家冷静下来思考解决方案。 部门领导还主动帮忙想办法，陪我们加班测试，实时跟踪事情的进展。 经过大家的共同努力，事情终于有了一个比较圆满的结局。 接下来，我们将在周一上午进行集体反思，总结经验教训。 我们必须尽力避免此类事故的发生。

本文使用的工具链接：

编译安装的依赖有很多，可以网上搜索如何安装。 可惜作