この質問には興味深い点があります。具体的には、ダウンタイムの考え方に関してです。アイデアの一部は、アプリケーションがダウンタイムの影響を受けやすい場合、リカバリ時間も考慮に入れる必要があるということです（極端な議論として、バックアップが必要でない限り、バックアップにダウンタイムは必要ありません。その場合、ダウンタイムは無限に近づくことがあります。 ）。
EBSについて
EBSボリュームとスナップショットはブロックレベルで動作します。その結果、EBSボリュームが使用中であっても、インスタンスの実行中にスナップショットを取得できます。ただし、スナップショットに含まれるのは、実際にディスク上にある（つまり、ファイルキャッシュにない）データのみです。スナップショットの一貫性という考え方が生まれるのは、後者の理由です。
- 推奨される方法は、ボリュームを切り離し、スナップショットを作成してから再接続することです。通常は実用的ではありません。
- 次善の策は、書き込みキャッシュをディスクにフラッシュし、ファイルシステムをフリーズし、スナップショットを作成することです。
ここで興味深い点は、上記のどちらの場合でも、スナップショットが再接続/フリーズ解除されてディスクへの書き込みが再開されるのを待つ必要がないことです。スナップショットが開始されると、データはその時点と一致します。通常、これは数秒でディスクが書き込みロックされます。また、ほとんどのデータベースはディスク上のファイルを合理的な方法で構造化しているため、挿入による既存のブロックへの影響が最小限になる可能性が高く、スナップショットに追加されるデータが最小限に抑えられます。
バックアップのポイントを考慮する
EBSボリュームはアベイラビリティーゾーン内ですでに複製されているため、ある程度の冗長性が組み込まれています。インスタンスが終了した場合、EBSボリュームを新しいインスタンスに接続するだけで（一貫性の欠如を乗り越えた後）再開できますやめた。多くの点で、これにより、EBSボリュームは、アクセス可能な場合、不整合なスナップショットのようになります。とはいえ、ほとんどのEC2ユーザーはおそらく2011年の初めからのEBSボリュームのカスケード障害を思い出します-ボリュームには数日間アクセスできず、一部のユーザーもデータを失いました。
RAID1
EBSディスクの障害から保護しようとしている場合（それは起こります）、RAID1セットアップを検討することができます。EBSボリュームはブロックデバイスであるため、mdadmを使用して簡単に目的の構成に設定できます。EBSボリュームの1つが仕様どおりに実行されない場合は、手動でボリュームを故障させる（そして後で別のEBSボリュームと交換する）のは簡単です。もちろん、これには欠点があります-すべての書き込みの時間が増加し、可変パフォーマンスの影響を受けやすくなり、I / Oコストが2倍になり（金銭的であり、パフォーマンスの観点からではありません）、より広範囲のAWS障害に対する実際の保護はありません（昨年の一般的な問題はロックされた状態のEBSボリュームを切り離すことができないこと）、そしてもちろん、障害時にディスクの一貫性のない状態。
S3FS
特定のアプリケーションのオプション（データベースには絶対にありません）は、S3をローカルファイルシステムとしてマウントすることです（たとえば、s3fsを介して）。これは遅く、ファイルシステムに期待されるいくつかの機能が欠如しており、期待どおりに動作しない可能性があります（結果整合性）。とはいえ、アップロードされたファイルをインスタンス間で利用できるようにするという単純な目的には、メリットがあるかもしれません。明らかに、優れた読み取り/書き込みパフォーマンスを必要とするものには適していません。
MySQLビンログ
MySQL固有のもう1つのオプションは、bin-logの使用です。bin-logを格納する2番目のEBSボリュームをセットアップし（データベースへの追加の書き込みの影響を最小限に抑えるため）、それを使用するデータベースダンプと組み合わせて使用できます。s3fsでこれを行うこともできるかもしれませんが、パフォーマンスが許容できる場合は実際にメリットがあります（s3fsを直接使用するよりもrsyncの方がおそらく優れており、できる限り圧縮する必要があります）。
しかし、もう一度、目的の考えに戻ります。上記の提案で何が起こるかを検討してください：
- アクセスできないEBSボリューム：
- RAID1-データにアクセスできないため、役に立たない
- bin-log-S3にエクスポートしない限り役に立たない-おそらくそれを行っても遅延
- インスタンスが予期せず終了します：
- RAID1-ディスクは使用可能ですが、一貫性がありません。データベースはそれ自体で不整合から回復する可能性があります
- bin-log-データにアクセスできる必要がありますが、最後のいくつかのイベントを確認する必要がある場合があります
- 誰かがrootとしてDROP DATABASEを実行します：
- RAID1-存在しないデータベースの完全なコピーが2つある
- bin-log-コマンドの直前までイベントを再生できるため、問題ありません。
そのため、実際にはRAID1はほとんど役に立たず、bin-logには時間がかかりすぎます。どちらも特定の状況ではメリットがあるかもしれませんが、バックアップのアイデアにはほど遠いものです。
スナップショット
スナップショットは差分であり、データを含む（そして圧縮されている）実際のブロックのみを保存することに注意してください。EBSボリュームとは異なり、20 GBのボリュームがあっても1 GBしか使用しない場合でも、「プロビジョニングされた」ストレージ（20 GB）に対して課金されます。スナップショットでは、使用した分だけが課金されます。スナップショット間でデータが変更されない場合、（理論的には）料金は発生しません。（スナップショットはPUTS / GETSおよび使用済みストレージに対して課金されます）。
余談ですが、アプリケーションデータ（データベースを含む）をルートボリューム（既にセットアップされている可能性がある）に保存しないことを強くお勧めします。利点の1つは、うまくいけば、ルートボリュームの変更が最小限になることです。つまり、スナップショットの頻度が少なくなる（または変更が最小限になる）ことで、コストと使いやすさが低下します。
また、古いスナップショットはいつでも削除できることにも言及しておく必要があります。それらは差分であっても、他のスナップショットには影響しません。ただし、スナップショットに割り当てられた各ブロックは、そのブロックを参照しているスナップショットがなくなるまで解放されません。
定期的なダンプの問題は、最初にダンプ間の時間（MySQLのbin-logを使用して対処される可能性があります）とリカバリの困難さです。大きなダンプをインポートして、bin-logからすべてのイベントを再生するには時間がかかります。また、ダンプを作成することには、パフォーマンスへの影響がないわけではありません。おそらく、そのようなダンプは、スナップショットよりもはるかに多くのストレージを必要とする可能性があります。データベースとスナップショットのためだけにEBSボリュームを設定することは、ほとんどの点で望ましいことです（つまり、スナップショットを取ると、パフォーマンスに多少の影響があります）。
スナップショットとEBSボリュームの優れた点は、他のインスタンスで使用できることです。インスタンスの起動に失敗した場合、ルートボリュームを別のインスタンスに接続して問題を診断および修正するか、データをコピーするだけで、ルートボリュームを数分のダウンタイムで切り替えることができます（インスタンスを停止し、デタッチします）ルートボリューム、新しいルートボリュームを接続し、インスタンスを起動します）。これと同じ考え方は、データを2番目のEBSボリュームに置く場合にも当てはまります。基本的に、カスタムAMIから新しいインスタンスを起動し、それに現在のEBSボリュームを接続するだけで、ダウンタイムを最小限に抑えることができます。
（同じサーバー（マスタースレーブ）にMySQLの2つのコピーをセットアップし、2つのEBSボリュームを使用してから、スレーブをシャットダウンしてそのスナップショットを取得することを主張できます（おそらくお勧めしません） EBSボリューム-ダウンタイムは発生せず、一貫性があります-しかし、パフォーマンスコストはそれほど価値がありません）。
AWSには自動スケーリングがあり、一定数のインスタンスを維持できます（その数が1の場合でも）。ただし、スナップショットからデプロイします。そのため、スナップショットが役に立たない場合、前提はあまり役に立ちません。 。
もう1つのポイント-単一のスナップショットから必要なだけインスタンスをデプロイできます（いつでも単一のインスタンスにのみ接続できるEBSボリュームとは異なります）。また、EBSボリュームはアベイラビリティーゾーン内での使用に制限されていますが、スナップショットはリージョン内で使用できます。
理想的には、スナップショットを使用して、サーバーがダウンした場合、最後のスナップショットを使用して新しいスナップショットを起動できます-特にルートボリュームをデータから分離している場合、悪いアップデートはダウンタイムを最小限に抑える必要があります（データが含まれるEBSボリュームを転送し、そのスナップショットをとって、不整合が原因で破損する可能性のあるものをすべて保持します。
補足として、Amazonは、最後のスナップショット以降に変更されたデータの量に応じて、EBSボリュームの失敗率が増加すると述べています。
最終的な推奨事項
- スナップショットを使用する-すばらしい-ダウンタイムを、それが引き起こすよりもはるかに削減する
- データとルートボリュームを分離し、データベースを独自のボリュームに配置し、必要に応じて更新前にスナップショットを作成します
- bin-logを使用して可能な限り「ホット」に保つ-これを（圧縮して）S3にアップロードする
- 実際にインスタンスからデータを取得していることを確認します（データがEBSボリュームにそのまま残っていても、ボリューム自体に一時的にアクセスできない場合があります）。
推奨読書：
（私はあまりにも多くのことを書いたと思いますが、十分に言っていません。