share facebook facebook facebook twitter twitter menu hatena pocket slack

2021.06.14 MON

AWS EC2の復元を実際に試してみた

廣山 豊

WRITTEN BY 廣山 豊

見るからに有用そうなアップデートがリリースされていたので試してみます。
(せっかく、リリース初日に記事書いたのに公開忘れてたので今更ながら)

これまで

EC2のルートボリュームを破壊しちゃった場合、これまでは以下のような手順で実施していました。
手段①
1. 破壊前のAMI Backupから新規にインスタンス起動
2. バックアップ時点からのデータ変更をできる限りリカバリ
3. エンドポイントを1に切り変える ex) ELBの付け替えや、EIPの差し替えなど用途に応じて

手段②
1. 適当なインスタンスを起動
2. 破壊されたインスタンスを停止し、rootボリュームをデタッチ
3. 1のインスタンスに、データボリューム(非root)として2をアタッチして、修復
4. 修復したrootボリュームを元のインスタンスに戻してインスタンスを起動し直す

①の方が、シンプルですが、エンドポイントの差し替えが可能な場合のみ、取れる手段であることに注意が必要です。

また、いずれも、サービス停止を伴っていました。
完全に破壊されつくして、サービスも止まっていたなら関係ないかもですが(すぐやるしかない)、復旧作業の実施タイミングが悩ましいところでもありました。
例えば、操作ミスでSSH無効化しちゃったりして、サービス運用は続けられているが、復旧が必要な場合とか。

これから

EC2インスタンスに対する操作で、簡単に、かつ、ダウンタイムなしでrootボリュームを差し替えられるようになりました!
手段②の改良版というイメージです。

条件

以下のいずれかでは、現時点ではこの手法はとれません。

  • rootボリュームがインスタンスストアボリュームの場合
  • メタルインスタンスのrootボリュームの場合

デモ

1. 下準備

Snapshot(AMIでも可)の取得

超重要です。これがないとどうしようもないことは、以前の復旧手順と変わりません。
バックアップ大事!

破壊

sshdのプロセスを止めちゃいます!

[ec2-user@ip-10-0-0-157 ~]$ sudo systemctl disable sshd
Removed symlink /etc/systemd/system/multi-user.target.wants/sshd.service.

そして、EC2インスタンスをリブート。

無事(?)、EC2インスタンスを要復旧な状態にすることが確認できました。

> ssh -i ~/hoge.pem ec2-user@52.196.184.243
ssh: connect to host 52.196.184.243 port 22: Connection refused

2. 復旧

EC2のトラブルシューティングメニューから復旧

操作は簡単。今回はマネコンで実施しましたが、CLIも提供済みです。

対象のEC2インスタンスに対し、「Monitor and troubleshoot – Replace root volume」を選択します。(下の「Storage」タブからでも可能)

Snapshotにて、予め作成しておいたバックアップを選択。
「Create replacement task」押下。

以上。とても簡単 :)

確認

実施後、すぐに完了。
無事、SSH復活。

> ssh -i ~/hoge.pem ec2-user@52.196.184.243
Last login: Fri Apr 30 01:51:34 2021 from 210.227.234.114

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
1 package(s) needed for security, out of 15 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-0-0-157 ~]$ 

まとめと注意点

操作があまりに簡単なので、裏で行われているであろうことを図にしてみました。

注意点としては、この操作により、rootのEBSボリュームとしては、新たに作られたものに挿し変わります。
つまり、再度、この操作を実施するためには、このEBSのスナップショットが必要になります。

次のミスに備え、再度バックアップを取っておくことをお勧めします。

参照

Replace an Amazon EBS root or data volume with data from a previous snapshot stored in Amazon S3.

元記事はこちら

AWS EC2の復元を実際に試してみた

廣山 豊

廣山 豊

もっか修行中

cloudpack

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