share facebook facebook twitter menu hatena pocket slack

2011.08.29 MON

EC2起動不能からの復旧記録

WRITTEN BY 後藤 和貴

先日、サーバーメンテナンス時に細かな不具合が発生し、EC2の起動ができなくなったのですが、原因がわかり、少し強引にですが対処した際の記録になります。

他のメンバーからの報告で、再起動しても、AMIから復旧しようとしても起動しない、さらに起動しても接続できないとのことだったので、Management Consoleから System Log を確認すると以下のメッセージが出ていました。

*** ファイルシステム検査中にエラー
*** シェルに移行します、システムは再起動します。
*** シェルから抜ける時。
Give root password for maintenance
(or type Control-D to continue):

エラー発生しているのはrootボリュームではなくデータ専用ボリュームだったのですが、入力待ち状態のため正常起動せず /etc/fstab も書き換えられない状態でした。そこで、手順を下記にまとめてみました。

  1. 該当インスタンス停止
  2. rootボリュームを detach(デバイス名をメモ、/dev/sda1だと思います。)
  3. rootボリュームを同じAZ内の他のインスタンスへ attach
  4. 他のインスタンス、適当な位置に mount
  5. vi で fstab を編集し不具合のあるボリュームの行をコメントアウト
    (起動時に mount/fsck 対象としないようにする)
    /dev/sda1 / ext3 defaults 1 1
    none /dev/pts devpts gid=5,mode=620 0 0
    none /dev/shm tmpfs defaults 0 0
    none /proc proc defaults 0 0
    none /sys sysfs defaults 0 0
    /dev/sda3 swap swap defaults 0 0
    # /dev/sdf1 /home ext3 defaults 1 1
    
  6. rootボリュームを umount
  7. rootボリュームを detach
  8. 該当インスタンスに attach(デバイス名に注意)
  9. インスタンス起動
  10. 起動できたら不具合のあるボリュームを調査し修復

ボリュームの不具合は結局スーパーブロックが飛んでいたようで、データそのものは安全でした。
(もし、Amazon純正のAMIを利用していたら、こんなに苦労しないのでしょうか。)
AWSが便利過ぎて気が抜けていたのが見透かされていたかのように発生した不具合でした。

今回のことで、再度姿勢を正すきっかけになりました。ありがとうございました。

こちらの記事はなかの人(klog)監修のもと掲載しています。
元記事は、こちら

後藤 和貴

執行役員 / エバンジェリスト。外向けにはイベントや勉強会などで講演する役割。社内ではマーケティング全般と新商品企画やPR戦略などを担当しています。

cloudpack

cloudpackは、Amazon EC2やAmazon S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。
AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。