MySQL恢复 – Database SOS

[MY-013183] [InnoDB] Assertion failure故障处理

标题：[MY-013183] [InnoDB] Assertion failure故障处理

在一个存储故障的环境中,通过做硬件恢复,恢复出来一个mysql数据库,但是直接启动报错

[mysql@localhost bin]$ ./mysqld
2025-04-17T03:34:50.352302Z 0 [System] [MY-010116] [Server] /data/mysql/mysql/bin/mysqld (mysqld 8.0.34) starting as process 58239
2025-04-17T03:34:50.356910Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-04-17T03:34:51.031054Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=160] log sequence number 1728577790947 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031090Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031118Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=131] log sequence number 1728577833027 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031124Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031138Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=3621] log sequence number 1728577635513 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.031142Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.031193Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_002′ Page [page id: space=4294967278, page number=167] log sequence number 1728577760219 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042480Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_001′ Page [page id: space=4294967279, page number=184] log sequence number 1728577792529 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042486Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.042359Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘innodb_undo_001′ Page [page id: space=4294967279, page number=1975] log sequence number 1728577800027 is in the future! Current system log sequence number 1728577469817.
2025-04-17T03:34:51.042681Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.059937Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2025-04-17T03:34:51.159245Z 0 [ERROR] [MY-011971] [InnoDB] Tablespace ‘xff/t_xifenfei’ Page [page id: space=153, page number=4] log sequence number 1728577926919 is in the future! Current system log sequence number 1728577498088.
2025-04-17T03:34:51.159280Z 0 [ERROR] [MY-011972] [InnoDB] Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB redo log files. Please refer to http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html for information about forcing recovery.
2025-04-17T03:34:51.163187Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: fut0lst.ic:81:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA thread 140491735693056
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2025-04-17T03:34:51Z UTC – mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=f183cd3ecfc35a4aa5da997063d5e8c97ffca986
Thread pointer: 0x7fc6bc000b60
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 7fc6c7ffeaf0 thread_stack 0×100000
/data/mysql/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0×41) [0x21323b1]
/data/mysql/mysql/bin/mysqld(print_fatal_signal(int)+0x2a2) [0xfef932]
/data/mysql/mysql/bin/mysqld(my_server_abort()+0×75) [0xfefb75]
/data/mysql/mysql/bin/mysqld(my_abort()+0xe) [0x212c24e]
/data/mysql/mysql/bin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0×309) [0x237cde9]
/data/mysql/mysql/bin/mysqld() [0x2349cf0]
/data/mysql/mysql/bin/mysqld() [0x234aa54]
/data/mysql/mysql/bin/mysqld(trx_purge(unsigned long, unsigned long, bool)+0xeb) [0x234d56b]
/data/mysql/mysql/bin/mysqld(srv_purge_coordinator_thread()+0×450) [0x23224b0]
/data/mysql/mysql/bin/mysqld(void Detached_thread::operator()<void (*)()>(void (*&&)())+0xca) [0x224bcaa]
/lib64/libstdc++.so.6(+0xc2ba3) [0x7fc731c11ba3]
/lib64/libpthread.so.0(+0x814a) [0x7fc732fe614a]
/lib64/libc.so.6(clone+0×43) [0x7fc7312eef23]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0): Connection ID (thread ID): 0
Status: NOT_KILLED

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

这个报错主要含义是：

多个表空间（特别是innodb_undo_*）的日志序列号(LSN)比当前系统LSN要大，这表明可能存在数据损坏或不一致
系统最终因为断言失败而崩溃

对于这样的情况,可以通过mysql强制拉库的方式启动mysql,如果可以启动成功直接使用mysqldump导出数据,然后重建新库,如果无法启动mysql成功,那就考虑通过对单个的ibd基表进行discard+import方式进行恢复参考:MySQL 8.0版本ibd文件恢复，如果这个方法不能成功考虑直接通过工具读取ibd文件参考:frm和ibd文件数据库恢复

.[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：.[OnlyBuy@cyberfear.com].REVRAC勒索mysql恢复

有朋友接到一个mariadb库被加密的case,部分文件被加密为:.[D2BB58C7].[OnlyBuy@cyberfear.com].REVRAC扩展名

黑客预留的+README-WARNING+.txt内容类似:

YOUR FILES ARE ENCRYPTED

Your files, documents, photos, databases and other important files are encrypted.

You are not able to decrypt it by yourself! The only method of recovering files is to purchase an unique private key.
Only we can give you this key and only we can recover your files.

To be sure we have the decryptor and it works you can send an 
    email: TechSupport@cyberfear.com  and decrypt one file for free.

Before paying you can send us up to 1 file for free decryption. The total size of files must be less than 1Mb 
(non archived), and files should not contain valuable information. (databases,backups, large excel sheets,sql. etc.) 

Do you really want to restore your files?
Write to email: OnlyBuy@cyberfear.com

Your personal ID is indicated in the names of the files and in the end of this message, before writing a message by email
indicate the name of the ID indicated in the files IN THE SUBJECT OF THE EMAIL

Attention!
 * Do not rename encrypted files.
 * Do not try to decrypt your data using third party software, it may cause permanent data loss.
 * Decryption of your files with the help of third parties may cause increased price (they add their fee to our) 
   or you can become a victim of a scam.

YOUR ID: D2BB58C7

通过分析ibd文件没有被破坏

这种情况恢复相对比较简单,可以直接通过对单独ibd文件会的思路进行处理,类似恢复文章:
frm和ibd文件数据库恢复
MySQL 8.0版本ibd文件恢复
[MySQL异常恢复]mysql ibd文件恢复
InnoDB: Cannot open table db/tab from the internal data dictionary of InnoDB though the .frm file for the table exists
当然前提需要有表创建语句,这个客户有昨天的备份的被的.sql备份,通过技术手段分析,确认只有3个表的创建语句丢失,对于丢失的ddl语句,通过直接对ibdata文件解析获取,基于这些信息结合,实现数据的完美恢复

对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持，请联系我们:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。

.hmallox加密mariadb/mysql数据库恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：.hmallox加密mariadb/mysql数据库恢复

有客户运行在win机器上的mariadb数据库被勒索加密了,加密扩展名为.hmallox
hmallox

HOW TO BACK FILES.txt文件内容

Hello

Your data has been stolen and encrypted
We will delete the stolen data and help with the recovery of encrypted files after payment has been made

Do not try to change or restore files yourself, this will break them
We provide free decryption for any 3 files up to 3MB in size on our website

How to contact with us:
1) Download and install TOR browser by this link: https://www.torproject.org/download/
2) If TOR blocked in your country and you can't access to the link then use any VPN software
3) Run TOR browser and open the site: wtyafjyxxxxxxxxxxxxxxxxxxxxxxxxljoyuklaad.onion/mallox/privateSignin
4) Copy your private ID in the input field. Your Private key: D7xxxxxxxxxxxxxxx90
5) You will see chat, payment information and we can make free test decryption here

Our blog of leaked companies:

wtyafjyxxxxxxxxxxxxxxxxxxxxxxxxljoyuklaad.onion

If you are unable to contact us through the site, then you can email us: mallox.resurrection@onionmail.org
Waiting for a response via mail can be several days. Do not use it if you have not tried contacting through the site.

通过分析,ibd文件情况尚可
ibd

对于这种情况,对于ibd文件进行分析结合客户提供的字典信息,完美恢复数据,业务直接使用

A_H_README_TO_RECOVER勒索恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：A_H_README_TO_RECOVER勒索恢复

有客户mysql数据库被黑(业务数据库被删除)，创建了一个A_H_README_TO_RECOVER库

[root@www.xifenfei.com ~]# mysql -uroot -pxxxxx
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4539028
Server version: 5.6.50-log Source distribution

Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.

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> show databases;
+-----------------------+
| Database              |
+-----------------------+
| information_schema    |
| A_H_README_TO_RECOVER |
| mysql                 |
| performance_schema    |
+-----------------------+
8 rows in set (0.00 sec)

mysql> use A_H_README_TO_RECOVER;
Database changed
mysql> show tables;
+---------------------------------+
| Tables_in_A_H_README_TO_RECOVER |
+---------------------------------+
| README                          |
+---------------------------------+
1 row in set (0.00 sec)

mysql> desc README;
+------------+----------+------+-----+---------+-------+
| Field      | Type     | Null | Key | Default | Extra |
+------------+----------+------+-----+---------+-------+
| zh_content | longtext | YES  |     | NULL    |       |
| en_content | longtext | YES  |     | NULL    |       |
| email      | longtext | YES  |     | NULL    |       |
+------------+----------+------+-----+---------+-------+
3 rows in set (0.00 sec)

mysql>  select *from README ;
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-------------------------+
| zh_content                                                                                                                                                                                                                                | en_content                                        | email                   |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-------------------------+
| 请与我们联系进行数据恢复，或者你对我们的项目感兴趣，也可以与我们取得联系。未与我们联系的，数据和组织信息将会公布在国内各大平台中。联系邮件：honey_xiaowu@keemail.me                                                                       | honey_xiaowu@keemail.me or honey_xiaowu@proton.me | honey_xiaowu@keemail.me |
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------+-------------------------+
1 row in set (0.00 sec)

mysql> exit
Bye

对于这类情况类似以前处理的case：
read_me_recover_tn勒索恢复
 RECOVER_YOUR_DATA勒索恢复
 A____Z____RECOVER____DATA勒索恢复
处理方法一般也就是先考虑os层面恢复,如果os层面无法恢复,就从block层面进行恢复,这个客户通过最终分析,恢复出来客户需要的表数据
101244
对于类似这种A_H_README_TO_RECOVER勒索恢复,建议先对系统进行镜像或者快照,然后按照先os层面恢复,在block级别恢复的方法处理,如果无法自行解决,可以联系我们进行技术支持,最大限度抢救和数据,减少损失
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上

应用连接错误,初始化mysql数据库恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：应用连接错误,初始化mysql数据库恢复

有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)
mysql

登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片
page

然后通过一些思路找出来需要恢复的表对应的page文件,然后对其进行解析恢复出来需要的数据

具体技术文章参考:
kettle导致MySQL数据丢失恢复
[MySQL异常恢复]恢复数据字典表讲解
[MySQL异常恢复]mysql drop table 数据恢复
[MySQL异常恢复]使用工具直接抽取MySQL数据字典
MySQL drop database恢复(恢复方法同样适用MySQL drop table,delete,truncate table)

read_me_recover_tn勒索恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：read_me_recover_tn勒索恢复

最近有客户被MySQL删库勒索,现象如下:
1. 删除掉以前的库,并创建一个同名库,并且会创建一个read_me_recover_tn库,类似下图:

2. 在read_me_recover_tn库中有一个readme表,每个被删除然后创建的库里面也有一个readme表

3. 每个readme表内容类似信息类似:

mysql> desc readme
    -> ;
+-----------------+------+------+-----+---------+-------+
| Field           | Type | Null | Key | Default | Extra |
+-----------------+------+------+-----+---------+-------+
| id              | int  | NO   | PRI | NULL    |       |
| Message         | text | YES  |     | NULL    |       |
| Bitcoin_Address | text | YES  |     | NULL    |       |
+-----------------+------+------+-----+---------+-------+
3 rows in set (0.01 sec)

mysql> select * from readme\G;
*************************** 1. row ***************************
             id: 1
        Message: I have backed up all your databases. To recover them you must
 pay 0.008 BTC (Bitcoin) to this address: 15f9vdGBeT1NCMp6z9NxrQEEUxnYqRPvyC . 
Backup List: xxxx_db, xxxx_db_test. After your payment email me at 
dbrestore3195@onionmail.org with your server IP (xx.xx.xx.xx) and transaction 
ID and you will get a download link to your backup. Emails without transaction 
ID and server IP will be ignored.
Bitcoin_Address: 15f9vdGBeT1NCMp6z9NxrQEEUxnYqRPvyC
1 row in set (0.00 sec)

这类勒索和我以前介绍相关文章类似:
RECOVER_YOUR_DATA勒索恢复
 A____Z____RECOVER____DATA勒索恢复

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

RECOVER_YOUR_DATA勒索恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：RECOVER_YOUR_DATA勒索恢复

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

会删除掉你的所有库里面表，并且在每个库里面创建一个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:107644445 E-Mail:dba@xifenfei.com
另外建议加强系统和mysql安全加固,数据库尽量不要暴露在公网上

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

联系：手机/微信(+86 17813235971) QQ(107644445)

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

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

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

kettle导致MySQL数据丢失恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

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

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

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

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

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

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

MySQL数据库文件丢失恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

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

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

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

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

恢复出来客户需要数据

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

分类目录归档：MySQL恢复