所以上周，EC2 上的一个实例停止了响应，我仍然不知道具体原因，因为我无法再通过 SSH 登录，我怀疑由于某些未知原因，安装到另一个驱动器的 /tmp/ 目录不再可访问。
我有一些非常重要的文件需要从这个服务器上删除......
我仍然能够在 AWS 控制台中提取日志，这里有一些非常相关的行（我仍然能够重新启动服务器）：
Welcome to CentOS release 5.4 (Final)
Press 'I' to enter interactive startup.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Thu Dec 29 13:52:43 EST 2011 [ OK ]
Starting udev: [ OK ]
Setting hostname localhost.localdomain: [ OK ]
No devices found
Setting up Logical Volume Management: File descriptor 7 (/sys/kernel/hotplug) leaked on lvm.static invocation. Parent PID 232: /bin/bash
[ OK ]
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1
/dev/sda1: clean, 202786/1310720 files, 1428718/2621440 blocks
[ OK ]
Remounting root filesystem in read-write mode: [ OK ]
Mounting local filesystems: [ OK ]
Enabling local filesystem quotas: [ OK ]
chown: cannot access `/tmp/.ICE-unix': No such file or directory
Enabling /etc/fstab swaps: [ OK ]
INIT: Entering runlevel: 4
Entering non-interactive startup
Starting background readahead: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0:
Determining IP information for eth0...mktemp: cannot create temp file /tmp/wnt890: No such file or directory
/sbin/dhclient-script: line 57: $rscf: ambiguous redirect
/sbin/dhclient-script: line 62: $rscf: ambiguous redirect
/sbin/dhclient-script: line 69: $rscf: ambiguous redirect
done.
[ OK ]
Starting getsshkey: /etc/rc4.d/S11getsshkey: line 12: /tmp/my-key: No such file or directory
getting ssh-key...
/etc/rc4.d/S11getsshkey: line 17: /tmp/my-key: No such file or directory
getting ssh-key...
我确信这不是防火墙问题。以下是 nmap 的输出
[root@ip-xxxxxxxxx ~]# nmap -sS -P0 xxxxxxxxxxx
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-12-29 16:32 EST
Interesting ports on xxxxxx (xxxxxxxxx):
Not shown: 1675 filtered ports
PORT STATE SERVICE
22/tcp closed ssh
25/tcp closed smtp
80/tcp closed http
443/tcp closed https
8000/tcp closed http-alt
答案1
我认为要求这里的任何人帮助您“侵入服务器”并不会特别有助于找到答案。
- 创建正在运行的 EC2 实例的快照
- 创建一个新实例。
- 将快照作为新的 EBS 卷挂载到实例上。
- 从快照复制数据
- 终止前一个和新的虚拟机实例。
太棒了！您刚刚恢复了数据，无需黑客攻击。
一些工具这里可能有帮助。
答案2
当您无法访问实例时，访问和修复 EBS 根卷（例如，编辑 /etc/fstab）的基本方法是：
- 停止原始实例A并分离卷。
- 启动临时实例B，将卷附加到该实例，并挂载该卷。
- 访问实例 B 并修复附加/安装卷上的文件。
- 卸载卷，将其与实例 B 分离，并终止临时实例 B。
- 将卷重新附加到原始实例 A，并启动实例 A。
这是我写的一篇文章，其中有更详细的信息，包括如何摆脱这种情况的示例命令行：
修复 EC2 实例的根 EBS 卷上的文件
http://alestic.com/2011/02/ec2-fix-ebs-root
这仅适用于 EBS 启动实例。我不建议运行 instance-store，因为它可能会让您陷入无法恢复数据的境地。
答案3
所以我的数据实际上存储在实例本身上，所以这两种方法都不起作用。实际的解决方案基本上是注册 AWS 支持，也许可以获取你的数据。以下是摘录自EC2 实例常见问题解答
“数据恢复 实例存储的数据恢复通常是不可能的，但如果实例尚未终止且不存在底层硬件问题，AWS Premium Support 可能能够恢复部分数据。不过，数据恢复并不是一个有保证的过程，可能需要几天才能完成，因此不要依赖 AWS Premium Support 的数据恢复可能性作为您唯一的备份策略。”