数据在服务器上不小心被删除了，这确实挺让人头疼的。如果不能恢复，后果会非常严重。但我没有放弃，连续两天都在努力尝试。最终，我成功找回了那些误删的数据。现在，我将详细向大家介绍我是如何做到这一点的。
误删数据事故
那天，我在网上找到了一份卸载指南，依照指南输入了删除Oracle安装路径的指令。没多想，我就开始操作。没想到，MySQL数据库仍在运行，结果整个数据库被误删了。幸运的是，只有Tomcat的日志文件幸免于难，可能是因为文件体积较大。这台服务器上运行着客户的生产系统，已经运行了半年多，现在需要尽快恢复。
rm -rf $ORACLE_BASE/*
rm -rf /*
备份文件问题
等等，妹子使用的可是root账户啊。
就这样，把整个盘的文件全部删除了。
包括应用Tomcat、MySQL数据库 and so on。。。。
拨通电话后，我指示机房将硬盘移至另一台服务器。通过SSH登录查看，却发现文件全都不翼而飞。急忙寻找离线备份的数据库，却惊讶地发现备份文件仅有1KB大小，里面仅含有几行mysqldump的注释，显然备份脚本出现了错误。最近的完整备份是2013年12月的，这该如何是好？原本遇到问题就够让人头疼的了，现在连备份都无法信赖。
软件恢复尝试
实在别无他法，我只能在网上查找恢复误删资料的窍门。出乎意料的是，我发现了一个名为ext3grep的工具。这个工具能恢复被rm -rf命令删掉的文件。我的硬盘也是ext3格式，而且网上有人用这个工具成功恢复了数据。我把所有被删掉的文件和路径都记录了下来，心情挺舒畅的，心想这下不必启用备用计划了。这款软件声称能恢复所有文件，但我的硬盘容量有限，只能一个个试。结果，有些文件成功恢复了，但也有部分文件未能恢复。
ext3grep /dev/vgdata/LogVol00 --dump-names
数据恢复进度
心情沉重，意识到可能是磁盘空间用得太多，恢复数据的可能性极低。就算能恢复一些内容，关键资料可能就在那些能恢复的文件中。于是，我将找回的文件添加到现有数据库，调整了文件权限，重启了mysql，算是找回了一部分数据。然而，客户关键的考勤签到和手机端上报的数据仍未找到，这些数据对员工绩效影响很大，必须设法恢复。
更换工具尝试
ext3grep /dev/vgdata/LogVol00 --restore-all
我尝试了extundelete，其语法与ext3grep颇为相似。据说该工具能够根据目录恢复数据。因此，我决定继续使用这两个工具进行多次试验。我将系统安装到了测试服务器上，主要目的是检验数据是否能够被完整恢复。在测试服务器上，我执行了多项操作。这些步骤涵盖了从备份中恢复资料，替换掉之前恢复的资料，设置文件的权限，还有重启mysql服务。
ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD
发现新恢复途径
突然想到，我们这边的服务都需要binlog开启，它可能对数据恢复有帮助。然而，在这次维护中，我并未向同事充分强调其重要性，自己也没给予足够关注，管理和流程上存在不少漏洞。事故发生后，我未能及时察觉，导致部分数据已写入硬盘，这对数据恢复产生了不利影响。未来要建立一个监控体系，一旦服务遇到异常，就会以短信方式通知相关责任人。
ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.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