继亚马逊之后8 月 8 日停电，所有（基于 EBS 的）AMI 停止工作许多 用户。这是由于 AMI 所基于的快照中的一些扇区损坏所致。
但是，Amazon 创建了修复磁盘问题的恢复快照。这些快照的命名方式为“vol-xxxxxxxx 的恢复快照”。
我从恢复快照创建了一个新的 AMI，它工作正常，但从这个新 AMI 启动的实例不起作用：它们的状态是“正在运行”，但我无法通过 ssh 进入机器，也无法访问应该在那里运行的任何 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并重新设置我们所有的服务。:-(但是，如果有任何方法可以让恢复快照真正起作用，我当然不想这样做。
答案1
当我尝试复制一台机器时遇到了同样的问题。
问题原来出在内核上。在创建 AMI 和实例时，我都为内核映像选择了默认设置。
为了解决这个问题，我使用与原始实例相同的内核映像重新创建了 AMI。
答案2
您可以尝试以下命令（注意使用 -f 选项而不是 --force）：
sudo fsck -f /dev/xvdg
希望这能有所帮助。弗雷德
答案3
我不想再浪费时间与奇怪的 AWS 特定问题作斗争，所以我从官方的一个创建了一个新的干净实例Ubuntu AMI（在我的情况下ami-359ea941，它是 eu-west-1 区域中 32 位 EBS 支持的 Ubuntu 11.04 图像），并在那里重新创建了我的服务器设置。
事实上，我可以在新实例中安装从恢复快照创建的卷，这使得重新设置的速度更快。例如，我做了类似的事情cp -a /mnt/recovery/usr/local /usr来恢复下的一大堆东西/usr/local。
因此，就我而言，恢复备份并非毫无用处，因为我可以访问其中的数据。但当然，如果只是从快照创建 AMI 并继续使用（来自的实例），就像整个事件从未发生过一样，那就更好了。（如果您知道如何实现这一点，请随时添加答案！）