AWS EC2 實例 (Windows Server 2008)：每日 EBS 快照，無需停機
TL;TR
我需要在不停機的情況下備份 AWS EBS 卷。
詳細介紹
我在 Amazon AWS 上有一個“Windows Server 2008”實例“ EC2 ” ，其中有兩個EBS 捲和系統驅動程序。
C:``D:在
C:驅動程序上執行作業系統，在D:驅動程序上執行網路服務，我只需要備份D:。Web 服務是一個 Delphi SOAP 應用程序，用於根據請求下載一些文件，例如：
http://www.example.com/dir/service.dll?filename=foo.zip（在這種情況下，Web 服務會使用
foo.zip位於 中的文件進行響應D:\dir\files\）。對於每個請求，此應用程序都會將一些文件（會話文件和日誌文件）寫入
D:\dir\temp\. 這是一個問題，因為從AWS docs對使用中的捲進行快照是不安全的：您可以拍攝正在使用的附加卷的快照。但是，快照僅擷取在發出快照命令時已寫入您的 Amazon EBS 卷的數據。如果您可以暫停對卷的任何文件寫入足夠長的時間以拍攝快照，那麼您的快照應該是完整的。
我的想法是在我的網路服務中實現只讀模式，基於目錄中文件的存在。
procedure onRequest(Sender: TObject; Request: TWebRequest; Response: TWebResponse; var Handled: Boolean); begin FReadOnlyMode := FileExists('D:\dir\flag\read_only_mode.txt'); // ... other code在每個請求中，服務檢查文件是否存在，如果存在，伺服器進入只讀模式並且不寫入任何內容（沒有日誌文件，沒有會話文件。）。
備份策略基於 Windows cron 任務中的每晚執行一個批處理文件，例如。
backup.bat：:: 1. stop all web service writes operation echo.>D:\dir\flag\read_only_mode.txt :: 2. Use sync.exe for flush all data to disk D sync.exe d :: 3. Use Amazon CLI for snapshot the volume: aws ec2 create-snapshot --volume-id vol-XXXXXXXXXX --description "D snapshot." :: 4. Remove `read_only_mode` flag: del /F /Q D:\dir\flag\read_only_mode.txt（有關Windows Sync和Amazon CLI的更多資訊）
問題是：我的 EBS 快照會保持一致嗎？
我是 AWS 的新手，任何其他建議都值得讚賞！
對不起，我的英語不好
理論上，為了使您的 EBS 快照保持一致，您將需要在開始創建快照時不執行任何有狀態的應用程序。可悲的是，Windows 本身可以被認為是有狀態的，這可能會造成一些混亂，尤其是在您使用寫入記憶體的情況下。
這有幾個有趣但令人困惑的部分：
- 快照過程的“快照”部分會立即完成，您無需在快照掛起的整個過程中禁用寫入。大卷可能需要數小時才能完成快照，但這只是快照的備份或複制部分。只要亞馬遜在此過程中沒有斷電，最終的快照將是快照發生時磁碟上的數據。
- 快照是非同步拍攝的。所以在創建快照時命令行工具不應該阻塞，它的返回與快照狀態無關。
然而，考慮到所有因素，這通常不會導致重大問題。一致性問題通常很小。吸引人們的主要問題是記憶體問題。如果您在作業系統或應用程序中啟用了磁碟寫入記憶體（預設情況下在 Windows 中啟用），僅僅因為您認為您已將文件寫入磁碟，並不意味著文件已完成寫入。
引起人們注意的另一個主要問題是交易。例如，如果您創建一個允許上傳文件的網站，您的問題將與整個過程中發生的快照有關。一個常見的例子是現有的數據庫記錄說文件“1234”已上傳到“d:/files/1234”，但文件不存在，因為在快照發生時文件尚未完成複製到該位置，但是已送出的數據庫記錄。
人們感到困惑的一件事是這種情況下的一致性一詞，它並不是指恢復快照的能力。您將始終能夠從快照創建卷，問題是您的應用程序是否能夠了解它之後的狀態。
例如，如果您在 Windows 更新過程中拍攝 Windows 系統驅動器的 EBS 快照，您最終會得到一些文件更新而一些文件沒有。幸運的是，Windows 了解更新過程，應該會注意到更新失敗並在啟動時進行處理。
如果您可以編寫應用程序而不用擔心文件部分寫入磁碟（您是否關心日誌條目是否失去？）您不需要使用只讀模式。通過文件上傳解決此問題的一種方法是讓上傳文件夾與最終位置不同（在同一磁碟上）。文件上傳完成並成功寫入後，將文件移動到其靜止位置。移動應該作為文件“重命名”而不是逐字節複製執行，並且立即發生。如果文件從未到達其最終位置，則說明上傳失敗。