记一次mysql数据库被黑，及通过几种方案恢复数据，复盘总结
事件经过早上上班客户反映，项目无法登陆，于是抓包看了下接口，报错数据库表不存在。当时心里一慌，打开数据库查看。果然，只有孤零零的一个表 README 以下数据库已被删除：*。 我们有一个完整的备份。 要恢复它，您必须将0.013比特币（BTC）支付给我们的比特币地址bc1qs82lvzrrag7aqpnyme4njv32qquky0slrclftr。 有关说明，请通过yang21@tutanota.com通过电子邮件联系我们。 任何与付款无关的邮件都将被忽略！
这是一个中途接手维护的项目，平时改动也不多，所以没有特别的关注。数据库是在服务器上自己搭建的，并没有对数据库进行数据备份。于是采取紧急数据恢复。
数据恢复
方案1（通过binlog日志进行恢复）
数据库被删，第一反应就是通过binlog恢复。
执行命令show variables like '%log_bin%';查看binlog是否开启。
binlog是开启的。
执行命令show master logs;查看所有binlog日志列表。
感觉不太妙，只有两个日志文件。
执行命令show variables like 'expire_logs_days';查看binlog过期时间。
只保留了10天的日志这条路行不通了。好吧先把10天的数据恢复出来。
mysqlbinlog命令参考mysqlbinlog参数详解
执行命令mysqlbinlog ./mysql-bin.000012 > /home/12.sql
导出mysql-bin.000012文件的sql保存到/home/12.sql。同样步骤导出mysql-bin.000013的所有sql。记得删表drop命令后再进行数据恢复。或者mysqlbinlog ./mysql-bin.000013 --start-datetime="2021-07-02 00:00:00 --stop-datetime="2021-07-12 01:15:00 " > /home/13.sql 设置指定的时间范围。
注意：binlog尽量下载到本地进行恢复，防止对线上数据库造成二次污染。
方案2（通过邮箱联系删库者，进行恢复）
搜集信息
通过BTC浏览器查询BTC地址，该地址并没有任何交易记录，是一个新的地址。 googel搜索删库者留下的邮箱，发现同一晚上被删库的不止一家，应该是脚本批量执行的。
联系删库者
由于binlg无法恢复数据，当时又比较着急，就按照要求向BTC地址转账。结果是徒劳的，那边收到币后就没有再回复过邮箱。
事后分析
后来通过分析mysql登录日志发现1点15份12秒一个泰国IP登录，binlog日志中drop命令是1点15分52秒执行，中间四十秒根本不足以备份几个G的数据库。（吐槽下：删库者是真的没有一点职业素养，靠技术吃饭的活，非要搞成诈骗性质，就算加密文件备份到本地服务器也行啊）
方案3（通过硬盘误删恢复）
该方案有点后知后觉了，之前有过恢复物理硬盘的经历，对于云服务器硬盘恢复不甚了解，前两种方案无果才去执行该方案。
通过了解，如果当数据库误删后，不进行任何磁盘操作有90%以上的概率能恢复数据，当然费用也是不低，根据数据大小每张表差不多上千元的价格。
执行此方案的时候，磁盘已经有几个G的操作了（恢复binlog......）
复盘总结
[*]数据库一定要开启定时备份，最好进行异地备份，如上传到OSS，防止服务器shell被拿后，删除本地备份。
[*]数据库一定要开启binlog,并且设置binlog保存时间为永久，磁盘不允许可以定期把binlog日志文件备份到其他地方，保证binlog日志完整。
[*]数据库安全。使用复杂的密码，使用权限较低的子账号，不使用远程登录，修改默认3306端口，定期检查登录日志等。
[*]如果发现被恶意删库，先对磁盘做一个镜像，binlog下载到本地进行数据恢复，为硬盘恢复准备条件。
[*]对于恶意删库索要报酬恢复数据，可以根据删库者留下的信息进行分析，分析是对手恶意攻击还是批量脚本的执行。登录时间删库时间的时间差判断是否进行过数据备份等，最终判断是否支付报酬。
文档来源：开源中国社区https://my.oschina.net/u/4260135/blog/5134680
页:
[1]