您的位置:首页 > 数据库 > MySQL

记一次mysql数据库被勒索(中)

2020-08-15 23:03 1616 查看

 背景在上一篇文章里面已经提过了。【参考:记一次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数据库被勒索(上)

真的是手贱了。。。这个问题,又费了九牛二虎之力才找到原因,好在最后也恢复成功了。

这个留在下篇再写吧。

 

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: