本文將描述 Azure 備份服務如何備份 Azure 虛擬機器 (Virtual Machines, VM)。
Azure 備份提供獨立且隔離的備份，以防止 VM 上意外的資料毀損。 備份會儲存於復原服務保存庫中，其具有內建的復原點管理功能。 設定及擴縮很簡單，備份已最佳化，而且您可以視需要輕鬆地還原。
在備份過程中，會建立快照集，並將資料傳輸至復原服務保存庫，其作業不會影響生產工作負載。 快照提供不同層級的一致性，如這裡所註明。 您可以在備份原則中，選擇使用代理程式型應用程式一致/檔案一致備份或無代理程式損毀一致備份。
Azure 備份也提供適用於資料庫工作負載的特殊方案，例如 SQL Server 和 SAP HANA，這些專案具備工作負載感知，提供 15 分鐘的復原點目標 (RPO)，並允許備份和還原個別資料庫。
您現在可以在 Azure 擴充區域中使用 Azure 備份來備份虛擬機（預覽）。 Azure 擴充區域 （預覽版）藉由將資源分散到 Azure 區域內的多個實體位置，以提供增強的復原能力。 這種方法可將關鍵基礎結構潛在失敗的影響降到最低。 藉由使用擴充區域，您的組織可以為其應用程式達到更高的可用性和容錯能力。 瞭解如何在 Azure 擴充區域中備份 Azure VM（預覽版）。
備份程序
以下是 Azure 備份完成 Azure VM 備份的方式：
針對已選取進行備份的 Azure VM，Azure 備份會根據您指定的備份排程開始備份工作。
如果您選擇應用程式或文件系統一致備份，則 VM 必須安裝備份延伸模組，以協調快照集程序。
如果您已選擇 崩潰一致性備份，則 VM 中不需要代理程式。
第一次備份時，如果 VM 正在執行，則會在 VM 上安裝備份延伸模組。
- 對於 Windows VM，會安裝 VMSnapshot 延伸模組 。
- 對於 Linux VM，會安裝 VMSnapshotLinux 延伸模組 。
針對執行中的 Windows VM，Azure 備份會與 Windows 磁碟區陰影複製服務 (VSS) 協調，以取得 VM 的應用程式一致快照集。
- 根據預設，備份服務會建立完整的 VSS 備份。
- 如果備份服務無法建立應用程式一致快照集，則會建立基礎儲存體的檔案一致性快照 (因為 VM 停止時，不會有任何應用程式寫入作業)。
針對 Linux VM，備份服務會建立檔案一致性備份。 若要建立應用程式一致快照集，必須手動自訂前/後指令碼。
針對 Windows VM，已安裝 Microsoft Visual C++ 2015 可轉散發套件 (x64) 14.40.33810.0 版、磁碟區陰影複製服務 (VSS) 的啟動設定會變更為 [自動]，並且會新增 Windows 服務 IaaSVmProvider。
備份服務建立快照之後，會將資料傳輸至保管庫。
- 備份是透過以平行方式備份每個 VM 磁碟來最佳化。
- 對於每個要備份的磁碟，Azure 備份會讀取磁碟上的區塊，並僅識別和傳輸自上次備份後有所變更 (差異) 的資料區塊。
- 快照集資料可能不會立即複製到保存庫。 在尖峰時間可能需要數小時。 針對每日備份原則，VM 的總備份時間會小於 24 小時。
對 Azure VM 備份進行加密
當您使用 Azure 備份來備份 Azure VM 時，VM 會透過儲存體服務加密 (SSE) 來執行待用加密。 Azure 備份也可備份使用 Azure 磁碟加密進行加密的 Azure VM。
| Encryption | Details | Support |
|---|---|---|
| SSE | 透過 SSE，Azure 儲存體會提供靜態加密，在儲存資料之前先自動將其加密。 Azure 儲存體會在擷取資料前進行資料解密。 Azure 備份支援具有兩種儲存體服務加密型別的 VM 備份： |
Azure 備份會在 Azure VM 的靜態加密上使用 SSE。 |
| Azure 磁碟加密 | Azure 磁碟加密會加密 Azure VM 的 OS 和資料磁碟。 Azure 磁碟加密會與 BitLocker 加密金鑰 (BEK) 整合，進而以祕密的形式在金鑰保存庫中受到保護。 Azure 磁碟加密也會與 Azure Key Vault 金鑰加密金鑰 (KEK) 整合。 |
Azure 備份支援僅使用 BEK 加密，或使用 BEK 搭配 KEK 加密的受控和非受控 Azure VM 的備份。 BEK 和 KEK 都已備份和加密。 由於 KEK 和 BEK 已備份，具有必要使用權限的使用者可以視需要將金鑰和秘密還原回金鑰保存庫。 這些使用者也可以對於已加密的 VM 進行復原。 未經授權的使用者或 Azure 都無法讀取已加密的金鑰和祕密。 |
針對受控和非受控 Azure VM，備份同時支援僅使用 BEK 加密的 VM，以及使用 BEK 搭配 KEK 加密的 VM。
已備份的 BEK (秘密) 和 KEK (金鑰) 都會加密。 當授權使用者將這些項目還原至金鑰保存庫時，才能讀取和使用這些項目。 未經授權的使用者和 Azure 都無法讀取或使用備份金鑰或祕密。
系統也會備份 BEK。 因此，如果遺失 BEK，授權使用者可以將 BEK 還原至金鑰保存庫，並復原已加密的 VM。 只有具備適當使用權限等級的使用者，才有權備份和還原已加密的 VM，以及金鑰和秘密。
快照建立
Azure 備份會根據備份排程來建立快照集。
如果您選擇進行應用程式或檔案系統一致性備份，則 VM 必須安裝備份擴充套件，以協調快照處理。 對於無代理程式多磁碟損毀一致備份 (部分內容可能是機器或 AI 翻譯)，快照集不需要 VM 代理程式。
Windows 虛擬機器： 針對 Windows VM，備份服務會與 VSS 協調，以建立 VM 磁碟的應用程式一致快照集。 根據預設，Azure 備份會進行完整的 VSS 備份 (其會在備份時截斷應用程式的記錄，例如 SQL Server，以取得應用維度層級一致的備份)。 如果您使用的是 Azure VM 備份上的 SQL Server 資料庫，則可以修改此設定，將其變更為進行 VSS 複本備份 (以保留記錄)。 如需詳細資訊，請參閱這篇文章。
Linux 虛擬機器： 若要建立 Linux VM 的應用程式一致快照集，請使用 Linux 前置指令碼和後置指令碼架構來撰寫您自己的自訂指令碼，以確保一致性。
- Azure 備份只會叫用您所撰寫的前/後指令碼。
- 如果前置指令碼和後置指令碼順利執行，Azure 備份會將復原點標記為應用程式一致。 不過，當使用自訂指令碼時，您最終必須負責應用程式一致性。
- 深入瞭解 如何設定指令碼。
Note
快照程序會從呼叫備份擴充模組開始（以代理程式為基礎），使用適用於 Windows 的 VSS 工具或適用於 Linux 的 freeze 工具，以確保數據一致性。 當系統達到一致性時，「還原點集合」會監控該延伸模組並啟動快照的建立。 之後，系統會更新包含還原點路徑與提交詳細資料的中繼資料，以完成備份並準備復原。
快照一致性
下表說明不同型別的快照集一致性：
| Snapshot | Details | Recovery | Consideration |
|---|---|---|---|
| Application-consistent | 這是 VM 備份原則中的預設設定。 符合應用程式一致性的備份會擷取記憶體內容和待處理的 I/O 作業。 應用程式一致快照集會使用 VSS 寫入器 (或 Linux 的前置/後置指令碼)，以先確保應用程式資料的一致性，再進行備份。 | 使用應用程式一致快照集復原 VM 時，VM 會啟動。 沒有任何資料損毀或遺失。 應用程式會以一致的狀態開始。 | Windows：所有 VSS 寫入器都已成功 Linux：前置/後置指令碼已設定並成功 |
| 檔案系統一致 | 這是 VM 備份原則中的預設設定。 檔案系統一致備份會同時建立所有檔案的快照集以提供一致性。 |
當您使用檔案系統一致性快照復原 VM 時，VM 會啟動。 沒有任何資料損毀或遺失。 應用程式必須實作自己的「修正」機制，以確保還原的資料一致。 | Windows：部分 VSS 編寫器失敗 Linux：預設 (如果前置/後置指令碼未設定或失敗) |
| Crash-consistent | 損毀一致快照集是 VM 備份原則中的加入設定。 如果 VM 未在備份期間執行，且應用程式/檔案一致備份失敗，Azure 備份也會建立損毀一致備份。 只會擷取並備份備份作業時磁碟上已存在的數據;讀取/寫入主機快取中的數據不會擷取。 |
從 VM 開機流程開始，接著進行磁碟檢查以修正損毀錯誤。 在損毀之前未傳送至磁碟的任何記憶體內部資料或寫入作業都會遺失。 應用程式會實作本身的資料驗證。 例如，資料庫應用程式可以使用其交易記錄來進行驗證。 如果交易記錄中有不存在於資料庫中的項目，則資料庫軟體會執行交易復原，直到資料變成一致為止。 | 當您選擇使用應用程式/檔案系統備份，且 VM 處於關機狀態 (已停止/已解除分配)，以及在重試快照集的情況下。 您已選擇使用無代理程式損毀一致備份 |
Note
如果布建狀態為 成功，Azure 備份會採用檔案系統一致的備份。 如果佈建狀態為 無法使用 或 失敗，則會進行損毀一致的備份。 如果布建狀態是建立或刪除，則表示 Azure 備份正在重試作業。
備份和還原考量
| Consideration | Details |
|---|---|
| Disk | VM 磁碟會以平行方式進行備份。 例如，如果 VM 有四個磁碟，備份服務便會嘗試平行備份所有四個磁碟。 備份是累進的 (僅備份已變更的資料)。 |
| Scheduling | 若要減少備份流量，請在當天的不同時間備份不同的 VM，並確定時間不重疊。 同時間備份多個 VM 會導致流量壅塞。 |
| 準備備份 | 請記住準備備份所需的時間。 準備時間可能包括安裝或更新備份擴充套件，並根據備份排程觸發快照。 |
| 資料傳輸 | 請考量 Azure 備份識別自上次備份以來所增變更的所需時間。 在增量備份中，Azure 備份會藉由計算區塊的總和檢查碼，以判斷有哪些變更。 如果區塊已變更，則會將其標示為待傳輸至保存庫。 服務會分析已識別到的區塊，以嘗試進一步減少要傳輸的資料數量。 評估所有變更區塊完成後，Azure 備份 將變更傳送至保存庫。 擷取快照集和將其複製到保存庫之間可能會有延遲。 尖峰時段時，將快照集傳輸至保存庫可能需要長達 8 小時的時間。 若每日備份，則 VM 的備份時間會小於 24 小時。 |
| 初始備份 | 增量備份的總備份時間小於 24 小時，這可能不是第一次備份的情況。 初始備份所需的時間取決於資料的大小，以及處理備份的時間。 |
| 還原佇列 | Azure 備份會同時處理來自多個儲存體帳戶的還原作業，並將還原要求放入佇列中。 |
| 還原副本 | 在還原流程期間，資料會從保存庫複製到儲存體帳戶。 總還原時數取決於每秒的輸入/輸出作業 (IOPS) 以及儲存體帳戶的輸送量。 若要減少複製時間，請選取沒有其他應用程式寫入或讀取之負載的儲存體帳戶。 |
Note
Azure 備份現在可讓您使用強化原則每天多次備份 Azure VM。 透過這項功能，您也可以定義備份作業觸發的持續時間，並在頻繁更新 Azure 虛擬機器時將備份排程與工作時間保持一致。 深入瞭解。
備份效能
可能會影響備份總時數的常見案例：
- 將新的磁碟新增至受保護的 Azure VM：如果 VM 正在進行增量備份，且新增了新的磁碟，備份時數也會增加。 因為新磁碟的初始複寫以及現有磁碟的差異複寫，所以備份時間總計可能會持續超過 24 小時。
- 碎片磁碟： 當磁碟變更是連續的時，備份作業會更快。 如果變更分散在磁碟中，則備份會必較慢。
- 磁碟流失： 如果正在進行增量備份的受保護磁碟的每日變換超過 200 GB，則備份可能需要很長的時間 （超過八小時） 才能完成。
- 備份版本： 最新版本的備份 （稱為即時還原版本） 使用比總和檢查碼比較更優化的流程來識別變更。 但是，如果您使用「立即還原」並已刪除備份快照集，則備份會切換至總和檢查碼比較流程。 在此情況下，備份作業將超過 24 小時 (或失敗)。
恢復性能
可能會影響還原總時數的常見案例：
- 總還原時間取決於每秒的輸入/輸出作業 (IOPS)，以及儲存體帳戶的輸送量。
- 若目標儲存體帳戶與其他應用程式讀取及寫入作業一起載入，則總還原時間可能會受到影響。 若要改善還原作業，請選取未與其他應用程式資料一起載入的儲存體帳戶。
最佳做法
當您設定 VM 備份時，我們建議下列做法：
- 修改原則中設定的預設排程時間。 例如，如果原則中的預設時間是凌晨 12:00，請增加幾分鐘，以最佳化資源的使用。
- 如果您要從單一保存庫還原 VM，我們強烈建議您使用不同的一般用途 v2 儲存體帳戶 (部分內容可能是機器或 AI 翻譯)，以確保目標儲存體帳戶不會受到節流影響。 例如，每個 VM 都需要有不同的儲存體帳戶。 例如，若還原 10 個 VM，請使用 10 個不同的儲存體帳戶。
- 對於使用進階儲存體搭配即時還原的 VM 備份，建議您配置總配置儲存空間總計的 50% 可用空間，這 僅 適用於第一次備份。 第一次備份完成之後，後續備份不需要這 50% 的可用空間
- 對每一儲存體帳戶的磁碟數目限制，與在基礎結構即服務 (IaaS) VM 上執行的應用程式對磁碟的存取次數多寡有關。 一般做法是，如果單一儲存體帳戶上有 5 到 10 個磁碟或更多磁碟，請將部分磁碟移至個別的儲存體帳戶來平衡負載。
- 若要使用 PowerShell 還原具有受控磁碟的 VM，請提供其他參數 TargetResourceGroupName 來指定受控磁碟要還原至的資源群組， 請深入瞭解這裡。
備份成本
使用 Azure 備份所備份的 Azure VM 適用 Azure 備份定價。
第一次成功完成備份後才會開始計費。 儲存體和受保護的 VM 也會在此同時開始計費。 只要 VM 有任何備份資料儲存在保存庫，就會繼續計費。 如果您停止保護 VM，但 VM 的備份資料仍在保存庫中，則還是會繼續計費。
只有在停止保護且刪除全部備份資料時，才會對指定的虛擬機器停止計費。 當保護停止且沒有任何作用中的備份作業時，最後一個成功 VM 備份的大小會成為每月帳單所使用的受保護執行個體大小。
如果您選擇了代理程式型應用程式一致或檔案系統一致備份，則受保護的執行個體大小計算會以 VM 的實際大小為基礎。 VM 的大小以 VM 中所有資料的總和計算，其不包括暫存儲存體。 價格根據儲存在資料磁碟上的實際資料進行結算，而不是每個連接至 VM 的資料磁碟所支援的儲存容量上限。
Note
無代理程式多磁碟損毀一致 VM 備份功能已正式推出。 此版本包含計費變更;請參閱 定價詳細資訊。
同樣地，備份儲存體帳單也是根據 Azure 備份所儲存的資料計費，也就是每個復原點所儲存的實際資料總和。
例如，A2 標準大小的 VM 擁有兩個額外資料磁碟，每個儲存容量上限為 32 TB。 下表顯示上述每個磁碟實際儲存的資料：
| Disk | 最大尺寸 | 存在的實際資料 |
|---|---|---|
| 作業系統磁碟 | 32 TB | 17 GB |
| 本機/暫存磁碟 | 135 GB | 5 GB (未包含備份) |
| 資料磁碟 1 | 32 TB | 30 GB |
| 資料磁碟 2 | 32 TB | 0 GB |
在此案例中，VM 的實際容量為 17 GB + 30 GB + 0 GB = 47 GB。 此受保護執行個體的容量大小 (47 GB) 會成為每月計費的依據。 當 VM 的資料量增加時，作為計費依據的受保護執行個體大小也會隨之變更。