[aws] EC2 で壊したインスタンスを修理するには

Amazon Web Services の EC2 では、仮想ローカルコンソール機能が無いみたいなので、起動しなくなるなど、SSH でアクセスできなくなるような壊し方をした場合、手詰まりになりそうになるので、そんな方を救済する方法についての記事です。

そういう時は、EBS にアクセスすることができるように同じ Availability Zone にもう一個、一時的にマイクロインスタンスを立ち上げて、壊したインスタンスの EBS を Web 上の AWS Management Console で、まずデタッチし、一時的なインスタンスにアタッチ、マウントして修理することができます。

アタッチ、デタッチなどは、AWS Management Console と称する AWS の Web 上の管理画面で可能なので簡単にできますが、頭の中が平常な時にあらかじめ練習しておいた方がいいと思います。

具体的な操作手順
  1. 壊したインスタンスをシャットダウンする。Shutdown Behavior の設定により Terminate されると一緒に EBS が削除されるので注意する。Stop なら削除されないので大丈夫。
  2. 壊したインスタンスに関連付いている EBS (※1) をデタッチする。どこからデタッチしたかメモを取る。例: /dev/sda1
  3. 一時的なインスタンスを同じアベイラビリティゾーンに立ち上げる。
  4. ※1 を一時的なインスタンスにアタッチする。
    たとえば: /dev/sdb
  5. ファイルシステムにマウントして、修理する。
    sudo mount /dev/sdb /mnt
  6. マウント解除する。
    umount /mnt
  7. デタッチして、壊したインスタンスの方に再度アタッチする
  8. 上手く動くようになればOKで、ダメなら再度アタッチ、マウントしていじってみる。
    備考: 修復はあきらめる場合でも、データは救出できます。

そもそも私はどう壊すに至ったか
Amazon Linux AMI で、あまりよく考えずに
sudo mv /etc/sudoers.rpmnew /etc/sudoers

したら、Enter を押してから気づいたのですが、sudoers.rpmnew はほとんど何も設定されていなかったので、即座に管理者権限を失いました。
sudoers をいじるときは、万一の事態を想定して、事前に su を使えるようにしたり、root shell を別に開いておくべきでした。

参考
Locked myself out of root account on EC2 Ubuntu instance

コメント

このブログの人気の投稿

[linux] ping は通るのに No route to host と言われる

Chrome でダウンロードしたファイル名の一部がハイフンになる

[windows] Windows 回復環境 (WinRE) を修理する