Назад | Перейти на главную страницу

Восстановить данные из хранилища инстансов 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.

Вот статья, которую я написал, в которой есть более подробная информация, включая примеры командных строк, о том, как выйти из таких ситуаций:

Исправление файлов на корневом томе EBS экземпляра EC2
http://alestic.com/2011/02/ec2-fix-ebs-root

Это работает только для экземпляров загрузки EBS. Я не рекомендую запускать instance-store, так как это может привести к подобным ситуациям без возможности восстановления ваших данных.

Итак, мои данные фактически хранятся в самом экземпляре, поэтому ни один из них не работает. Фактическое решение состоит в том, чтобы подписаться на поддержку AWS и, возможно, получить ваши данные. Вот отрывок из EC2 Instance FAQ

«Восстановление данных Восстановление данных из хранилища экземпляров обычно невозможно, хотя AWS Premium Support может быть в состоянии восстановить некоторую часть данных, если экземпляр не был остановлен и никаких проблем с оборудованием не существует. Однако восстановление данных не является гарантированным процессом. и это может занять несколько дней, поэтому не полагайтесь на возможность восстановления данных с помощью AWS Premium Support в качестве единственной стратегии резервного копирования ".