Как восстановить работающий AMI из моментального снимка восстановления после сбоя 8 августа?

11

После сбоя в работе Amazon 8 августа все AMI (на основе EBS) перестали работать для многих пользователей . Это связано с повреждением некоторых секторов в снимках, на которых основаны AMI.

Тем не менее, Amazon создал моментальные снимки восстановления, где проблемы с диском должны быть исправлены. Они названы в соответствии с «Снимок восстановления для vol-xxxxxxxx».

Я создал новый AMI из моментального снимка восстановления, который работал нормально, но экземпляры, запущенные из этого нового AMI, не работают: их состояние «Работает», но я не могу подключиться к машине через ssh и получить доступ к веб-службам, которые должны там работать. Это сводится к следующему (из системного журнала, доступного через консоль управления AWS):

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).

EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Я смонтировал том, созданный из этого моментального снимка восстановления, на другом сервере в AWS, и все выглядит вполне нормально. Например, fsck говорит:

$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks

В одном из обсуждений на форуме AWS я нашел этот совет от кого-то с похожими проблемами:

Обходной путь будет заключаться в том, чтобы сделать том из моментального снимка и прикрепить его к работающему экземпляру, использовать fsck --force для принудительной проверки файловой системы, а после очистки вы можете сделать моментальный снимок и использовать его для AMI.

Но я не знаю, как заставить fsck в Ubuntu (11.04):

$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'

Кто-нибудь знает, как принудительно проверить файловую систему на томе в Ubuntu? Любые другие идеи о том, как запустить рабочие экземпляры, основанные на снимке восстановления?

Прямо сейчас кажется, что было бы быстрее просто начать все заново с чистого Ubuntu AMI и переустановить все наши сервисы. :-( Но, конечно, я бы предпочел не делать этого, если есть какой-нибудь способ заставить снимок восстановления действительно работать.

— Jonik
источник

14

Я столкнулся с той же проблемой при попытке дублировать машину.

Проблема оказалась в ядре. При создании AMI и экземпляра я выбрал значение по умолчанию для образа ядра.

Чтобы решить эту проблему, я воссоздал AMI, используя тот же образ ядра, что и исходный экземпляр.

— DCYorke
источник

Для пояснения, в образе ядра по умолчанию отсутствует поддержка ext4, но в любом случае всегда следует использовать ядро, которое использовалось для сборки AMI.

— DCYorke

Если останется только снимок, восстановить его будет очень сложно. Можете ли вы предложить метод резервного копирования метаданных такого типа (а также, какие группы безопасности и пользовательские данные используются) со снимком или где-то еще?

— Мартейн Химелс

2

Не могли бы вы попробовать следующую команду (обратите внимание на параметр -f вместо --force): sudo fsck -f /dev/xvdg

Надеюсь это поможет. Фред

— Фред
источник

fsck -fдействительно делает что-то большее (не знаю точно, что; man fsckничего не говорит об этом), так что +1. Но в любом случае это не решает всей проблемы; Я создал моментальный снимок, а затем AMI из тома fscked, и запустил экземпляр этого тома, и все еще получаю ту же ошибку «Ядро паники ... Невозможно смонтировать root» в системном журнале.

— Джоник

0

Я не хотел тратить больше времени на борьбу со странными проблемами, связанными с AWS, поэтому я создал новый чистый экземпляр из одного из официальных AMI Ubuntu (в моем случае ami-359ea941это 32-разрядный образ Ebuntu 11.04 с поддержкой EBS в eu-west-1 region) и заново создал там настройки моего сервера.

Тот факт, что я мог смонтировать том, созданный из снимка восстановления в новом экземпляре, сделал переустановку намного быстрее, хотя. Например, я сделал что-то вроде того, cp -a /mnt/recovery/usr/local /usrчтобы восстановить много всего /usr/local.

Так что в моем случае резервные копии восстановления были далеко не бесполезны, так как я мог получить доступ к данным на них. Но, конечно, было бы лучше создать AMI из снимка и продолжить использовать (экземпляры из), которые, как и весь инцидент, никогда не происходили. (Не стесняйтесь добавлять ответ, если знаете, как этого добиться!)

— Jonik
источник