我发现太迟了，我们的MySQL数据库的备份脚本工作不正常。 也就是说，当服务器上的磁盘已经开始出现故障时，我通过SSHlogin，并得到一个损坏的二进制垃圾的屏幕。 从那些不是空的.sql.gz文件的微不足道的备份中恢复，会使我们失去一个月的数据。 我真的很喜欢，如果我能避免这种情况。
我已经能够fsck磁盘，并提取了/var/lib/mysql目录的内容，每个数据库在子目录下有一个100MB的ibdata1 ， ib_logfile*文件以及.frm和.opt文件。 我没有/etc/mysql/my.cnf ，那里的一切似乎都丢失了。 没有.ibd文件，可能是因为innodb_file_per_table被closures了。
我在我的开发机器上安装了MySQL 5.5安装（与失败相同的版本），并尝试恢复文件，按照这里的build议， 在这里 。 我把ibdata1和.frm和.opt文件放到/var/lib/mysql mysql:mysql ，在我重新创build表之后，将文件的权限和所有者设置为默认值（一些mysql:mysql ，一些mysql:root ）使用mysql客户端的模式。
然后我用命令运行mysqld：
/usr/sbin/mysqld –innodb_log_file_size=4128768 –innodb_force_recovery=6
它立即终止，没有输出。 一个dmesg | tail dmesg | 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 ，我试图用.frm和.opt文件夹覆盖ibdata1和数据库子目录。 我已经尝试过，没有日志文件，并从1-6增加恢复值。
如果我恢复原来的mysql目录，mysqld启动就好了。 Apparmor没有在机器上运行（有些人有问题）。
我在Percona的MySQL性能博客上读到，可以从ibdata1文件恢复数据。 我只有每个数据库2个表，我有模式，但阅读提供他们的恢复工具的自述文件，它看起来像我至less需要能够启动MySQL来获取有关表空间的信息。