从数据库完好无损地恢复“chmod -R 777 /”的最佳方法

题：
从数据库完整的“chmod -R 777 /”中恢复mysql（或者最糟糕的情况：迁移）的最好方法是什么？

系统：
Ubuntu 12.04 LTS
MySQL 5.5.24
64位Amazon EC2云服务器。

背景：试图恢复（或至less从数据恢复）一个系统，这样做了：

chmod -R 777 /

没有必要担心为什么。这是一个经理太多，经验太less，喜欢在深水里游泳。这是他的一个纯粹的意外事件，而不是实际意义上的打进时。

我已经恢复了大部分的系统，但是真的让mysql重新运行起来了。我已经通过这样的页面：

如何修复/恢复'sudo chmod / 777'后的ubuntu 10.04
chmod -R 777 /在Ubuntu上 – 很多问题
chmod / 775 -R，现在我们的mysql数据库正在closures…！
为什么“chmod -R 777 /”是破坏性的？

已经这样做了：

  sudo chmod 644 my.cnf chown mysql:mysql my.cnf

试图启动mysql的时候：

  sudo service mysql start

在syslog中生成此输出：

  Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.774742] type=1400 audit(1365799902.306:41): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18210 comm="apparmor_parser" Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.964496] init: mysql main process (18214) terminated with status 1 Apr 12 20:51:42 ip-10-10-25-143 kernel: [18632541.964542] init: mysql main process ended, respawning Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632542.959796] init: mysql post-start process (18215) terminated with status 1 Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.002041] type=1400 audit(1365799903.534:42): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18238 comm="apparmor_parser" Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.098490] init: mysql main process (18242) terminated with status 1 Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.098536] init: mysql main process ended, respawning Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.140706] init: mysql post-start process (18244) terminated with status 1 Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.158681] type=1400 audit(1365799903.690:43): apparmor="STATUS" operation="profile_replace" name="/usr/sbin/mysqld" pid=18258 comm="apparmor_parser" Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.285087] init: mysql main process (18262) terminated with status 1 Apr 12 20:51:43 ip-10-10-25-143 kernel: [18632543.285133] init: mysql respawning too fast, stopped

我从中读到的是，mysql正在终止状态1，它试图循环几次尝试启动，并经过太多的尝试后停止。我查看了状态1，但还没有find似乎适用的解决scheme。

使用相同的操作系统版本和MySQL版本创build新的VM实例。
在新的VM上启动MySQL – 它应该在/var/lib/mysql创build没有数据库但具有正确权限的MySQL数据目录。
在新的虚拟机上停止MySQL。
将新VM上的/var/lib/mysql复制到/var/lib/mysql.empty 。
将新VM上的/var/lib/mysql从旧VM复制到/var/lib/mysql 。
根据/var/lib/mysql.empty上的权限手动设置/var/lib/mysql所有文件和目录的权限。
现在一个短暂的祈祷神的select不会受到伤害。
在新的虚拟机上启动MySQL。
我build议使用mysqldump -A转储所有数据，重新创build一个新的空mysql数据目录，并将这些数据导入以防万一。
当你确信它能正常工作，并且你的所有数据完好无损时，closures旧的虚拟机并将其归档到某个地方。设置新的服务器比尝试从中恢复要less得多，安全得多。