AWS Windows Serverのバックアップ自動化とリカバリー
(2015.1.10追記)
2014/9/10より前に作成された Windows Server 2012 R2 AMIを利用しているEC2インスタンスの場合、スナップショットからのリカバリー時に正しく起動しない可能性があります。
以下のAWSからのお知らせを確認のうえ、適切な対処を行ってください。
・Amazon EC2 インスタンス上で Windows Server 2012 R2 をご利用のお客様へ重要なご案内
https://aws.amazon.com/jp/windows/products/ec2/server2012r2/network-drivers/
(2015.1.10追記ここまで)
AWSでWindows Serverを自動でバックアップする設定と、そのバックアップからリカバリーする設定を行ったのでまとめておきます。
以下の実験で使用したAMIは、Microsoft Windows Server 2012 Base – ami-37b0c036 です。
Windows Serverのバックアップ自動化
ここでは、EBSボリュームのスナップショットを作成することで、OSのディスクイメージごとバックアップをとることにします。
EC2のLinuxサーバーインスタンスがあれば、そのLinuxサーバー上でAWS SDKやAWS CLIを使用したスクリプトを実行して、Windows Serverインスタンスのスナップショットの作成を行うとよいでしょう。
スクリプトをcronに登録すれば、自動化できます。
Windows Serverインスタンスしか存在しない場合はどうしましょう?
Windows PowershellのSDKを使う方法があるでしょうが、(僕のように)Powershellを使ったことがない人にとってはちょっと面倒ではないでしょうか。
※スナップショットを作成するAWS SDKはAWS内のサーバーでなくても、どこでも動作しますが、バックアップ対象サーバーと同じAWSアカウント内で完結したほうが管理しやすいと思います。
そんなときは、クラスメソッドさんが公開しているCloudFormationのテンプレート「ソンナコトモアロウカト」を使うと便利です。
(参考)
Developers.IO
1クリックで毎日スナップショットを自動取得 ? ソンナコトモアロウカト編 | アドカレ2013 : CFn #14
http://dev.classmethod.jp/cloud/aws/aws-cfn-advent-calendar-2013-snapshot/
(2015.7.1追記)
2015年6月、ソンナコトモアロウカトのv1.4がリリースされたとのことです。
Developers.IO
【お知らせ】1クリックで毎日スナップショットを自動取得 〜 ソンナコトモアロウカト v1.4 リリース
http://dev.classmethod.jp/cloud/aws/sonna-kotomo-aroukato-1-4-release/
(2015.7.1追記ここまで)
ここに書いてある手順どおりにCloudFormationのスタックを作成してパラメータを設定すれば、Backup=true のタグをセットしたEBSボリュームのスナップショットが作成されます。
まさに「1クリックで毎日スナップショットを自動取得」です。
CloudFormationとAutoScalingを組み合わせると、「指定した時刻にスナップショット作成処理を行うためだけのEC2インスタンスを起動して、必要な処理を実行して、終了後にEC2インスタンスを停止・削除する。」というようなことが一発でできてしまうんですね。
バックアップを実行するためのEC2インスタンスは毎日1時間分の課金しかされないので、料金も月200円ぐらいしかかかりません。
素敵なツールですね!
サーバーにログインしなくても、AWS Management Consoleの操作だけで設定が完了してしまうというのも大きなポイントだと思います。
もちろん、今回のように「Windows Serverのバックアップ」ではなく、LinuxほかあらゆるEC2インスタンスのバックアップに使用できます。
テンプレートは公開されており、カスタマイズもできます。
僕は、スナップショットがどのインスタンスのバックアップかがわかりやすいよう、作成されるスナップショットのNameタグに、バックアップ対象のEC2インスタンスのNameタグをセットするようにしました。
Windows Serverのリカバリー
バックアップとして作成されたスナップショットから、Windows Serverをリカバリーしてみます。
(Windows Serverをコピーするときもほぼ同様の手順となります。)
Linuxサーバーですと、
スナップショットからAMIを作成 →AMIからEC2インスタンスを作成
という手順となります。
ところが、AWSの仕様で、「スナップショットからのAMI作成はLinux/Unixしか対応していない。」ということがわかりました。
これは知らなかった。。
(参考)
Server Fault
Is it possible to create an EBS AMI for windows EC2 instance?
https://serverfault.com/questions/355742/is-it-possible-to-create-an-ebs-ami-for-windows-ec2-instance
ということでWindows Serverについては、↑に記載があるとおり「標準のAMIからWindows Serverを起動し、スナップショットから作成したボリュームに付け替える。」という方法でリカバリーします。
リカバリーは、大まかに下記の手順となります。
- スナップショットから新しいボリュームを作成
- 新しいEC2インスタンスを作成
- EC2インスタンスを停止
- EC2インスタンスのボリュームをDetach
- EC2インスタンスに新しいボリュームをAttach
- EC2インスタンスを起動
- 動作確認
- Detachしたボリュームを削除
イメージは以下のような感じです。
以下、詳細手順です。
1. スナップショットから新しいボリュームを作成
作成されたスナップショットを選択して、’Create Volume’します。
‘Availability Zone’ は、EC2インスタンスを作成するゾーンを指定します。
2. EC2インスタンスを作成
AMIとしては、バックアップしたEC2インスタンスを作成したときと同じAMI(今回は ‘ami-37b0c036’)を使用します。
EC2インスタンスのステータスが’Running’になるのを待ちます。
(2015.1.10追記)
なお、「バックアップしたEC2インスタンスを作成したときと同じAMI」がAWSが提供する標準AMIの場合、いつのまにかLaunch時に選択できなくなっていることがあります。
その場合、同じWindows Serverシリーズの新しい日付(YYYY.MM.DD)がついたバージョンのAMIを使用してEC2インスタンスを作成するとうまくいくようです。
例えば、AMI: Windows_Server-2012-R2_RTM-Japanese-64Bit-Base-2014.11.19 (ami-e580bae4)を使用したインスタンスのスナップショットから新しいボリュームを作成
→ AMI: Windows_Server-2012-R2_RTM-Japanese-64Bit-Base-2014.12.10 (ami-ec7e73ed)にボリュームをAttach
で問題なくリカバリーできることを確認しました。
(2015.1.10追記ここまで)
3. EC2インスタンスを停止
2.で作成したEC2インスタンスを’Stop’します。
EC2インスタンスのステータスが’Stop’になるのを待ちます。
4. EC2インスタンスのボリュームをDetach
2.で作成したEC2インスタンスに紐づいているボリュームを選択して、’Detach Volume’します。
このボリュームはあとで削除するので、Volume-Idをメモしておくか、わかりやすいようタグをつけておくとよいでしょう。
5. EC2インスタンスに新しいボリュームをAttach
1.でスナップショットを基に作成した新しいボリュームを選択して、’Attach Volume’します。
インスタンスとして、2.で作成したEC2インスタンスを指定します。
ここで、’Device’ は、rootデバイスの ‘/dev/sda1’ を指定します。
※’Windows Devices: xvdf through xvdp’ と表示されていますが、気にしなくてよいです。
※デバイス指定を変更しないと、
Error starting instances
Invalid value ‘i-xxxxxxxx’ for instanceId.
Instance does not have a volume attached at root (/dev/sda1)
のエラーとなります。
これで、EC2インスタンスのボリュームを「付け替えた」ことになります。
6. EC2インスタンスを起動
EC2インスタンスを選択して、’Start’します。
EC2インスタンスのステータスが’Running’になるのを待ちます。
7. 動作確認
Windows Serverにログインして動作確認を行います。
8. Detachしたボリュームを削除
4.でDetachしたボリュームは不要なので削除します。
これで、Windows Serverが無事リカバリーできました。
まとめ
クラスメソッドさんによるツールを利用することで、AWS上のWindows Serverでも比較的容易にバックアップ、リカバリーできることがわかりました。
EBSのスナップショットについては、RDSのバックアップ設定と同じような感じで、AWS Management Consoleで簡単に設定できるようになるとよいですね。