Amazon EC2 EBSバックアップ：AMIとスナップショット
サーバーのバックアップメカニズムを作成しようとしているので、システムがクラッシュした場合、単一のスクリプトを実行してシステム全体を作成できるはずです。
Amazonのドキュメントを読んだ後、これはバックアップの作成と復元に関する私の理解です
バックアップ
- AMIイメージを作成します（これは毎月更新できます）
- スナップショットを作成します（これは、スナップショットを作成する毎日のスクリプトを使用して実行できます）
復元（スクリプト）
- AMIを使用してEBSインスタンスを作成する
- EBSボリュームを作成されたインスタンスに接続します
今私の質問は
- バックアップを取り、復元する最良の方法ですか？
- AMIとEBSボリューム（スナップショットを使用）の2つのことを実際にバックアップする必要がありますか、スナップショットのみを保持できますか？
- スナップショット機能がないため、これはローカルインスタンスストアインスタンスでは機能しないことを理解しています。ローカルインスタンスストアインスタンスのバックアップおよび復元プロセスを作成するにはどうすればよいですか？
より良い代替手段を見つけることができなかったので、最初のアプローチに固執しています。
EBSの場合
バックアップ：
- AMIイメージを作成します（これは毎月更新できます）。
- スナップショットを作成します（これは、スナップショットを作成する毎日のスクリプトを使用して実行できます）。
復元（スクリプト）
- AMIを使用してEBSインスタンスを作成します。
- EBSボリュームを作成されたインスタンスに接続します。
インスタンスストアの場合、アプリケーションのみを保持しているため（データベースは保持していません）、そのバックアップを保持する必要はありません。
EBSスナップショットは、バックアップを作成する優れた方法です。
スクリプトを使用して、EBSボリュームのスナップショットを頻繁に実行できます。毎週、毎日、毎時、またはクレジットカードが許す限り頻繁に。唯一の制限は、同時に実行できるスナップショットの数に関するものです。これに到達すると、EBS APIは、いくつかの実行中の操作が完了するまでエラーを返し始めます。
壊滅的なイベントに対するバックアップを提供するために、スナップショットをリージョンからリージョンにコピーすることもできます。
EBSボリュームのスナップショットを作成する場合、そのスナップショットはボリューム全体のものです。 AMIから作成された場合でも、スナップショットには、ボリュームの新しいインスタンスを作成するために必要なすべてが含まれています。これを自分で簡単に試すことができます。
インスタンスがLinuxベースの場合、スナップショットを作成している場合、AMIを作成する必要はありません。回復する必要がある場合は、スナップショットからその場でAMIを作成できます。そのプロセスを自動化した場合、それは非常に簡単です。
- Windowsでは、スナップショットからEC2インスタンスを起動できないという制限があるため、AMIを使用する必要があります。この制限を回避する方法があります：私の会社のブログで書いたこの投稿をチェックアウトできます：
http://www.n2ws.com/blog/3-ways-ec2-windows-backup-and-recovery.html
EBSスナップショットに加えて Auto Scaling を使用することをお勧めします。インスタンスがハードウェア障害のために死にかけている場合、またはAmazonによる廃止が予定されている場合、Auto Scalingは新しいインスタンスを自動的に開始します。
ただし、この場合は、動的データにNASを設定する必要があります。サーバーの負荷に応じて、実行中のインスタンスの数は異なり、すべてのスケーリングサーバーはNASストレージ。
データベースも別のサーバーに配置する必要があります。または、優れた自動バックアップ/ Point-In-Time-Restore機能があるため、 Amazon RDS を使用することもできますが、そのために追加料金を支払う必要があります。
1）はい。スナップショットはEBSボリュームのバックアップと復元に最適な方法です。
2）依存します。EBSでバックアップされたAMIとしてルートボリュームがある場合は、それらのスナップショットも作成でき、管理性が向上します。
3）RsyncおよびAMIは、インスタンスストアで使用可能なオプションです