分类目录归档：MySQL恢复

mysql数据库被黑恢复—应用层面delete删除

发表于 2024 年 1 月 12 日 由 惜分飞

客户的mysql被人从应用层面攻击,并且删除了一些数据,导致业务无法正常使用,通过底层分析binlog确认类似恢复操作
20240112131751

确认这类的业务破坏是通过delete操作实现的,客户那边不太幸,客户找了多人进行恢复,现场严重破坏,老库被删除,并且还原了历史的备份文件(非故障第一现场),通过底层扫描恢复出来ibd和page文件,然后解析对应的文件,运气不错,恢复出来客户需要的数据
20240112131907
发表在 MySQL恢复 | 标签为 , | 评论关闭

kettle导致MySQL数据丢失恢复

发表于 2023 年 12 月 17 日 由 惜分飞

有客户通过kettle 插入数据，由于配置不当导致原数据丢失,希望能够恢复之前数据（mysql数据库）
20231217125043

通过分析（相关文件的时间）,判断kettle应该是在插入数据之前触发了truncate操作导致数据丢失,而且还插入了部分数据
2023121712561220231217125738
通过数据块层面扫描分析,找出来需要恢复表对应的page文件
20231217125854
解析这些page文件恢复出来客户需要数据
20231217130029
遇到此类误操作,最重要的是保护现场,尽可能减少对数据文件所在分区的写入操作,可以实现最大限度数据恢复.

发表在 MySQL恢复 | 标签为 , , | 评论关闭

MySQL数据库文件丢失恢复

发表于 2023 年 12 月 10 日 由 惜分飞

客户服务器重启,mysql相关数据文件丢失
20231206095845

通过底层工具进行分析,无法正确恢复数据库名字,一个个单个ibd文件(而且很多本身是错误的)
20231210224010
对于这种情况,通过mysql block扫描恢复出来page文件
20231210224106
恢复出来客户需要数据
20231210224248
20231207215458
这个客户出现该故障的原因大概率是由于文件系统损坏导致.最终可以比较好的恢复,主要是故障之后第一时间保护了现场,没进行任何的写入覆盖,如果覆盖了神仙也没有办法.如果此类问题无法自行解决或者恢复效果不好,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

发表在 MySQL恢复 | 标签为 , , , | 评论关闭