爱站程序员基地背景在上一篇文章里面已经提过了。【参考：记一次mysql数据库被勒索（上）】
现在面临的问题是nextcloud没有mysql数据库，用不起来了。
因为文件没丢，一种方法是启动新的mysql数据库，把文件重新提交一次。
为了程序员的面子，没有选择这么没技术含量的方法。我想通过恢复mysql数据库来解决这个问题。
恢复mysql数据库
于是，在mysql目录里面找找看，发现了一堆binlog文件。上网查了一下，binlog文件里面好像有记录mysql的操作，可以用来恢复数据库。
查看binlog：#ll -th binlog.*
先把最近的binlog转成SQL：
mysqlbinlog /var/lib/mysql/binlog.000011 > /var/lib/mysql/11.sql
打开11.sql，里面果然有被黑的记录。创建了一个“PLEASE_READ_ME_VVV\”的数据库和\”WARNING\”的数据表。
看来有希望。
把所有binlog都转成SQL，查看什么时候创建nextcloud数据库的。
# grep -i \”create database\” *.sql
注：需要找到第一次创建nextcloud库的记录，这个记录会包含建表操作，否则恢复数据时会报如下数据表找不到的错误：
顺便找一下，什么时候被删除数据库的。
# grep -i \”drop database\” *.sql
查看11.sql，找到黑客入侵前的日志，只恢复到这个时间点的数据（之后的数据也恢复的话，相当于又删除一遍数据）
只转换部分binlog的话，可以使用–start-position 和 –stop-position来界定，参数的值就是上图红框处，# at 82015的值。
或者也可以全部转换成SQL后，手动将SQL中不要的操作删除掉。
# mysqlbinlog –stop-position=82015 /var/lib/mysql/binlog.000011 > /var/lib/mysql/11_1.sql
根据上面的grep结果，我只需要恢复5~10的全部LOG，以及11的部分LOG（删除黑客操作的部分）。
将5~11的binlog转换成SQL准备好，就可以开始恢复了。
恢复过程：
1，删除nextcloud仓库以及PLEASE_READ_ME_VVV仓库；
mysql> drop database `nextcloud`;
mysql> drop database `PLEASE_READ_ME_VVV`;
2，加载5~10和11_1的SQL文件。
mysql> source /var/lib/mysql/5.sql;
。。。
恢复完成后，查看一下nextcloud仓库，数据表已经恢复回来了。哦耶！
随着数据库的恢复，心情也逐渐畅快起来，就是不能向恶势力低头嘛，哈哈哈。
———————————————————————————————————————————-
本来，至此，nextcloud应该就可以直接恢复成功了。然而。。。又出幺蛾子了。。。。
nextcloud还是显示\”Internal server error\” ，查看日志发现，错误变成了mysql访问拒绝。
这个地方报错原因是密码错误。因为nextcloud在之前重新配置过数据库导致的。参考：记一次mysql数据库被勒索（上）
真的是手贱了。。。这个问题，又费了九牛二虎之力才找到原因，好在最后也恢复成功了。
这个留在下篇再写吧。
