昨天下午，客户发截图来说系统异常，哥的第一时间就是去看tomcat日志，直接说客户表不存在，我很好奇，这个明明有，不然早都报错了。于是打开数据库看看，顿时傻眼了！整个数据库都没了，肯定是被攻击了，最搞笑的是多了一个数据库，名字直接是qq12344，类似这样，好吧，意思就是要钱给你恢复。然后哥加了这个qq，但是并不打算给钱，只是好奇随便加下；
然后同事给我发了一个博格地址（http://blog.csdn.net/rogerzhanglijie/article/details/37902611 ），看了下是用binlog，这方面我还没接触过，于是先看看文章；看完之后大概知道是什么情况了，于是准备开始小试牛刀。
首先我查看下是不是开启binlog了，打开mysql配置：vim /etc/my.cnf; 万幸!开启了。
然后找到了日志存放的目录，由于哥是一个小白，不知道日志目录，于是用最笨的方法，
find -/ '*mysql-bin*';
于是搜索出了一大堆文件，再找到mysql-bin.00001结尾的文件，因为binlog日志文件是这个格式。。于是乎就找到日志了。。
现在找到日志之后，开始按前面提到的博客地址教程，使用mysqlbinlog生产.txt文件；先cd 到mysql的bin目录下，然后执行：
mysqlbinlog /data/mysql/mysql-bin.000003 >/data/mysql/mysql-bin.000003.txt；
这时候会提示编码问题，没办法，继续百度，然后加上 --no-defaults 参数就ok了；生成之后准备恢复；于是执行：
mysqlbinlog --no-defaults --start-position="4" --stop-position="791490" /data/mysql/mysql-bin.000003 /data/mysql/mysql-bin.000003.txt | mysql -uroot -p；
结果又出错了，说数据库不存在，好吧，确实不存在，于是新建了一个名字一样的数据库；继续执行，还是报错，说mysql.zpxstd表已存在，这个好像是mysql自带的表，在日志里有创建这个表，然后现在已经有这个表了。难道把这个表删除了？可是这样的情况很多，还有其他表；因为这样的错误，导致后面的binlog都执行不了。。怎么办？然后同事说用source，可以忽略错误继续执行。于是，命令变成这样：
source /data/mysql/mysql-bin.000003.txt;
搞定！然后查看下数据库，悲催，数据库又没了！原来日志里有drop命令，是那个黑客留下的，忘记处理drop了，处理之后再执行一次。。ok了！
注意：1.最好先在本地数据库进行操作；
2.改好之后记得把密码改复杂点
3.定时备份！
4.开启快照
5.最好不要用root远程登录，可以建个只读用户名进行远程登录
在哥进行恢复的时候，那个黑客的qq通过了好友，然后他直接问想恢复吗？我说你留着把（本来就不打算买，我们项目上线才1周，没什么数据），然后他很拽的把哥拉黑了；
来源：oschina
链接：https://my.oschina.net/u/2526698/blog/793419