Azure VM 備份的概觀

本文將描述 Azure 備份服務如何備份 Azure 虛擬機器 (Virtual Machines, VM)。

Azure 備份提供獨立且隔離的備份，以防止 VM 上意外的資料毀損。 備份會儲存於復原服務保存庫中，其具有內建的復原點管理功能。 設定及擴縮很簡單，備份已最佳化，而且您可以視需要輕鬆地還原。

在備份過程中，會建立快照集，並將資料傳輸至復原服務保存庫，其作業不會影響生產工作負載。 快照集會提供不同維度層級的一致性，如此處所述。 您可以選擇在備份原則中，選擇代理程式型應用程式一致/檔案一致備份或無代理程式損毀一致備份。

Azure 備份也有適用於資料庫工作負載的特製化供應項目，例如工作負載感知的 SQL Server 和 SAP Hana、提供 15 分鐘的 RPO (復原點目標)，並允許個別資料庫所運作的備份與還原。

備份程序

以下是 Azure 備份完成 Azure VM 備份的方式：

1. 針對已選取進行備份的 Azure VM，Azure 備份會根據您指定的備份排程開始備份工作。

2. 如果您選擇應用程式或文件系統一致備份，則 VM 必須安裝備份延伸模組，以協調快照集程序。

   如果您選擇損毀一致備份，則 VM 中不需要代理程式。

3. 第一次備份時，如果 VM 正在執行，則會在 VM 上安裝備份延伸模組。

   • 如果是 Windows VM，會安裝 VMSnapshot 延伸模組。
   • 如果是 Linux VM，會安裝 VMSnapshot Linux 延伸模組。

4. 針對執行中的 Windows VM，Azure 備份會與 Windows 磁碟區陰影複製服務 (VSS) 協調，以取得 VM 的應用程式一致快照集。

   • 根據預設，備份服務會建立完整的 VSS 備份。
   • 如果備份服務無法建立應用程式一致快照集，則會建立基礎儲存體的檔案一致性快照 (因為 VM 停止時，不會有任何應用程式寫入作業)。

5. 針對 Linux VM，備份服務會建立檔案一致性備份。 若要建立應用程式一致快照集，必須手動自訂前/後指令碼。

6. 針對 Windows VM，已安裝 Microsoft Visual C++ 2013 可轉散發套件 (x64) 12.0.40660 版、啟動磁碟區陰影複製服務 (VSS) 會變更為自動，並且會新增 Windows 服務 IaaSVmProvider。

7. 備份服務建立快照集之後，會將資料傳輸至保存庫。

   • 備份是透過以平行方式備份每個 VM 磁碟來最佳化。
   • 針對每個要備份的磁碟，Azure 備份會讀取磁碟上的區塊，並只識別並傳輸自上次備份之後變更的資料區塊 (差異)。
   • 快照集資料可能不會立即複製到保存庫。 在尖峰時間可能需要數小時的時間。 針對每日備份原則，VM 的總備份時間會小於 24 小時。

對 Azure VM 備份進行加密

當您使用 Azure 備份來備份 Azure VM 時，VM 會透過儲存體服務加密 (SSE) 來執行待用加密。 Azure 備份也可備份使用 Azure 磁碟加密進行加密的 Azure VM。

加密	詳細資料	支援
SSE	透過 SSE，Azure 儲存體會提供靜態加密，在儲存資料之前先自動將其加密。 Azure 儲存體會在擷取資料前進行資料解密。 Azure 備份支援具有兩種儲存體服務加密型別的 VM 備份： 搭配平台待控金鑰的儲存體服務加密 (SSE)：此預設加密針對 VM 中的所有磁碟。 請在此參閱更多資訊。 搭配客戶自控金鑰的 SSE。 您可以使用 CMK 管理用於磁碟加密的金鑰。 請在此參閱更多資訊。	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 都無法讀取已加密的金鑰和祕密。

備份僅支援與 BEK 或 BEK 搭配 KEK 加密運作的受控和非受控 Azure VM。

已備份的 BEK (秘密) 和 KEK (金鑰) 都會加密。 當授權使用者將這些項目還原至金鑰保存庫時，才能讀取和使用這些項目。 未經授權的使用者和 Azure 都無法讀取或使用備份金鑰或祕密。

系統也會備份 BEK。 因此，如果遺失 BEK，授權使用者可以將 BEK 還原至金鑰保存庫，並復原已加密的 VM。 只有具備適當使用權限等級的使用者，才有權備份和還原已加密的 VM，以及金鑰和秘密。

快照集建立

Azure 備份會根據備份排程來建立快照集。

如果您選擇應用程式或文件系統一致備份，VM 必須安裝備份延伸模組，以協調快照集程式。 針對 無代理程式多磁碟損毀一致 備份，快照集不需要 VM 代理程式。

• Windows VM： 針對 Windows VM，備份服務會與磁碟區陰影複製服務 (VSS) 進行協調，以建立 VM 磁碟的應用程式一致快照集。 根據預設，Azure 備份會進行完整的 VSS 備份 (其會在備份時截斷應用程式的記錄，例如 SQL Server，以取得應用維度層級一致的備份)。 如果您使用的是 Azure VM 備份上的 SQL Server 資料庫，則可以修改此設定，將其變更為進行 VSS 複本備份 (以保留記錄)。 如需詳細資訊，請參閱這篇文章。

• Linux VM：若要建立 Linux VM 的應用程式一致快照集，請使用 Linux 前指令碼和後指令碼架構撰寫您自己的自訂指令碼，以確保一致性。

  • Azure 備份只會叫用您所撰寫的前/後指令碼。
  • 如果前置指令碼和後置指令碼順利執行，Azure 備份會將復原點標記為應用程式一致。 不過，當使用自訂指令碼時，您最終必須負責應用程式一致性。
  • 深入了解如何設定指令碼。

快照集一致性

下表說明不同型別的快照集一致性：

快照式	詳細資料	復原	考量
應用程式一致	這是 VM 備份原則中的預設設定。 應用程式一致的備份會擷取記憶體內容和擱置 I/O 作業。 應用程式一致快照會使用 VSS 寫入器 (或 Linux 的前置或後置指令碼)，以先確保應用程式資料的一致性，再進行備份。	使用應用程式一致快照集復原虛擬機器 (VM) 時，VM 會啟動。 沒有任何資料損毀或遺失。 應用程式會以一致的狀態開始。	Windows：所有 VSS 寫入器都已成功 Linux：前置/後置指令碼已設定並成功
檔案系統一致	這是 VM 備份原則中的預設設定。 檔案系統一致備份會同時建立所有檔案的快照集以提供一致性。	當您使用檔案系統一致快照集復原虛擬機器 (VM) 時，VM 會啟動。 沒有任何資料損毀或遺失。 應用程式必須實作自己的「修正」機制，以確保還原的資料一致。	Windows：部分 VSS 寫入器失敗 Linux：預設 (如果前置/後置指令碼未設定或失敗)
絕對一致	損毀一致快照集是 VM 備份原則中的選擇加入設定。 如果 VM 未在備份期間執行，且應用程式/檔案一致備份失敗，則 Azure 備份 也會採取當機一致備份。 只會擷取並備份備份作業時磁碟上已存在的數據;讀取/寫入主機快取中的數據不會擷取。	從 VM 開機流程開始，接著進行磁碟檢查以修正損毀錯誤。 在損毀之前未傳送至磁碟的任何記憶體內部資料或寫入作業都會遺失。 應用程式會實作本身的資料驗證。 例如，資料庫應用程式可以使用其交易記錄來進行驗證。 如果交易記錄中有不存在於資料庫中的項目，則資料庫軟體會執行交易復原，直到資料變成一致為止。	當您選擇應用程式/檔案系統備份，且 VM 處於關機狀態（已停止/已解除分配）以及重試快照集時。 您已選擇無代理程式損毀一致備份

注意

若佈建狀態為成功，Azure 備份會採用檔案系統一致備份。 若佈建狀態為無法使用或失敗，則會採用損毀一致的備份。 若佈建狀態為正在進行建立或正在進行刪除，這表示 Azure 備份正在重試作業。

備份和還原考量

考量	詳細資料
磁碟	VM 磁碟會以平行方式進行備份。 例如，如果 VM 有四個磁碟，備份服務便會嘗試平行備份所有四個磁碟。 備份是累進的 (僅備份已變更的資料)。
正在排程	若要減少備份流量，請在當天的不同時間備份不同的 VM，並確定時間不重疊。 同時間備份多個 VM 會導致流量壅塞。
準備備份	請記住準備備份所需的時間。 準備時間可能包括安裝或更新備份延伸模組，並根據備份排程觸發快照集。
資料傳輸	考慮 Azure 備份識別上次備份以來所增變更的所需時間。 在增量備份中，Azure 備份會藉由計算區塊的總和檢查碼，以判斷有哪些變更。 如果區塊已變更，則會將其標示為傳輸至保存庫。 服務會分析已識別到的區塊，以嘗試進一步減少要傳輸的資料數量。 評估所有已變更區塊之後，Azure 備份 會將變更傳送至保存庫。 擷取快照集和將其複製到保存庫之間可能會有延遲。 尖峰時段時，將快照集傳輸至保存庫可能需要長達 8 小時的時間。 若每日備份，則 VM 的備份時間會小於 24 小時。
初始備份	增量備份的總備份時間小於 24 小時，這可能不是第一次備份的情況。 初始備份所需的時間取決於資料的大小，以及處理備份的時間。
還原佇列	Azure 備份會同時處理來自多個儲存體帳戶的還原作業，並將還原要求放入佇列中。
還原複本	進行還原時，資料會從保存庫複製到儲存體帳戶。 總還原時數取決於每秒的輸入/輸出作業 (IOPS) 以及儲存體帳戶的輸送量。 若要減少複製時間，請選取未使用其他應用程式寫入或讀取載入的儲存體帳戶。

注意

Azure 備份現在可讓您使用強化原則每天多次備份 Azure VM。 透過這項功能，您也可以定義備份作業觸發的持續時間，並在頻繁更新 Azure 虛擬機器時將備份排程與工作時間保持一致。 深入了解。

備份效能

可能會影響備份總時數的常見案例：

• 將新的磁碟新增至受保護的 Azure VM：如果 VM 正在進行增量備份，且新增了新的磁碟，備份時數也會增加。 因為新磁碟的初始複寫以及現有磁碟的差異複寫，所以備份時間總計可能會持續超過 24 小時。
• 分割磁碟： 當磁碟變更為連續進行的狀態，備份作業會更快速。 如果變更分散在磁碟中，則備份會必較慢。
• 磁碟流失：如果正在進行增量備份的受保護磁碟每天有 200 GB 以上的變換，則備份可能需要很長的時間 (超過八個小時) 來完成。
• 備份版本：如果您使用最新版的備份 (稱為「立即還原」版本)，該備份會使用更為最佳化的流程來比對變更，而不是使用總和檢查碼。 但是，如果您使用「立即還原」並已刪除備份快照集，則備份會切換至總和檢查碼比較流程。 在此情況下，備份作業將超過 24 小時 (或失敗)。

還原效能

可能會影響還原總時數的常見案例：

• 總還原時間取決於每秒的輸入/輸出作業 (IOPS)，以及儲存體帳戶的輸送量。
• 若目標儲存體帳戶與其他應用程式讀取及寫入作業一起載入，則總還原時間可能會受到影響。 若要改善還原作業，請選取未與其他應用程式資料一起載入的儲存體帳戶。

最佳作法

當您設定 VM 備份時，我們建議下列做法：

• 修改原則中設定的預設排程時間。 例如，如果原則中的預設時間是凌晨 12:00，請增加幾分鐘，以最佳化資源的使用。
• 如果您要從單一保存庫還原 VM，我們強烈建議您使用不同的一般用途 v2 儲存體帳戶，以確保目標儲存體帳戶不會受到節流影響。 例如，每個 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 的資料磁碟所支援的儲存容量上限。

注意

針對 無代理程式當機時一致的備份，您目前會在預覽期間針對每個 VM 收取 0.5 個受保護實例 （PI） 的費用。

同樣地，備份儲存體帳單也是根據 Azure 備份所儲存的資料計費，也就是每個復原點所儲存的實際資料總和。

例如，A2 標準大小的 VM 擁有兩個額外資料磁碟，每個儲存容量上限為 32 TB。 下表顯示上述每個磁碟實際儲存的資料：

磁碟	大小上限	實際儲存的資料
作業系統磁碟	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 的資料量增加時，作為計費依據的受保護執行個體大小也會隨之變更。

下一步

• 為 Azure VM 備份預作準備。