Azure VM 備份的概觀
本文說明 Azure 備份 服務如何備份 Azure 虛擬機（VM）。
Azure 備份提供獨立且隔離的備份，以防止 VM 上意外的資料毀損。 備份會儲存於復原服務保存庫中，其具有內建的復原點管理功能。 設定及擴縮很簡單，備份已最佳化，而且您可以視需要輕鬆地還原。
在備份過程中，會 擷取快照集，並將數據傳輸到復原服務保存庫，而不會影響生產工作負載。 快照集提供不同層級的一致性，如這裡所述。 您可以選擇在備份原則中，選擇代理程式型應用程式一致/檔案一致備份或無代理程式損毀一致備份。
Azure 備份 也有資料庫工作負載的特製化供應專案，例如工作負載感知的 SQL Server 和 SAP HANA 提供 15 分鐘的 RPO（恢復點目標），並允許備份和還原個別資料庫。
備份程序
以下是 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++ 2013 可轉散發套件 （x64） 12.0.40660 版、磁碟區陰影複製服務 （VSS） 的啟動會變更為 自動，並新增 Windows 服務 IaaSVmProvider 。
備份服務建立快照集之後，會將資料傳輸至保存庫。
- 備份是透過以平行方式備份每個 VM 磁碟來最佳化。
- 針對每個要備份的磁碟，Azure 備份會讀取磁碟上的區塊，並只識別並傳輸自上次備份之後變更的資料區塊 (差異)。
- 快照集資料可能不會立即複製到保存庫。 在尖峰時間可能需要數小時的時間。 針對每日備份原則，VM 的總備份時間會小於 24 小時。
Azure VM 備份的加密
當您使用 Azure 備份 備份 Azure VM 時，VM 會以 儲存體 服務加密 （SSE） 進行待用加密。 Azure 備份也可備份使用 Azure 磁碟加密進行加密的 Azure VM。
| 加密 | 詳細資料 | 支援 |
|---|---|---|
| Sse | 使用 SSE，Azure 儲存體 藉由在儲存數據之前自動加密數據來提供待用加密。 Azure 儲存體 也會在擷取數據之前解密數據。 Azure 備份 支援備份具有兩種 儲存體 服務加密類型的 VM： |
Azure 備份 使用 SSE 進行 Azure VM 的待用加密。 |
| Azure 磁碟加密 | Azure 磁碟加密 加密 Azure VM 的 OS 和數據磁碟。 Azure 磁碟加密會與 BitLocker 加密金鑰 (BEK) 整合，進而以祕密的形式在金鑰保存庫中受到保護。 Azure 磁碟加密也會與 Azure Key Vault 金鑰加密金鑰 (KEK) 整合。 |
Azure 備份 支援僅使用 BEK 加密的受控和非受控 Azure VM 備份，或搭配 KEK 一起備份。 BEK 和 KEK 都會進行備份和加密。 由於 KEK 和 BEK 已備份，因此具有必要許可權的使用者可以視需要將密鑰和秘密還原回密鑰保存庫。 這些使用者也可以復原加密的 VM。 未經授權的使用者或 Azure 無法讀取加密金鑰和秘密。 |
針對受控和非受控的 Azure VM，Backup 僅支援使用 BEK 加密的 VM，或搭配 KEK 加密的 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 備份 同時處理多個記憶體帳戶的還原作業，並將還原要求放在佇列中。 |
| 還原復本 | 在還原程式期間，數據會從保存庫複製到記憶體帳戶。 還原時間總計取決於每秒的 I/O 作業 （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 的每個數據磁碟所支援的大小上限。
注意
針對 無代理程式當機時一致的備份，您目前會在預覽期間針對每個 VM 收取 0.5 個受保護實例 （PI） 的費用。
同樣地，備份記憶體帳單是以儲存在 Azure 備份 中的數據量為基礎，這是每個恢復點中實際數據的總和。
例如，採用具有兩個額外數據磁碟且大小上限為 32 TB 的 A2 標準 VM。 下表顯示每個磁碟上儲存的實際資料：
| 磁碟 | 大小上限 | 實際數據呈現 |
|---|---|---|
| OS 磁碟 | 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 中的數據量成長，用於計費變更的受保護實例大小會變更為相符。