Recuperar dados do armazenamento da instância do EC2

Question

Então, na semana passada, uma instância do EC2 parou de responder, ainda não sei exatamente por quê, porque não consigo mais SSH, suspeito que o diretório / tmp / que foi montado em outra unidade não esteja mais acessível para alguns desconhecidos. razão.

Eu tenho alguns arquivos muito importantes que eu preciso para sair deste servidor ...

Ainda consigo extrair os logs no console da AWS, eis algumas linhas muito relevantes (ainda posso reinicializar o servidor):

        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...

Tenho certeza de que não é um problema de firewall. Aqui está a saída do 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

    

Answer 1

Então meus dados são armazenados na própria instância, então nenhum deles realmente funciona. A solução real é basicamente se inscrever no suporte da AWS e talvez obter seus dados. Veja um trecho da FAQ sobre instâncias do EC2

"Recuperação de dados A recuperação de dados do repositório de instâncias geralmente não é possível, embora o AWS Premium Support possa recuperar alguma parte dos dados se a instância não tiver sido finalizada e não houver problemas de hardware subjacentes. No entanto, a recuperação de dados não é um processo garantido e pode levar dias para ser concluído, portanto, não confie na possibilidade de recuperação de dados pelo AWS Premium Support como sua única estratégia de backup. "

    

Answer 2

Eu não acho que pedir a alguém aqui para ajudá-lo a "invadir um servidor" é particularmente propício para respostas.

1. Crie um instantâneo da sua instância do EC2 em execução
2. Crie uma nova instância.
3. Monte o instantâneo como um novo volume do EBS na instância.
4. Copie os dados do snapshot
5. Mate as instâncias de máquina virtual anterior e nova.

Ta Dah! Você acabou de recuperar os dados, sem invasão de hackers.

Algumas ferramentas aqui podem ajudar.

    

Answer 3

Os princípios básicos para acessar e corrigir um volume raiz do EBS (por exemplo, editar / etc / fstab) quando você não consegue acessar a instância são:

1. Pare a instância original A e desconecte o volume.
2. Inicie uma instância temporária B, anexe o volume a ela e monte o volume.
3. Acesse a instância B e corrija os arquivos no volume anexado / montado.
4. desmontar o volume, desanexá-lo da instância B e encerrar a instância temporária B.
5. Anexe o volume de volta à instância A original e inicie a instância A
.

Aqui está um artigo que eu escrevi que tem mais detalhes, incluindo exemplos de linhas de comando sobre como sair de situações como esta:

Fixing Files on the Root EBS Volume of an EC2 Instance
http://alestic.com/2011/02/ec2-fix-ebs-root

Isso só funciona para instâncias de inicialização do EBS. Não recomendo a execução de armazenamento de instâncias, pois isso pode colocá-lo em situações como essa sem a possibilidade de recuperar seus dados.