RECOVER_YOUR_DATA勒索恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:RECOVER_YOUR_DATA勒索恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

mysql数据库被删除库的勒索新变种
20240122235221


会删除掉你的所有库里面表,并且在每个库里面创建一个RECOVER_YOUR_DATA表

[root@xff  appdata1]# cd receipt_2
[root@xff   receipt_2]# ls
db.opt  RECOVER_YOUR_DATA.frm  RECOVER_YOUR_DATA.ibd

并且创建一个RECOVER_YOUR_DATA数据库,里面有一张RECOVER_YOUR_DATA表

[root@xff RECOVER_YOUR_DATA]# ls -ltr
total 116
-rw-rw---- 1 mysql mysql    61 Jan 21 10:14 db.opt
-rw-rw---- 1 mysql mysql  8560 Jan 21 10:14 RECOVER_YOUR_DATA.frm
-rw-rw---- 1 mysql mysql 98304 Jan 21 10:14 RECOVER_YOUR_DATA.ibd

所有的RECOVER_YOUR_DATA表内容为:
All your data is backed up. You must pay 0.018 BTC to 164hyKPAoC5ecqkJ2ygeGoGFRcauWRLujV In 48 hours,
your data will be publicly disclosed and deleted. (more information: go to http://iplis.ru/data2)
After payment send mail to us: rambler+280cs@onionmail.org and
we will provide a link for you to download your data. Your DBCODE is: 280CS
这类的故障和以前恢复的A____Z____RECOVER____DATA勒索恢复基本上一样,对于类似这种RECOVER_YOUR_DATA勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

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

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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


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

kettle导致MySQL数据丢失恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:kettle导致MySQL数据丢失恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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


通过分析(相关文件的时间),判断kettle应该是在插入数据之前触发了truncate操作导致数据丢失,而且还插入了部分数据
2023121712561220231217125738

通过数据块层面扫描分析,找出来需要恢复表对应的page文件
20231217125854

解析这些page文件恢复出来客户需要数据
20231217130029

遇到此类误操作,最重要的是保护现场,尽可能减少对数据文件所在分区的写入操作,可以实现最大限度数据恢复.

MySQL数据库文件丢失恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:MySQL数据库文件丢失恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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


通过底层工具进行分析,无法正确恢复数据库名字,一个个单个ibd文件(而且很多本身是错误的)
20231210224010

对于这种情况,通过mysql block扫描恢复出来page文件
20231210224106

恢复出来客户需要数据
20231210224248
20231207215458

这个客户出现该故障的原因大概率是由于文件系统损坏导致.最终可以比较好的恢复,主要是故障之后第一时间保护了现场,没进行任何的写入覆盖,如果覆盖了神仙也没有办法.如果此类问题无法自行解决或者恢复效果不好,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

A____Z____RECOVER____DATA勒索恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:A____Z____RECOVER____DATA勒索恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户MySQL数据库被黑,业务库中表被删除,并创建A____Z____RECOVER____DATA库,里面有一张readme表,内容为:

mysql> select * from readme \G;
*************************** 1. row ***************************
zh_content: 请尽快与我们取得联系,否则我们将会公布你的数据库信息在网络中,联系邮件:datacenterback@keemail.me
en_content: 请尽快与我们取得联系,否则我们将会公布你的数据库信息在网络中,联系邮件:datacenterback@keemail.me
     email: datacenterback@keemail.me
1 row in set (0.00 sec)

a_z_recover_data


对于这种情况,本质就是mysql drop 库或者drop表级别的恢复,通过反删除软件恢复,可惜恢复效果很差(底层发生了大量的覆盖)
os-recovery

对于这种情况,只能采用底层block级别恢复,通过底层扫描分析
20231121211906

并解析扫描结果恢复需要数据
20231121212028

对于类似这种A____Z____RECOVER____DATA勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上

InnoDB: Database page corruption on disk or a failed file read of page恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:InnoDB: Database page corruption on disk or a failed file read of page恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

由于文件系统或者硬件故障导致mysql启动报错InnoDB: Database page corruption on disk or a failed file read of page
mysql-error


使用innodb_force_recovery参数,数据库启动成功,但是部分表查询报错,对于这种情况,是由于ibd文件本身有损坏,通过DISCARD TABLESPACE和IMPORT TABLESPACE也无法解决,只能对ibd文件进行恢复,通过工具直接解析ibd文件恢复其中数据
20230212125347

MySQL 8.0版本ibd文件恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:MySQL 8.0版本ibd文件恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

对于单个的ibd文件,大部分情况下可以通过DISCARD TABLESPACE和IMPORT TABLESPACE方式进行恢复

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> CREATE TABLE `t1` (
    ->   `id` int DEFAULT NULL
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values(1);
Query OK, 1 row affected (0.02 sec)

mysql> insert into t1 values(2);
Query OK, 1 row affected (0.01 sec)

mysql> insert into t1 values(3);
Query OK, 1 row affected (0.00 sec)

关闭mysql服务,备份mysql中的t1.ibd文件

[root@xifenfei ~]# service mysql stop
Shutting down MySQL..... SUCCESS! 
[root@xifenfei test]# cp t1.ibd  t1_bak

启动mysql服务,并删除并创建新的t1表(表结构相同)

[root@xifenfei test]# service mysql start
Starting MySQL..................... SUCCESS! 


[root@xifenfei test]# mysql -uroot -poracle test
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.31 MySQL Community Server - GPL

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> drop table t1;
Query OK, 0 rows affected (0.20 sec)


mysql> 
mysql> CREATE TABLE `t1` (
    ->   `id` int DEFAULT NULL
    -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
Query OK, 0 rows affected (0.01 sec)

DISCARD TABLESPACE操作

mysql> ALTER TABLE t1 DISCARD TABLESPACE;
Query OK, 0 rows affected (0.01 sec)

把备份的t1.ibd还原回去并修改权限

[root@xifenfei test]# mv t1_bak t1.ibd
[root@xifenfei test]# ls -ltr
total 112
-rw-r-----. 1 root root 114688 Dec 18 17:24 t1.ibd
[root@xifenfei test]# chown mysql.mysql t1.ibd 

IMPORT TABLESPACE并验证数据

mysql> ALTER TABLE t1 IMPORT TABLESPACE;
Query OK, 0 rows affected, 1 warning (0.24 sec)

mysql> select * from t1;
+------+
| id   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

在恢复途中如果遇到表定义不对,或者ibd文件损坏,或者版本不匹配等各种情况,可能在IMPORT TABLESPACE的时候可能出现类似ERROR 1808 (HY000): Schema mismatch (Clustered index validation failed. Because the .cfg file is missing, table definition of the IBD file could be different. Or the data file itself is already corrupted.)错误

mysql>  alter table       `t1` import tablespace;                    
ERROR 1808 (HY000): Schema mismatch (Clustered index validation failed. 
Because the .cfg file is missing, table definition of the IBD file could be different. 
Or the data file itself is already corrupted.)

如果出现此类错误,无法直接通过该方法进行解决,参考frm和ibd文件数据库恢复,使用专业恢复工具进行处理

MyISAM表delete记录恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:MyISAM表delete记录恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户delete删除了myisam表中的部分数据,本来表中4-5w条记录,删除之后值剩余几十条,希望对其进行恢复(该库没有开启binlog)

mysql> select count(1) from db_bet;
+----------+
| count(1) |
+----------+
|       46 |
+----------+
1 row in set (0.00 sec)

通过分析.MYD文件确认数据依旧在文件中
myisam-delete-recovery


通过工具对其删除操作分析,找到记录如下
20221125175222

对其记录入库确认

mysql> select count(1) from db_bet_deleted;
+----------+
| count(1) |
+----------+
|    40158 |
+----------+
1 row in set (0.10 sec)

mysql ibd文件反删除恢复之后异常处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:mysql ibd文件反删除恢复之后异常处理

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户因为误操作删除了mysql的datadir目录,并且mysql数据库已经关闭(如果没有关闭可以采用类似方法:mysql 数据库目录被删除恢复),由于无法通过该方法直接处理,首先尝试文件系统层面进行恢复
20220715215237


虽然可以看到相关的数据文件(最大的一个表的ibd文件100多G),通过查看该ibd文件发现几乎全部为0
20220715215439

基于这种情况,无法通过文件系统层面进行恢复,只能考虑从mysql block层面进行恢复,参考类似恢复:又一起mysql rm删除数据库目录事故处理方法,实现绝大多数数据恢复
20220715215058

再次提醒对于mysql数据库也需要考虑好安全备份方案,谁都不能保证人永远不误操作,不能保证硬件永远不出故障.

InnoDB: Cannot open table db/tab from the internal data dictionary of InnoDB though the .frm file for the table exists

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:InnoDB: Cannot open table db/tab from the internal data dictionary of InnoDB though the .frm file for the table exists

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户找到我说mysql无法正常使用报错如下(库名.表名 doesn’t exist):
mysql-doesnot-exist


客户确认表的frm和ibd文件均存在.通过检查mysql日志,发现大量类似异常
mysql-1

而且情况一样ibd和frm文件均存在,系统日志中提示:
2022-07-08T08:37:57.935514Z 1423 [Warning] InnoDB: Cannot open table 库名/表名 from the internal data dictionary of InnoDB though the .frm file for the table exists. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
根据对mysql的认知,出现此类问题,很可能是mysql的ibdata文件出了问题,对日志进行分析,发现类似记录

2022-07-08T04:11:27.413455Z 0 [Note] /www/server/mysql/bin/mysqld (mysqld 5.7.34-log) starting as process 2144 ...
2022-07-08T04:11:27.495536Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-07-08T04:11:27.495559Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-07-08T04:11:27.495562Z 0 [Note] InnoDB: Uses event mutexes
2022-07-08T04:11:27.495565Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-07-08T04:11:27.495568Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-07-08T04:11:27.495571Z 0 [Note] InnoDB: Using Linux native AIO
2022-07-08T04:11:27.496130Z 0 [Note] InnoDB: Number of pools: 1
2022-07-08T04:11:27.496227Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-07-08T04:11:27.510618Z 0 [Note] InnoDB: Initializing buffer pool, total size=256M,instances=1,chunk size=128M
2022-07-08T04:11:27.520144Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-07-08T04:11:27.522095Z 0 [Note] InnoDB: If the mysqld execution user is authorized, 
        page cleaner thread priority can be changed.  See the man page of setpriority().
2022-07-08T04:11:27.532135Z 0 [Note] InnoDB: The first innodb_system data file 'ibdata1' did not exist. 
       A new tablespace will be created!
2022-07-08T04:11:27.532259Z 0 [Note] InnoDB: Setting file '/www/server/data/ibdata1' size to 10 MB. 
        Physically writing the file full; Please wait ...
2022-07-08T04:11:27.760116Z 0 [Note] InnoDB: File '/www/server/data/ibdata1' size is now 10 MB.
2022-07-08T04:11:27.760338Z 0 [Note] InnoDB: Setting log file /www/server/data/ib_logfile101 size to 128MB
2022-07-08T04:11:27.760414Z 0 [Note] InnoDB: Progress in MB:
 100
2022-07-08T04:11:28.940355Z 0 [Note] InnoDB: Setting log file /www/server/data/ib_logfile1 size to 128 MB
2022-07-08T04:11:28.940442Z 0 [Note] InnoDB: Progress in MB:
 100
2022-07-08T04:11:30.517357Z 0 [Note] InnoDB: Renaming log file /www/server/data/ib_logfile101 
      to /www/server/data/ib_logfile0
2022-07-08T04:11:30.517394Z 0 [Warning] InnoDB: New log files created, LSN=45790
2022-07-08T04:11:30.517401Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-07-08T04:11:30.517425Z 0 [Note] InnoDB: Setting file '/www/server/data/ibtmp1' size to 12 MB. 
       Physically writing the file full; Please wait ...
2022-07-08T04:11:30.609146Z 0 [Note] InnoDB: File '/www/server/data/ibtmp1' size is now 12 MB.
2022-07-08T04:11:30.609236Z 0 [Note] InnoDB: Doublewrite buffer not found: creating new
2022-07-08T04:11:30.631133Z 0 [Note] InnoDB: Doublewrite buffer created
2022-07-08T04:11:31.160847Z 0 [Note] InnoDB: 96 redo rollback segment(s) found.96 redo rollback segment(s) are active.
2022-07-08T04:11:31.160860Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2022-07-08T04:11:31.160970Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2022-07-08T04:11:31.194147Z 0 [Note] InnoDB: Foreign key constraint system tables created
2022-07-08T04:11:31.194175Z 0 [Note] InnoDB: Creating tablespace and datafile system tables.
2022-07-08T04:11:31.195079Z 0 [Note] InnoDB: Tablespace and datafile system tables created.
2022-07-08T04:11:31.195098Z 0 [Note] InnoDB: Creating sys_virtual system tables.
2022-07-08T04:11:31.195974Z 0 [Note] InnoDB: sys_virtual table created
2022-07-08T04:11:31.196099Z 0 [Note] InnoDB: Waiting for purge to start
2022-07-08T04:11:31.246167Z 0 [Note] InnoDB: 5.7.34 started; log sequence number 0
2022-07-08T04:11:31.246379Z 0 [Note] Plugin 'FEDERATED' is disabled.
2022-07-08T04:11:31.248996Z 0 [Warning] InnoDB: Cannot open table mysql/plugin from the internal data dictionary 
        of InnoDB  though the .frm file for the table exists. 
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
mysqld: Table 'mysql.plugin' doesn't exist

通过上述日志可以确认,数据库应该被重新初始化了,导致以前库的ibd和frm文件无法被正常访问.对于此类情况,可以参考以前类似恢复案例:frm和ibd文件数据库恢复