我讀了很多關於 aws ebs 的文章，很多人似乎鼓勵人們凍結檔案系統期間快照。然而，亞馬遜的這篇文件卻有所不同：
在完成時，正在進行的快照不會受到正在進行的磁碟區讀取和寫入操作的影響。
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、ecc）。再說一次，這確實不是意味著突然斷電（或恢復的非靜默快照）不會導致任何資料遺失；相反，這意味著當（可能是隱式的）COMMIT 返回時，任何相關資料都在穩定儲存上。
使用此類日誌應用程序，您並不嚴格需要停頓檔案系統。恢復快照後的第一次啟動，系統將回復其日誌（檔案系統和資料庫）並達到一致的狀態。
然而，有許多應用程式可以不是正確記錄他們的更新，以及要求相當於afsck返回到一致狀態。主要的例子是MySQL+MyISAM：這個（非常常見的）資料庫引擎是不是符合 ACID，因為其出色的寫入速度是透過批次不相關的 I/O 操作而不考慮常規 I/O 屏障來實現的。不正確的關閉（即：斷電、系統或 mysql 崩潰、非靜默快照）在mysqlcheck/mysqlrepair執行 a 之前，MyISAM 資料庫可能無法操作。
各種指南建議在快照之前靜默檔案系統，正是出於以下原因：某些「未準備好的」應用程式（例如：MyISAM）可能會因突然關閉和隨後的復原而受到一定程度的損壞，需要進行一致性檢查。
底線：如果您使用啟用了 I/O 屏障的日誌檔案系統（ext4 和 XFS 上預設）和對於符合 ACID 的資料庫，您應該可以安全地拍攝非靜默快照。在最壞的情況下，您在安裝快照時可能會看到一些非致命錯誤/警告，但日誌回應將使系統處於一致狀態。但是，如果使用 MyISAM，最好在拍攝快照之前凍結/靜默檔案系統。
答案2
如果在系統運作時拍攝，Amazon 快照本身並不安全。如果您在建立快照之前關閉系統，它們是安全的。快取在作業系統緩衝區或應用程式緩衝區（例如資料庫）中的任何檔案系統資料都不會成為快照的一部分。這可能會導致無法恢復的損壞。
Linux 和 Windows 都有作業系統提供的機制來凍結系統（通知應用程式將資料刷新到磁碟）。一旦完成，就會執行解凍，以便繼續應用。在凍結和解凍之間，拍攝快照。注意：大多數應用程式不支援凍結/解凍，並且少數應用程式執行錯誤。仔細檢視您的供應商文件。
另一個重要事項是檢查應用程式儲存資料的位置。資料庫在最佳實踐設計下將其資料、日誌等儲存在不同的檔案系統上。這意味著您可能會在與另一個磁碟區的快照不同的時間啟動一個磁碟區的快照（可能需要作為一組來成功還原應用程式及其資料）。
關鍵是要了解崩潰一致快照與應用程式一致快照之間的差異。
這是一篇關於 EBS 快照的文章，解釋了這些差異。
[邁克爾評論後更新]
快照實現寫入時複製 (COW)。一旦啟動快照，就可以修改檔案系統。如果檔案系統寫入磁碟區塊，COW子系統會將原始區塊複製到其內部緩存，以便在快照期間可以修改檔案系統。
在快照期間沒有必要保持檔案系統凍結。在快照建立期間，將建立/複製必要的磁碟區資料結構，以便無需保持凍結。根據系統和記憶體中快取的資料量、作業系統和應用程式日誌的大小等，凍結/快照/解凍週期可能快至幾秒鐘。
這是一篇有關各種快照技術的文章，其中包括對寫入時複製的說明：