8月8日中断后，如何从恢复快照中重新创建可用的AMI？

亚马逊在8月8日发生故障后，所有（基于EBS的）AMI都停止为许多 用户服务。这是由于AMI所基于的快照中的某些扇区损坏。

但是，Amazon创建了应解决磁盘问题的恢复快照。这些名称按照“ vol-xxxxxxxx的恢复快照”的名称命名。

我从恢复快照创建了一个新的AMI，该快照可以正常工作，但是从该新AMI启动的实例不起作用：它们的状态为“正在运行”，但是我无法进入计算机，也无法访问应在该计算机上运行的任何Web服务。归结为这一点（从系统日志，可通过AWS管理控制台访问）：

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).

EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

我已经将通过该恢复快照创建的卷安装到AWS上的另一台服务器上，尽管看起来一切正常。例如，fsck说：

$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks

在一个AWS论坛讨论中，我从遇到类似问题的人那里获得了以下建议：

解决方法是从快照创建卷并将其附加到正在运行的实例，使用fsck --force强制检查文件系统，一旦清除，便可以创建快照并将其用于AMI。

但是我不知道如何在Ubuntu（11.04）上强制fsck：

$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'

有人知道如何在Ubuntu上强制检查文件系统吗？关于如何启动基于恢复快照的工作实例还有其他想法吗？

现在看来，从干净的Ubuntu AMI重新开始并重新设置所有服务似乎更快。:-(但是，如果有任何方法可以使恢复快照真正起作用，我当然不愿意这样做。

尝试复制机器时遇到了相同的问题。

问题原来是内核。创建AMI时，我都为内核映像选择了默认实例。

为了解决该问题，我使用与原始实例相同的内核映像重新创建了AMI。

您能否尝试以下命令（请注意-f选项而不是--force）： sudo fsck -f /dev/xvdg

希望这可以帮助。弗雷德

我不想浪费更多的时间来解决与AWS有关的怪异问题，因此我从一个官方的Ubuntu AMI中创建了一个新的干净实例（在我的情况下ami-359ea941，这是32位EBS支持的Ubuntu 11.04映像）。 eu-west-1区域），并在那里重新创建我的服务器设置。

我可以在新实例中挂载从恢复快照创建的卷，这一事实使重新设置要快得多。例如，我做了一些类似的事情，cp -a /mnt/recovery/usr/local /usr要恢复下的很多东西/usr/local。

因此，就我而言，恢复备份远非无用之举，因为我可以访问其中的数据。但是，当然，从快照中创建一个AMI并继续使用（整个事件从未发生过的）实例仍然是更好的选择。（如果您知道如何实现，请随意添加答案！）