8 월 8 일 중단 후 복구 스냅 샷에서 작동중인 AMI를 다시 생성하는 방법은 무엇입니까?


11

Amazon의 8 월 8 일 중단 후 모든 (EBS 기반) AMI는 많은 사용자의 작업을 중단했습니다 . 이는 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에 사용할 수 있습니다.

그러나 우분투 (11.04)에서 fsck를 강제 실행하는 방법을 모르겠습니다.

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

누구나 우분투의 볼륨에서 파일 시스템 검사를 수행하는 방법을 알고 있습니까? 복구 스냅 샷을 기반으로 작업 인스턴스를 시작하는 방법에 대한 다른 아이디어가 있습니까?

지금은 깨끗한 Ubuntu AMI 에서 다시 시작하여 모든 서비스를 다시 설정 하는 것이 더 빠를 것 같습니다 . :-( 물론 복구 스냅 샷을 실제로 얻을 수있는 방법이 있다면 물론 그렇게하지 않는 것이 좋습니다.

답변:


14

컴퓨터를 복제하려고 할 때도 같은 문제가 발생했습니다.

문제는 커널로 밝혀졌습니다. AMI와 인스턴스를 생성 할 때 커널 이미지에 기본값을 선택했습니다.

이 문제를 해결하기 위해 원래 인스턴스와 동일한 커널 이미지를 사용하여 AMI를 다시 생성했습니다.


명확히하기 위해 기본 커널 이미지에는 ext4 지원이 없지만 AMI를 빌드하는 데 사용 된 커널은 항상 사용해야합니다.
DCYorke

스냅 샷 만 남아 있으면 복구하기가 매우 어렵습니다. 이런 종류의 메타 데이터 (어떤 보안 그룹과 사용자 데이터가 사용되는지)를 스냅 샷이나 다른 곳에 백업하는 방법을 제안 할 수 있습니까?
Martijn Heemels 2016 년

2

다음 명령을 시도해 볼 수 있습니다 (--force 대신 -f 옵션 참고). sudo fsck -f /dev/xvdg

도움이 되었기를 바랍니다. 프레드


fsck -f실제로 더 많은 것을 수행합니다 (정확히 무엇을 모르고 man fsck그것에 대해 아무 말도하지 않음). + 1. 그러나 어쨌든 이것이 전체 문제를 해결하지는 못합니다. fscked 볼륨에서 스냅 샷을 생성 한 다음 AMI를 생성하고 그로부터 인스턴스를 래칭했지만 시스템 로그에 여전히 동일한 "Kernel panic ... 루트를 마운트 할 수 없음"오류가 발생합니다.
Jonik

0

이상한 AWS 관련 문제로 싸우는 데 더 많은 시간을 낭비하고 싶지 않았으므로 공식 Ubuntu AMI 중 하나에서 새로운 깨끗한 인스턴스를 만들었습니다 (제 경우 ami-359ea941에는 32 비트 EBS 지원 Ubuntu 11.04 이미지입니다. eu-west-1 region)에 접속하고 서버 설정을 다시 작성했습니다.

새 인스턴스의 복구 스냅 샷에서 생성 된 볼륨을 마운트 할 수 있다는 사실로 인해 재설정 속도가 훨씬 빨라졌습니다. 예를 들어, 나는 cp -a /mnt/recovery/usr/local /usr아래의 많은 것들을 복원하는 것과 같은 것을했다 /usr/local.

따라서 필자의 경우 복구 백업은 데이터에 액세스 할 수 있으므로 쓸모가 없었습니다. 그러나 물론 스냅 샷에서 AMI를 생성하고 전체 사건이 발생하지 않은 것처럼 인스턴스를 계속 사용하는 것이 더 좋을 것입니다. (그것을 달성하는 방법을 알고 있다면 대답을 자유롭게 추가하십시오!)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.