私はAWS EBSについてたくさん読んできましたが、多くの人がファイルシステムをフリーズすることを推奨しているようです。その間スナップショット。ただし、この Amazon ドキュメントはこれに異論を唱えています。
完了するまで、進行中のスナップショットはボリュームへの進行中の読み取りおよび書き込みの影響を受けません。
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
AWS のドキュメントではスナップショットは I/O の影響を受けないと記載されているのに、なぜ多くの人がスナップショット中にファイルシステムをフリーズするのでしょうか?
ファイルシステムが ftp に使用されている場合はどうなりますか?
ファイルシステムがデータベースに使用される場合はどうなりますか?
答え1
短い答え：それは、インスタンス上で実行しているアプリケーションの種類によって異なります。
長い答え:基本的に、実行中のマシンの静止していないスナップショットを撮ることは、「電源プラグを抜く」こと、つまり突然の、即時の、予期しないクラッシュに似ています。
I/Oバリアを有効にして実行する場合、最新のジャーナリングファイルシステムはクラッシュがあっても一貫性を保つはずです。ないメモリ内のデータは失われず、コミットされたデータは保証された永続的なストレージ（ディスクなど）に保存されます。
これは、適切にジャーナル化されたアプリケーション、特にACID準拠のデータベース（MSSQL、InnoDB、PostgreSQL、Oracle、IBM DB2など）に当てはまります。繰り返しますが、これはない突然の電源喪失 (または復元された静止していないスナップショット) によってデータが失われることはありません。むしろ、(おそらく暗黙の) COMMIT が返されたときに、関連するデータはすべて安定したストレージ上にあることを意味します。
このようなジャーナル化されたアプリケーションでは、厳密にはファイルシステムを静止させる必要はありません。スナップショットを復元した後の最初の起動時に、システムはジャーナル (ファイルシステムとデータベース) に応答し、一貫性のある状態になります。
しかし、多くのアプリケーションではない更新を適切に記録し、必要とする一貫性のある状態に戻すことと同等ですfsck。主な例はMySQL+MyISAMです。この（非常に一般的な）データベースエンジンはないACID 準拠。通常の I/O バリアをほとんど考慮せずに無関係な I/O 操作をバッチ処理することで、優れた書き込み速度が実現されます。不適切にシャットダウンされた (電源喪失、システムまたは MySQL のクラッシュ、静止していないスナップショットなど) MyISAM データベースは、がmysqlcheck/mysqlrepair実行されるまでは動作不能になる可能性があります。
スナップショットの前にファイルシステムを静止することを推奨するさまざまなガイドは、まさにこの理由でそれを行います。つまり、一部の「準備されていない」アプリケーション (MyISAM など) は、突然のシャットダウンとその後の復元によって多少損傷を受ける可能性があり、一貫性チェックが必要になるからです。
結論:I/Oバリアを有効にしたジャーナルファイルシステムを使用する場合（ext4およびXFSのデフォルト）そしてACID 準拠のデータベースであれば、静止していないスナップショットを安全に取得できるはずです。最悪の場合、スナップショットをマウントするときに致命的ではないエラー/警告が表示されることがありますが、ジャーナル応答によってシステムは一貫した状態になります。ただし、MyISAM を使用する場合は、スナップショットを取得する前にファイルシステムをフリーズ/静止させることをお勧めします。
答え2
Amazon スナップショット自体は、システムの実行中に取得すると安全ではありません。スナップショットを作成する前にシステムをシャットダウンすれば安全です。オペレーティングシステムのバッファまたはアプリケーションのバッファ (データベースなど) にキャッシュされているファイルシステムのデータは、スナップショットの一部にはなりません。これにより、回復不可能な破損が発生する可能性があります。
Linux と Windows の両方に、システムをフリーズする (アプリケーションにデータをディスクにフラッシュするように通知する) OS 提供のメカニズムがあります。これが完了すると、解凍が実行され、アプリケーションが続行できるようになります。フリーズと解凍の間に、スナップショットが取得されます。注: ほとんどのアプリケーションはフリーズ/解凍をサポートしておらず、いくつかのアプリケーションはそれを間違って実装しています。ベンダーのドキュメントを注意深く確認してください。
もう 1 つの重要な点は、アプリケーションがデータを保存している場所を確認することです。データベースは、ベスト プラクティスの設計では、データやログなどを異なるファイル システムに保存します。つまり、あるボリュームのスナップショットを、別のボリュームのスナップショットとは異なる時間に開始している可能性があります (アプリケーションとそのデータを正常に復元するには、セットで必要になる場合があります)。
重要なのは、クラッシュ整合性スナップショットとアプリケーション整合性スナップショットの違いを理解することです。
EBS スナップショットの違いについて説明した記事がこちらにあります。
EBS スナップショット: クラッシュ整合性とアプリケーション整合性
[マイケルのコメント後の更新]
スナップショットは、Copy-on-Write (COW) を実装します。スナップショットが開始されると、ファイル システムを変更できます。ファイル システムがディスク ブロックに書き込むと、COW サブシステムは元のブロックを内部キャッシュにコピーし、スナップショット中にファイル システムを変更できるようにします。
スナップショット中にファイル システムをフリーズしたままにする必要はありません。スナップショットの作成中に必要なボリューム データ構造が作成/コピーされるため、フリーズを保持する必要がありません。システム、メモリにキャッシュされるデータの量、OS およびアプリケーション ジャーナルのサイズなどに応じて、フリーズ/スナップショット/解凍サイクルは数秒ほどで完了する場合があります。
以下に、Copy-on-Write の説明を含むさまざまなスナップショット テクノロジに関する記事を示します。