3
Amazon EC2インスタンス/ボリュームのシンプルなバックアップ戦略？
Amazon EC2 EBS-backed Windows Images 010の導入バックアップを入力しました... SharePoint Servicesを実行している単一のWindows 2008サーバーの簡単なバックアップ戦略を見つけるために、頭をブラウジングしています。これは、1つのデータボリュームを備えた1つのサーバーのEBS-backedイメージです。エキゾチックなものは必要ありません。「毎日」のバックアップのみが必要です（1日分のデータを失うことは壊滅的ではありません）。 使いやすいEBSバックアップAMIイメージ（Windows 2008）を作成して保存しました。新しいEBS AMIイメージを作成するだけでバックアップを開始しました。これは非常に簡単ですが、実行中のサーバーは、イメージを作成してから最初の10〜15分間オフラインになりますが、これは理想的ではありません。 バックアップを作成する標準的な方法は、実行中のインスタンスに接続されたボリュームのスナップショットを作成することです。繰り返しますが、これは非常に単純であり、サーバーはスナップショットの生成中も使用可能なままです。明らかなCatch-22は、スナップショットから直接新しいインスタンスを起動することはできないということです。 実行中のインスタンスをS3ストレージにバンドルし、S3バケットからAMIを登録する方法を知っています。これにより、実行中のインスタンスのバックアップを取得でき、実行中のインスタンスが失われた場合、S3バケットからAMIを登録し、インスタンスを回復するために新しいAMIを起動しますが、これは本当に複雑で、とんでもないように思えますAWSコンソールとFirefoxのS3オーガナイザープラグインの間を行き来して、これを実現します。（コマンドラインアプローチについては言及しないでください。これは010レベルのコースです）。 EBS-backedイメージをいじってみると、次のアプローチがうまくいくように見えます（すべてAWSコンソール内で行われます）。 1.バックアップのために、必要に応じてシステムボリューム（/ dev / sda1）のスナップショットを作成します。2.実行中のインスタンスが失われた場合は、次の手順を実行します：a。最後のスナップショットバックアップから新しいボリュームを作成しますb。開始AMIの別のインスタンスを起動します（EBSでバックアップする必要があります）c。このインスタンスを停止します。d。停止した新しいインスタンスから既存のシステムボリュームを切り離し、破棄します。e。新しく作成したボリュームをシステムボリューム（/ dev / sda1）として停止したインスタンスに接続します。f。新しいインスタンスを再起動します。これを数回テストしましたが、うまくいくようです。 質問：このアプローチには何か問題がありますか？