我发现 MySQL 数据库的备份脚本无法正常工作，但为时已晚。也就是说，当服务器上的磁盘已经开始出现故障时，我通过 SSH 登录，屏幕上全是损坏的二进制垃圾。从那些不只是空的 .sql.gz 文件的微不足道的备份中恢复会让我们丢失大约一个月的数据。如果我能避免这种情况，我会非常高兴。
我已经能够 fsck 磁盘并提取/var/lib/mysql目录的内容，其中包含 100MB ibdata1、ib_logfile*文件.frm和.opt子目录下每个数据库的文件。我没有/etc/mysql/my.cnf，那里的所有内容似乎都丢失了。没有 .ibd 文件，大概是因为 innodb_file_per_table 已关闭。
我在开发机器上安装了 MySQL 5.5（与失败的版本相同），并尝试按照建议恢复文件这里， 和这里。在我使用 mysql 客户端从模式重新创建表之后，我将ibdata1.frm 和 .opt 文件放入/var/lib/mysql并将文件的权限和所有者设置为与默认值相同（some mysql:mysql，some ）。mysql:root
然后我使用以下命令运行 mysqld：
/usr/sbin/mysqld –innodb_log_file_size=4128768 –innodb_force_recovery=6
它立即终止，没有任何输出。Admesg | tail显示一大堆：
[ 781.937089] init: mysql main process (1819) terminated with status 1
[ 781.937127] init: mysql respawning too fast, stopped
和/var/log/mysql.log均为/var/log/mysql.err空。
我尝试过多种恢复过程。我尝试过将整个恢复的 mysql 数据目录复制到 中/var/lib，我尝试过只覆盖ibdata1数据库子目录和 .frm 和 .opt 文件夹。我尝试过带日志文件和不带日志文件的方案，并将恢复值从 1 增加到 6。
如果我恢复原始 mysql 目录，mysqld 就可以正常启动。Apparmor 未在机器上运行（有些人遇到了问题）。
我在 Percona 的 MySQL 性能博客上看到，可以仅从 ibdata1 文件恢复数据。每个数据库只有 2 个表，并且我有架构 - 但阅读其恢复工具提供的 README，看起来我至少需要能够启动 mysql 才能获取有关表空间的信息。