误删悲剧
rm -rf $ORACLE_BASE/*
工作那两天，我依照网上的教程操作，输入了一条指令，打算移除mysql的安装文件夹。没想到，Linux竟然能删掉正在运行的文件，数据库几乎全被清空，只留下一个未能删除的大日志文件。我赶紧给机房打了电话，把硬盘移到了另一台服务器上。上去一看，文件全都不见了，那可是运行了半年多的生产系统，我顿时感到十分惊讶。
rm -rf /*
等等，妹子使用的可是root账户啊。就这样，把整个盘的文件全部删除了。包括应用Tomcat、MySQL数据库 and so on。。。。
备份堪忧
文件被清空了，我赶紧寻找离线备份的数据库，却发现备份文件仅有1kb大小，里面只有几行注释。再仔细一看，最近的备份还是2013年12月的。那一刻，我慌了，心想怎么这么倒霉，备份怎么会变成这样，感觉就像天要塌下来一般。
领导部署
ext3grep /dev/vgdata/LogVol00 --dump-names
部门领导得知情况后，立刻制定了应对最坏情况的B方案。领导亲自带领团队，周日与产品一同赶往客户所在地，周一早上便与对方高层进行了交流。我那时内心既感愧疚又焦急，尽管如此，我还是希望能自己解决问题，于是急忙上网搜索数据恢复的方法。
初现曙光
ext3grep /dev/vgdata/LogVol00 --restore-all
经过一番网络搜索，我发现了一款可以恢复被rm -rf命令删除文件的软件。我们使用的磁盘是ext3格式，网上已有不少用户成功恢复数据的案例。当我看到打印出来的被删除文件和路径时，我非常高兴，心想不必实施B计划了，文件都有希望被找回，内心充满了希望。
ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD
恢复波折
软件只能恢复所有文件，无法按目录进行恢复，而且现在磁盘空间不足。我尝试恢复了几份文件，有的成功，有的却失败了。我心中一沉，担心磁盘已被覆盖，恢复的可能性降低。尽管如此，我还是希望能尽可能多地恢复文件，期盼着在可恢复的MYD文件中找到重要的数据。
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
将找回的文件添加至现有数据库，调整了文件权限后重启了mysql，成功恢复了部分数据。然而，客户关键的考勤签到记录和手机端上报的数据尚未恢复。于是尝试了另一款工具，在测试服务器上按照流程操作，但依然未能完全找回。后来尝试使用mysql-bin文件进行恢复，执行还原命令后竟然成功了。
这次事故主要因维护人员安排不当，导致管理和流程极度混乱。自动备份存在缺陷，无人检查，事故发生后未能及时察觉，致使部分数据无法恢复。今后需编写应用监控程序，一旦服务异常，通过短信及时通知责任人。大家觉得还有哪些方法可以防止此类数据误删事故发生？欢迎在评论区留言讨论，并别忘了点赞和转发。
extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh
