從 EC2 實例儲存中恢復數據

所以上週，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 實例的快照
2. 創建一個新實例。
3. 將快照掛載為實例上的新 EBS 卷。
4. 從快照中複製數據
5. 殺死以前的和新的虛擬機實例。

達達！您剛剛恢復了數據，不涉及黑客攻擊。

這裡的一些工具可能會有所幫助。

當您無法訪問實例時，訪問和修復 EBS 根卷（例如，編輯 /etc/fstab）的基礎是：

1. 停止原始實例 A 並分離卷。
2. 啟動一個臨時實例 B，將捲附加到它，然後掛載該卷。
3. 訪問實例 B 並修復附加/安裝卷上的文件。
4. 解除安裝卷，將其與實例 B 分離，並終止臨時實例 B。
5. 將捲附加回原始實例 A 並啟動實例 A。

這是我寫的一篇文章，其中包含更多詳細資訊，包括有關如何擺脫這種情況的範例命令行：

在 EC2 實例的根 EBS 卷上修復文件

http://alestic.com/2011/02/ec2-fix-ebs-root

這僅適用於 EBS 啟動實例。我不建議執行 instance-store，因為它會使您陷入這種情況而無法恢復您的數據。

引用自：https://serverfault.com/questions/345172