AmazonのEC2を使用して、いくつかのWebサーバー/ DBサーバーをセットアップしています。現在、すべてのシステムファイルと、アプリケーションファイル、DBファイル、ソースコード、DBバックアップのすべてを含むEBSドライブのスナップショットを毎日取得しています。バックアップの作成をスケジュールに従って実行するコンソールアプリケーションがあります。私の画像はEBS画像です。
数日後にスナップショットをドロップするタスクに取り組んでいます。私の質問は、完全な画像/ EBSタスクもスケジュールする必要がありますか？このように、サーバーに障害が発生した場合や破損した場合、最新のイメージを起動してから最新のスナップショットを適用できます。
バックアップ戦略に取り組んでいるので、Jungle Discを使用してデータディスクをバックアップしています。
回答:
私の推奨事項：
インスタンスを失った場合にソフトウェアのインストールとシステム構成を再現できるように、各新しいインスタンスのセットアップを常に文書化および/またはスクリプト化します。これをテストするには、新しいインスタンスを開始し、手順に従います。インストールに時間がかかり、インスタンスをすばやく起動する必要がある場合は、カスタムのプライベートAMIを使用できますが、そのAMI自体は、文書化された手順またはスクリプト化された手順を使用して構築する必要があります。
重要なデータは、ルートEBSボリュームではなく、個別のEBSボリュームに保管してください。これには、データを新しいインスタンスに移植しやすくする（たとえば、異なるAMIに基づいて）、他のインスタンスにデータのコピーを取得しやすくする（たとえば、スナップショットや新しいボリュームを使用する）など、多くの利点があります。
EBSデータボリュームの定期的なスナップショットを作成します。可能/適用可能な場合は、私のec2-consistent-snapshotのようなツールを使用して、一貫性のあるファイルシステム/データベースのスナップショットを取得する可能性を高めます。AWSアカウント自体が単一障害点であるため、AWS / EC2の外部でデータをバックアップします。
重要なインスタンスで、時々ルートEBSボリュームのスナップショットを作成します。これは、インスタンスまたはEBSボリュームに障害が発生した場合に役立ちますが、上記の＃1と＃2のため、その部分はそれほど重要ではありません。これを行う主な理由は、スナップショットを作成することで、ルートEBSボリューム自体の障害のリスクが減少することです。
EBSボリュームの障害率は、最後のEBSスナップショット以降にそのボリュームで変更されたブロックの数に直接関係しています。
完全な画像/ EBSタスクもスケジュールする必要がありますか？
はい、それはお勧めです。カーネルの問題が原因で何度もリセットする必要があったため、ブートディスクが読み取り不能になり、最新のスナップショットから単にブートするまで、それが私を救った。
興味がある場合は、接続されているすべてのEBSボリュームのスナップショットを作成し、一定時間後にそれらを削除するJavaクラスを作成しました。現在、私は毎週バックアップを行い、2週間後に3番目のバックアップを破棄しています。
スナップショットの取得または削除など、実行ごとに1つのアクションのみを実行します。これは、私と同じように多くのEBSを使用している場合に、同時に数十のスナップショットで過負荷になるのを避けるために1時間ごとにcronに配置することを意図しているためです
シンプルだが強力なバックアップ戦略を使用します。EC2EBSインスタンスを1日に2回実行することに基づいて新しいAMIを作成し、「古い」AMIを削除します。API（CreateImage）を使用して、新しいAMIの作成中にインスタンスを再起動しないフラグを設定するか、CreateIImage API呼び出しの前にインスタンスへのsshを使用し、新しいカーネルのほとんどの一般的なファイルシステムの「fsfreeze」またはxfs_freeze if古いカーネルとxfsを使用します。
作成された「バックアップ」AMIは、（作成されたスナップショットへのリンクを介して）元の実行中のインスタンスEBSディスクに接続されたすべてを記憶し、複数のディスクでソフトウェアRAIDを使用する場合、1回のAPI呼び出しまたはWeb経由で任意のAZで新しいインスタンスを復元できます-インターフェース。