重新启动后，我无法通过 ssh 客户端和 Web 浏览器访问我的实例，然后我使用前一个实例的 Ami 创建了一个新实例，但仍然无法访问我的实例。
然后我读突然无法访问非日志记录 EC2 实例该怎么办？邮政
但我从那里了解到，必须创建一个新实例才能恢复服务器上的文件，并且必须重新安装所需的所有软件包
有没有办法可以解决这个问题，而无需创建一个新的实例并重新安装软件包，因为那样做真的会花费很多时间？
提前致谢
答案1
来自评论：
我从损坏的实例中创建了一个 Ami，然后用于启动一个新实例
原始实例中出现的问题很可能在替换实例中出现问题，因此至少该部分看起来是一致的。如果你从原始实例中创建了一个新实例，原来的AMI，这解释起来会困难得多。
记住——为了未来——一旦你启动并测试了一个实例，并验证了它可以重新启动，请停止它，并在它仍然工作时对其进行快照，创建一个 AMI，从 AMI 创建一个实例，并验证整个过程从头到尾都是稳固的。
但是，对你的问题的简短回答应该是的，除了扔掉所有东西重新开始之外，应该还有其他恢复方法……但克隆损坏的机器应该是可以预料到的不是工作，这取决于原来的机器不工作的原因。
如果您仍有可用的原始实例，那么这将是开始进行故障排除的最佳位置，因为新的实例上还可能存在其他问题。
当然，如果您只是“重启”了实例，而不是真正“停止”并“启动”了实例，您也应该尝试这样做……因为停止实例会在其运行的物理主机上销毁它，并在新的物理主机上重新启动它。万一出现问题，此步骤可以清除该问题，尽管我从未遇到过这种情况。
否则，启动实例，并给它一点时间尝试启动。然后，从 EC2 控制台中的“实例”中，您应该能够选择实例，单击“操作”下拉菜单，并选择“获取系统日志”以从机器检索控制台输出，以查看它未启动的原因或它在做什么。
您遇到的问题几乎一定是以下几个问题之一：
- 根文件系统损坏
- 根文件系统正常，但关键文件被无意删除
- 根文件系统正常，文件也正常，但配置错误导致无法完全启动
- 实例实际上已完全启动，但某些配置错误导致您无法访问它 - 例如 sshd、iptables 或路由表的配置
- 实例的低级内核与您的安装不兼容（如果实例最初正常运行，则不太可能出现这种情况）
假设您的安全组配置没有阻止访问的简单问题，您应该会看到某物在系统日志中解释或至少提示了为什么您的实例没有启动……很难推测上述哪个原因最有可能。
你应该能够识别某物但是，从控制台日志中...您在原始问题中没有提到控制台中的两个状态检查显示了什么，或者您是否在安全组中打开了“ICMP 回显请求”，这将允许您 ping 该实例。
如果您可以在控制台日志中发现问题，那么问题就变成了如果您在物理服务器上遇到同样的问题，您是否知道该怎么做才能解决该问题。
如果是这样，那么您应该能够通过连接并编辑/修复包含损坏实例的根分区的实际磁盘卷上的文件来解决问题：
- 停止损坏的实例
- 在控制台中分离根 EBS 卷
- 从 AWS 提供的库存 Linux AMI 之一创建一个新实例。
- 允许它启动，并验证连接性（如果这里也没有连接，那么肯定还有其他事情发生）
- 在控制台中将损坏实例的根卷附加到新实例上的可用虚拟设备
- 登录新实例
- 将旧实例的根文件系统挂载到方便的地方，例如 /mnt
- 通过编辑 /etc/fstab 或 /etc/ssh/sshd_config 来修改配置以修复任何损坏的内容，或者禁用或更正行为不当的服务的配置等。
- 卸载卷
- 在控制台中分离卷，然后将其重新连接到损坏的实例
- 重新启动损坏的实例
当然，这需要具备查找和解决所遇到的问题的专业知识......但我已经通过这些步骤成功拯救了由于配置错误而无法启动的机器......类似于如果我有一台物理机器和一张装满命令行工具的救援 CD 会做的事情。