AWS EBS 快照。文件系統一致性真的需要嗎？
我一直在閱讀很多關於 aws ebs 的內容，而且很多人似乎鼓勵人們在快照*期間凍結文件系統。*但是，這篇亞馬遜文件有所不同：
在完成時，正在進行的快照不受對卷的持續讀取和寫入的影響。
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
為什麼很多人在快照期間凍結文件系統，而 aws 文件說快照不受 I/O 影響？
如果我的文件系統用於 ftp 怎麼辦？
如果我的文件系統用於數據庫怎麼辦？
**簡短的回答：**這實際上取決於您在實例上執行的應用程序類型。
**長答案：**基本上，對正在執行的機器進行非靜止快照類似於“拔掉電源插頭”——即：突然、立即、意外的崩潰。
在啟用 I/O 屏障的情況下執行時，現代日誌文件系統應該保持一致，儘管發生任何崩潰。這並不意味著記憶體中的數據不會失去；相反，送出的數據保證儲存在持久儲存（即：磁碟）上。
這確實適用於任何正確記錄的應用程序，尤其是符合 ACID 的數據庫（非包含列表：MSSQL、InnoDB、PostgreSQL、Oracle、IBM DB2、ecc）。同樣，這並不意味著突然斷電（或恢復的、未靜默的快照）不會導致任何數據失去；相反，這意味著當（可能是隱式的）COMMIT 返回時，任何相關數據都在穩定儲存中。
使用這樣的日誌應用程序，您並不嚴格需要停止文件系統。恢復快照後的第一次啟動，系統將回復其日誌（文件系統和數據庫）並達到一致狀態。
但是，有許多應用程序沒有正確記錄其更新，並且需要等效於 a
fsck才能返回到一致狀態。主要的例子是 MySQL+MyISAM：這個（非常常見的）數據庫引擎不符合 ACID，因為它的出色寫入速度是通過批處理不相關的 I/O 操作來實現的，而很少考慮正常 I/O 障礙。不正確的關閉（即：斷電、系統或 mysql 崩潰、未靜默的快照） MyISAM 數據庫在mysqlcheck/mysqlrepair執行 a 之前可能無法執行。建議在快照之前靜默文件系統的各種指南正是出於這個原因：一些“未準備好”的應用程序（閱讀：MyISAM）可能會因突然關閉和隨後的恢復而受到一定程度的損壞，需要進行一致性檢查。
**底線：**如果您使用啟用了 I/O 屏障（預設在 ext4 和 XFS 上）和符合 ACID 的數據庫的日誌文件系統，您應該可以安全地拍攝非靜默快照。在最壞的情況下，您可以在掛載快照時看到一些非致命錯誤/警告，但日誌回復將使系統處於一致狀態。但是，如果使用 MyISAM，最好在拍攝快照之前凍結/靜默您的文件系統。