將雲端和內部部署工作負載備份到雲端

Azure 備份透過需要零基礎結構的簡單、安全且符合成本效益的解決方案,全面保護您在 Azure 中的資料資產。 其是適用於各種不同工作負載的 Azure 內建資料保護解決方案。 它可協助您保護在雲端中執行的任務關鍵性工作負載,並確保整個備份資產一律可供使用及管理備份。

目標對象

本文的主要目標物件是 IT 和應用程式系統管理員,以及大型和中型組織的實作者,他們想要瞭解 Azure 內建數據保護技術、Azure 備份 的功能,以及實作解決方案,以有效率地保護您的部署。 本文假設您已熟悉核心 Azure 技術、數據保護概念,並具備使用備份解決方案的經驗。 本文所涵蓋的指引可讓您更輕鬆地使用已建立的模式在 Azure 上設計備份解決方案,並避免已知的陷阱。

本文的組織方式

雖然您可以輕鬆地開始保護 Azure 上的基礎結構和應用程式,但當您確定已正確設定基礎 Azure 資源,並獲得最佳使用時,您可以加速您的價值時間。 本文涵蓋設計考慮和指引的簡短概觀,以最佳方式設定您的 Azure 備份 部署。 它會檢查核心元件(例如復原服務保存庫、備份原則)和概念(例如治理),以及如何使用詳細產品文件的連結來思考它們及其功能。

開始使用

訂用帳戶設計策略

除了有明確的藍圖流覽雲端採用旅程之外,您還必須規劃雲端部署的訂用帳戶設計和帳戶結構,以符合組織的擁有權、帳單和管理功能。 當保存庫的範圍設定為訂用帳戶時,您的訂用帳戶設計將對您的保存庫設計產生高度影響。 深入瞭解 不同的訂用帳戶設計策略和使用時機指引。

記錄備份需求

若要開始使用 Azure 備份,請規劃備份需求。 以下是您在制定完美備份策略時應該問自己的一些問題。

您要保護哪些工作負載類型?

若要設計保存庫,請確定您是否需要集中式/分散式作業模式。

所需的備份粒度為何?

判斷它是否應該是應用程式一致、損毀一致或記錄備份。

您是否有任何合規性需求?

請確定您是否需要強制執行安全性標準和個別的存取界限。

所需的 RPO、RTO 為何?

判斷備份頻率和還原速度。

您是否有任何數據落地限制?

判斷必要數據持久性的記憶體備援。

您要保留備份資料多久?

決定在記憶體中保留備份數據的持續時間。

架構

顯示 Azure 備份 架構的圖表。

工作負載

Azure 備份 可針對各種工作負載(內部部署和雲端)啟用數據保護。 這是 Azure 中安全且可靠的內建數據保護機制。 它可以順暢地跨多個工作負載調整其保護,而不需要任何管理額外負荷。 還有多個自動化通道可以啟用此功能(透過 PowerShell、CLI、Azure Resource Manager 範本和 REST API。

  • 可調整、持久且安全的記憶體:Azure 備份 使用具有內建安全性和高可用性功能的可靠 Blob 記憶體。 您可以選擇備份資料的 LRS、GRS 或 RA-GRS 記憶體。

  • 原生工作負載整合:Azure 備份 提供與 Azure 工作負載的原生整合(VM、SAP HANA、Azure VM 中的 SQL,甚至是 Azure 檔案儲存體),而不需要您管理自動化或基礎結構來部署代理程式、撰寫新的腳本或布建記憶體。

深入了解 支援的工作負載。

資料平面

  • 自動化記憶體管理:Azure 備份 自動布建和管理備份數據的記憶體帳戶,以確保其隨著備份數據成長而進行調整。

  • 惡意刪除保護:防止任何意外和惡意嘗試透過虛刪除備份來刪除備份。 已刪除的備份數據會免費儲存 14 天,並允許從此狀態復原。

  • 安全加密備份:Azure 備份 確保您的備份數據以安全的方式儲存,並利用 Azure 平臺的內建安全性功能,例如 Azure 角色型存取控制 (Azure RBAC) 和加密。

  • 備份數據生命週期管理:Azure 備份 會自動清除較舊的備份數據,以符合保留原則。 您也可以將資料從作業記憶體分層至保存庫記憶體。

  • 受保護的重大作業:適用於 Azure 備份 的多用戶授權 (MUA) 可讓您將額外的保護層新增至復原服務保存庫上的重要作業。

管理平面

  • 訪問控制:保存庫(復原服務和備份保存庫)提供管理功能,並可透過 Azure 入口網站、備份中心、保存庫儀錶板、SDK、CLI,甚至是 REST API 來存取。 它也是 Azure 角色型存取控制 (Azure RBAC) 界限,可讓您選擇僅將備份的存取限制為已授權的備份 管理員。

  • 原則管理:Azure 備份 每個保存庫內的原則會定義何時應觸發備份,以及保留備份的持續時間。 您也可以管理這些原則,並將其套用到多個項目。

  • 監視和報告:Azure 備份與 Log Analytics 整合,也提供透過 Workbooks 查看報表的功能。

  • 快照集管理:Azure 備份 針對某些 Azure 原生工作負載建立快照集(VM 和 Azure 檔案儲存體),會管理這些快照集,並允許從它們快速還原。 此選項可大幅減少將數據復原至原始記憶體的時間。

保存庫考慮

Azure 備份 會使用保存庫(復原服務和備份保存庫)來協調、管理備份,以及儲存備份的數據。 有效的保存庫設計可協助組織建立結構,以組織和管理 Azure 中的備份資產,以支援您的商務優先順序。 建立保存庫時,請考慮下列指導方針。

單一或多個保存庫

若要使用單一保存庫或多個保存庫來組織和管理備份,請參閱下列指導方針:

  • 全球保護多個區域的資源:如果您的組織跨 北美洲、歐洲和亞洲有全域作業,且您的資源會部署在美國東部、英國西部和東亞。 Azure 備份 的其中一個需求是,保存庫必須存在於要備份之資源的相同區域中。 因此,您應該為每個區域建立三個不同的保存庫,以保護您的資源。

  • 保護各種業務單位和部門的資源:請考慮您的業務營運分為三個不同的業務單位(BU),而每個業務單位都有自己的部門集(財務、銷售、人力資源、研發和行銷五個部門)。 您的業務需求可能需要每個部門管理及存取自己的備份和還原;也可讓您追蹤其個別的使用量和成本費用。 針對這類案例,建議您為 BU 中的每個部門建立一個保存庫。 如此一來,您整個組織將有15個保存庫。

  • 保護不同的工作負載:如果您打算保護不同類型的工作負載(例如 150 個 VM、40 個 SQL 資料庫和 70 個 PostgreSQL 資料庫),建議您為每個類型的工作負載建立個別的保存庫(在此範例中,您需要為每個工作負載建立三個保存庫 - VM、SQL 資料庫和 PostgreSQL 資料庫)。 這可協助您將存取權授與相關項目關係人(使用 Azure 角色型存取控制 – Azure RBAC)來分隔使用者的存取界限。

  • 保護在多個環境中執行的資源:如果您的作業要求您處理多個環境,例如生產環境、非生產環境,以及開發人員,建議您為每個環境建立個別的保存庫。

  • 保護大量 Azure VM(1000+):請考慮您有 1500 部要備份的 VM。 Azure 備份 只允許一個保存庫中備份 1000 個 Azure VM。 在此案例中,您可以建立兩個不同的保存庫,並將資源分散為 1000 和 500 個 VM 到個別的保存庫,或考慮上限的任何組合。

  • 保護大量(2000+)各種工作負載:在大規模管理備份時,您將會保護 Azure VM,以及其他工作負載,例如在這些 Azure VM 上執行的 SQL 和 SAP HANA 資料庫。 例如,您有 1300 部要保護的 Azure VM 和 2500 個 SQL 資料庫。 保存庫限制可讓您在每個保存庫中備份 2000 個工作負載(限制為 1000 部 VM)。 因此,在數學上,您可以在一個保存庫中備份 2000 個工作負載(1000 個 VM + 1000 個 SQL 資料庫),並在個別保存庫中其餘 1800 個工作負載(300 個 VM + 1500 個 SQL 資料庫)。

    不過,不建議使用這種類型的隔離,因為您無法定義存取界限,而且工作負載不會彼此隔離。 因此,若要正確散發工作負載,請建立四個保存庫。 備份 VM 的兩個保存庫(1000 個 VM + 300 個 VM)和其他兩個保存庫來備份 SQL 資料庫(2000 個資料庫 + 500 個資料庫)。

  • 您可以使用:

    • 備份中心可讓您有單一窗格來管理所有備份工作。 在此深入了解
    • 如果您需要跨保存庫的一致原則,您可以使用 Azure 原則 將備份原則傳播到多個保存庫。 您可以撰寫使用 'deployifnotexists' 效果的自定義 Azure 原則 定義,將備份原則傳播到多個保存庫。 您也可以將此 Azure 原則 定義指派給特定範圍(訂用帳戶或 RG),以便將「備份原則」資源部署到 Azure 原則 指派範圍內的所有復原服務保存庫。 備份原則的設定(例如備份頻率、保留等)應該由使用者指定為 Azure 原則 指派中的參數。
  • 隨著組織使用量的成長,您可能會因為下列原因而想要跨訂用帳戶移動工作負載:依備份原則、合併保存庫、取捨較低的備援,以節省成本(從 GRS 移至 LRS)。 Azure 備份 支援跨 Azure 訂用帳戶移動復原服務保存庫,或移至相同訂用帳戶內的另一個資源群組。 在此深入了解

檢閱預設設定

在保存庫中設定備份之前,請先檢閱 儲存體 復寫類型和安全性設定的預設設定,以符合您的需求。

  • 根據預設,儲存體 複寫類型會設定為異地備援 (GRS)。 設定備份之後,就會停用修改的選項。 請遵循 下列步驟 來檢閱和修改設定。

    • 非支援和開發等非關鍵性工作負載適用於 LRS 記憶體複寫。

    • 區域備援記憶體 (ZRS) 是高數據持久性與數據落地的良好記憶體選項。

    • 異地備援 儲存體 (GRS) 建議用於任務關鍵性工作負載,例如在生產環境中執行的工作負載,以防止永久數據遺失,並在發生區域完全中斷或主要區域無法復原的災害時加以保護。

  • 預設會在新建立的保存庫上啟用虛刪除 ,以保護備份數據免於意外或惡意刪除。 請遵循 下列步驟 來檢閱和修改設定。

  • 跨區域還原 可讓您還原次要區域中的 Azure VM,這是 Azure 配對的區域。 此選項可讓您進行演練,以符合稽核或合規性需求,並在主要區域中發生災害時還原 VM 或其磁碟。 CRR 是任何 GRS 保存庫的加入功能。 在此深入了解

  • 在完成保存庫設計之前,請先檢閱 保存庫支援矩陣 ,以瞭解可能會影響或限制設計選擇的因素。

備份原則考慮

Azure 備份 原則有兩個元件: 排程(何時進行備份)和保留期(保留備份的時間)。 您可以根據要備份的數據類型、RTO/RPO 需求、作業或法規合規性需求和工作負載類型(例如 VM、資料庫、檔案)來定義原則。 深入了解

建立備份原則時,請考慮下列指導方針:

排程考慮

排程備份原則時,請考慮下列幾點:

  • 針對任務關鍵性資源,請嘗試排程每天最常提供的自動備份,以擁有較小的 RPO。 深入了解

    如果您需要透過擴充功能每天針對 Azure VM 進行多個備份,請參閱下一節中的因應措施。

  • 對於需要相同排程開始時間、頻率和保留設定的資源,您必須在單一備份原則下將它們分組。

  • 建議您在非尖峰生產應用程式時間期間保留備份排程的開始時間。 例如,最好在夜間排程每日自動備份,上午 2 點到 3 點左右,而不是在資源使用量偏高時排程每日自動備份。

  • 若要散發備份流量,建議您在一天的不同時間備份不同的 VM。 例如,若要備份具有相同保留設定的 500 部 VM,建議您建立 5 個不同的原則,讓 VM 與 100 部 VM 建立關聯,並將它們排程數小時。

保留考慮

  • 短期保留可以是「每日」。 「每週」、「每月」或「每年」備份點的保留也稱為長期保留。

  • 長期保留:

    • 規劃 (合規性需求) - 如果您事先知道需要的資料是從目前時間起以年計算,請使用長期保留。 Azure 備份 支援封存層中長期保留點的備份,以及快照集和標準層。 深入瞭解 封存層和保留組態支援的工作負載。
    • 非計劃性 (隨選需求) - 如果您事先不知道,則您可以使用隨選搭配特定的自定義保留設定(這些自定義保留設定不受原則設定影響)。
  • 隨選備份搭配自訂保留 - 如果您需要透過備份原則取得未排程的備份,則可以使用隨選備份。 這對於擷取不符合排程備份或進行細微備份的備份很有用(例如,由於排程備份每天只允許一次備份,因此每天有多個 IaaS VM 備份)。 請務必注意,在排定的原則中定義的保留原則不會套用至隨選備份。

優化備份原則

  • 隨著業務需求的變更,您可能需要延長或減少保留期間。 當您這樣做時,可以預期下列各項:

    • 如果延長保留期,則會根據新原則標示並保留現有的恢復點。
    • 如果保留期減少,恢復點會標示為在下一個清除作業中剪除,並隨後刪除。
    • 最新的保留規則適用於所有保留點(不包括隨選保留點)。 因此,如果保留期間延長(例如100天),則當備份進行時,接著是減少保留期(例如從100天縮短到7天),則所有備份數據都會根據最後指定的保留期間 (也就是7天) 保留。
  • Azure 備份 可讓您彈性地停止保護和管理備份

    • 停止保護並保留備份資料。 如果您要淘汰或解除委任數據源(VM、應用程式),但需要保留數據以供稽核或合規性之用,則可以使用此選項來停止所有未來的備份作業,以保護數據源,並保留備份的恢復點。 然後,您可以還原或繼續 VM 保護。

    • 停止保護並刪除備份資料。 此選項將會讓所有未來的備份作業停止保護 VM,並刪除所有復原點。 您將無法還原 VM,也無法使用 [繼續備份] 選項。

    • 如果您繼續保護 (已停止保留數據的數據源),則會套用保留規則。 任何過期的恢復點都會移除(在排程的時間)。

  • 完成原則設計之前,請務必注意可能會影響設計選擇的下列因素。

    • 備份原則範圍設定為一個保存庫。
    • 每個原則的項目數目有限制(例如 100 部 VM)。 若要調整,您可以建立具有相同或不同排程的重複原則。
    • 您無法選擇性地刪除特定的恢復點。
    • 您無法完全停用排程備份,並讓數據源保持受保護狀態。 您可以使用原則設定的最低頻率備份是每周排程備份一次。 替代方式是停止保護保留數據,並在每次您想要進行備份時啟用保護、進行隨選備份,然後關閉保護,但保留備份數據。 在此深入了解

安全性考量

為了協助您保護備份資料並符合您企業的安全性需求,Azure 備份提供機密性、完整性和可用性保證,以防止您寶貴的資料和系統遭到蓄意攻擊和濫用。 請考慮 Azure 備份解決方案的下列安全性指導方針:

使用 Azure 角色型存取控制 (Azure RBAC) 進行驗證和授權

  • Azure 角色型存取控制 (Azure RBAC) 提供您更精細的存取管理、隔離小組內的職責,並只授與執行其作業所需的使用者存取權數量。 在此深入了解

  • 如果您有多個工作負載要備份 (例如 Azure VM、SQL 資料庫和 PostgreSQL 資料庫),且您有多個專案關係人來管理這些備份,請務必隔離其責任,讓使用者只能存取他們負責的資源。 Azure 角色型存取控制 (Azure RBAC) 提供您細微的存取管理、隔離小組內的職責,並只授與執行其作業所需的使用者存取類型。 深入了解

  • 您也可以提供執行特定工作所需的最低存取權,以隔離職責。 例如,負責監視工作負載的人員不應該有修改備份原則或刪除備份項目的存取權。 Azure 備份提供三個內建角色來控制備份管理作業: 備份參與者、操作員和讀取者。 在此深入了解。 如需 Azure VM、SQL/SAP HANA 資料庫和 Azure 檔案共用之每個備份作業所需的最低 Azure 角色相關信息,請參閱 本指南

  • Azure 角色型訪問控制 (Azure RBAC) 也提供根據個別需求建 置自定義角色 的彈性。 如果您不確定針對特定作業建議的角色類型,您可以使用 Azure 角色型存取控制 (Azure RBAC) 所提供的內建角色,並開始使用。

    下圖說明不同 Azure 內建角色的運作方式:

    圖表說明不同 Azure 內建角色的運作方式。

    • 在上圖中,User2User3 為備份讀取者。 因此,他們只具有監視備份並檢視備份服務的權限。

    • 就存取範圍而言,

      • User2 只能存取 Subscription1 的資源,而 User3 只能存取 Subscription2 的資源。
      • User4 是備份操作員。 它具有啟用備份、觸發隨選備份、觸發還原,以及備份讀取者功能的權限。 然而,在此案例中,其範圍僅限於 Subscription2。
      • User1 是備份參與者。 它具有建立保存庫、建立/修改/刪除備份原則、停止備份,以及備份操作員的功能之權限。 然而,在此案例中,其範圍僅限於 Subscription1
  • 系統會隔離復原服務保存庫所使用的儲存體帳戶,且使用者無法對其進行存取,以進行任何惡意用途。 只有透過 Azure 備份管理作業才允許該存取權,例如還原。

傳輸中和待用數據加密

加密可保護您的數據,並協助您符合組織的安全性和合規性承諾。

  • 在 Azure 中,Azure 記憶體與保存庫之間的傳輸數據會受到 HTTPS 的保護。 此數據會保留在 Azure 網路中。

  • 備份資料會使用由 Microsoft 所管理的金鑰自動加密。 或者,您可以使用自己的金鑰,也稱為 客戶管理的金鑰。 此外,使用 CMK 加密進行備份不會產生額外費用。 不過,使用 Azure 金鑰保存庫,其中儲存您的金鑰,會產生成本,這是合理的費用,以換取較高的數據安全性。

  • Azure 備份 支援備份和還原其 OS/數據磁碟以 Azure 磁碟加密 (ADE) 加密的 Azure VM。 深入了解

使用虛刪除保護備份資料免於意外刪除

您可能會遇到在保存庫中有任務關鍵性備份數據的案例,而且意外或錯誤地刪除。 此外,惡意執行者可能會刪除您的生產備份專案。 重建這些資源通常耗費大量成本且耗費大量時間,甚至可能會導致重要的數據遺失。 Azure 備份 提供防止意外和惡意刪除與虛刪除功能可讓您在刪除資源之後復原這些資源。

使用虛刪除時,如果使用者刪除備份(VM、SQL Server 資料庫、Azure 檔案共用、SAP HANA 資料庫),則備份數據會保留 14 天,讓該備份專案不會遺失數據。 虛刪除狀態的備份數據額外保留 14 天不會產生任何費用。 深入了解

多使用者授權 (MUA)

如果您的系統管理員流氓並危害您的系統,您要如何保護您的數據?

任何具有您備份數據特殊許可權存取權的系統管理員,都有可能對系統造成無法彌補的損害。 流氓系統管理員可以刪除所有業務關鍵性數據,或甚至關閉可能讓您的系統容易受到網路攻擊的所有安全性措施。

Azure 備份 提供您多使用者授權 (MUA) 功能可保護您免於遭受這類流氓系統管理員攻擊。 多使用者授權可協助防止執行破壞性作業的流氓系統管理員(也就是停用虛刪除),方法是確保只有在獲得安全性系統管理員核准之後,才能執行每個特殊許可權/破壞性作業。

勒索軟體防護

  • 系統會排除直接存取由惡意執行者加密 Azure 備份 數據,因為備份數據上的所有作業只能透過復原服務保存庫或備份保存庫來執行,而備份數據可以受到 Azure 角色型存取控制 (Azure RBAC) 和 MUA 保護。

  • 在備份數據上啟用虛刪除(預設啟用)將會保留已刪除的數據 14 天(免費)。 停用虛刪除可以使用 MUA 來保護。

  • 使用較長的保留期(周、月、年)以確保清除備份(未由勒索軟體加密)不會過早過期,而且有早期偵測和降低對源數據這類攻擊的策略。

可疑活動的監視和警示

您可能會遇到有人嘗試入侵您的系統並惡意關閉安全性機制的案例,例如停用虛刪除或嘗試執行破壞性作業,例如刪除備份資源。

Azure 備份 透過您慣用的通知通道(電子郵件、ITSM、Webhook、Runbook 和 sp pn)傳送重要警示,藉以針對這類事件提供安全性警示頂端的動作規則深入了解

安全性功能有助於保護混合式備份

Azure 備份 服務會使用 Microsoft Azure 復原服務 (MARS) 代理程式,將檔案、資料夾和磁碟區或系統狀態從內部部署電腦備份和還原至 Azure。 MARS 現在提供安全性功能:從 Azure 備份 下載後上傳和解密之前加密的複雜密碼、刪除的備份數據會從刪除日期起再保留 14 天,而重大作業(例如變更複雜密碼)只能由具有有效 Azure 認證的用戶執行。 在此深入了解

網路考量

Azure 備份 需要將數據從工作負載移至復原服務保存庫。 Azure 備份 提供數個功能來保護備份數據,避免不小心公開(例如網路攔截式攻擊)。 請參考下列指引:

網際網路連線能力

  • Azure VM 備份:記憶體與 Azure 備份 服務之間所有必要的通訊和數據傳輸都會在 Azure 網路中發生,而不需要存取您的虛擬網路。 因此,放置於安全網路內的 Azure VM 備份不需要您允許存取任何 IP 或 FQDN。

  • Azure VM 上的 SAP HANA 資料庫、Azure VM 上的 SQL Server 資料庫:需要連線到 Azure 備份 服務、Azure 儲存體 和 Microsoft Entra ID。 這可以藉由使用私人端點或允許存取所需的公用IP位址或 FQDN 來達成。 不允許正確連線到所需的 Azure 服務,可能會導致資料庫探索、設定備份、執行備份和還原數據等作業失敗。 如需使用 NSG 標籤、Azure 防火牆和 HTTP Proxy 時的完整網路指引,請參閱這些 SQLSAP HANA 文章。

  • 混合式:MARS (Microsoft Azure 復原服務) 代理程式需要所有重要作業的網路存取權 - 安裝、設定、備份和還原。 MARS 代理程式可以使用公用對等互連(適用於舊線路)和 Microsoft 對等互連,使用私人端點或透過 Proxy/防火牆搭配適當的訪問控制,透過 Azure ExpressRoute 連線到 Azure 備份 服務

用於安全存取的私人端點

使用 Azure 備份 保護您的重要數據時,您不希望從公用因特網存取您的資源。 特別是,如果您是銀行或金融機構,您會有嚴格的合規性和安全性需求,以保護您的高業務影響 (HBI) 數據。 即使在醫療保健行業,也有嚴格的合規性規則。

若要滿足所有這些需求,請使用 Azure 私人端點,這是一種網路介面,可讓您私下且安全地連線到由 Azure Private Link 提供的服務。 我們建議您使用私人端點進行安全備份和還原,而不需要新增至虛擬網路 Azure 備份 或 Azure 儲存體 的任何IP/FQDN 允許清單。

深入瞭解如何建立和使用私人端點,以在虛擬網路內 Azure 備份。

  • 當您為保存庫啟用私人端點時,它們只會用於在 Azure VM、MARS 代理程式、DPM/MABS 備份中備份和還原 SQL 和 SAP HANA 工作負載。 您也可以使用保存庫來備份其他工作負載(但不需要私人端點)。 除了 SQL 和 SAP HANA 工作負載的備份之外,使用 MARS 代理程式和 DPM/MABS Server 進行備份,私人端點也會用來在 Azure VM 備份的情況下執行檔案復原。 在此深入了解

  • Microsoft Entra ID 目前不支援私人端點。 因此,在 Azure VM 中執行資料庫備份並使用 MARS 代理程式進行備份時,必須允許 Microsoft Entra ID 所需的 IP 和 FQDN 從安全網路進行輸出存取。 您也可以使用 NSG 標籤和 Azure 防火牆標籤來允許存取 Microsoft Entra ID (如適用)。 在這裡深入瞭解 必要條件

治理考慮

Azure 中的治理主要是使用 Azure 原則Azure 成本管理來實作。 Azure 原則 可讓您建立、指派和管理原則定義,以強制執行資源的規則。 此功能可讓這些資源符合公司標準。 Azure 成本管理 可讓您追蹤 Azure 資源和其他雲端提供者的雲端使用量和支出。 此外,下列工具,例如 Azure 價格計算機Azure Advisor ,在成本管理程式中扮演著重要的角色。

使用大規模 Azure 原則 自動設定新布建的備份基礎結構

  • 每當布建新的基礎結構並建立新的 VM 時,身為備份管理員,您必須確保其保護。 您可以輕鬆地設定一或兩部 VM 的備份。 但是當您需要大規模設定數百或甚至數千部 VM 時,就會變得很複雜。 為了簡化設定備份的程式,Azure 備份 提供一組內建的 Azure 原則來管理備份資產。

  • 使用原則在 VM 上自動啟用備份(中央備份小組模型):如果您的組織有一個中央備份小組來管理跨應用程式小組的備份,您可以使用此原則,將備份設定至與 VM 相同訂用帳戶和位置的現有中央復原服務保存庫。 您可以選擇包含/排除原則範圍中包含特定標籤的 VM。 深入了解

  • 使用原則在 VM 上自動啟用備份(應用程式小組擁有的備份位置):如果您在專用資源群組中組織應用程式,並想要讓它們由相同保存庫備份,請使用此原則來自動管理此動作。 您可以選擇包含/排除原則範圍中包含特定標籤的 VM。 深入了解

  • 監視原則:若要為您的資源產生備份報告,請在建立新的保存庫時啟用診斷設定。 通常,手動為每個保存庫新增診斷設定可能是一項繁瑣的工作。 因此,您可以使用 Azure 內建原則,將診斷設定大規模設定為每個訂用帳戶或資源群組中的所有保存庫,並將 Log Analytics 作為目的地。

  • 僅限稽核原則:Azure 備份 也提供僅稽核原則,以識別沒有備份組態的 VM。

Azure 備份 成本考慮

Azure 備份 服務提供彈性以有效管理成本;也符合 BCDR(商務持續性和災害復原)商務需求。 請參考下列指引:

  • 使用定價計算機,藉由調整各種槓桿來評估和優化成本。 深入了解

  • 優化備份原則,

    • 根據工作負載原型優化排程和保留設定(例如任務關鍵性、非關鍵性)。
    • 將立即還原的保留設定優化。
    • 選擇正確的備份類型以符合需求,同時依 Azure 備份 中的工作負載採用支援的備份類型(完整、增量、記錄、差異)。
  • 使用選擇性備份磁碟來降低備份記憶體成本:排除磁碟功能可提供有效率且符合成本效益的選擇,以選擇性地備份重要數據。 例如,當您不想備份連結至 VM 的所有磁碟時,您只能備份一個磁碟。 當您有多個備份解決方案時,這也很實用。 例如,若要使用工作負載備份解決方案來備份資料庫或數據(Azure VM 備份中的 SQL Server 資料庫),請使用所選磁碟的 Azure VM 層級備份。

  • 使用「立即還原」功能加速還原並將 RTO 降到最低:Azure 備份 擷取 Azure VM 的快照集,並將它們連同磁碟一起儲存,以提升恢復點建立及加速還原作業。 這稱為「立即還原」。 此功能可藉由減少還原時間,從這些快照集進行還原作業。 這可減少從保存庫轉換和複製數據所需的時間。 因此,這會產生此期間所擷取快照集的記憶體成本。 深入瞭解 Azure 備份 立即復原功能

  • 選擇正確的復寫類型:根據預設,Azure 備份 保存庫 儲存體 復寫類型設定為異地備援 (GRS)。 當您開始保護項目之後,就無法變更此選項。 異地備援記憶體 (GRS) 提供比本地備援記憶體更高的數據持久性層級(LRS)、允許選擇加入使用跨區域還原,而且成本更高。 檢閱較低成本與較高數據持久性之間的取捨,併為您的案例選擇最佳選項。 深入了解

  • 針對長期保留使用封存層並節省成本:請考慮您很少存取的舊備份數據案例,但基於合規性考慮,需要長期儲存(例如 99 年)。 將如此龐大的數據儲存在標準層的成本很高,而且不經濟。 為了協助您優化記憶體成本,Azure 備份 提供封存層,這是專為備份數據長期保留 (LTR) 而設計的存取層。

  • 如果您要保護 VM 內執行的工作負載和 VM 本身,請確定是否需要此雙重保護。

監視和警示考慮

身為備份使用者或系統管理員,您應該能夠監視所有備份解決方案,並取得重要案例的通知。 本節詳述 Azure 備份 服務所提供的監視和通知功能。

監視器

  • Azure 備份 提供內建作業監視,例如設定備份、備份、還原、刪除備份等作業。 這會限定於保存庫,而且很適合用來監視單一保存庫。 在此深入了解

  • 如果您需要大規模監視作業活動,備份總管會提供整個備份資產的匯總檢視,以啟用詳細的向下切入分析和疑難解答。 它是內建的 Azure 監視器活頁簿,提供單一的集中位置,協助您監視 Azure 上、跨租用戶、位置、訂用帳戶、資源群組和保存庫的整個備份資產上的作業活動。 在此深入了解

    • 使用它來識別未設定備份的資源,並確保您從未錯過保護成長資產中的重要數據。
    • 儀錶板提供過去七天的作業活動(最大值)。 如果您需要保留此數據,則可以匯出為 Excel 檔案並加以保留。
    • 如果您是 Azure Lighthouse 使用者,您可以跨多個租用戶檢視資訊,以啟用無界限監視。
  • 如果您需要保留及檢視長期營運活動,請使用 報表。 備份管理員的常見需求是根據跨越一段時間的數據,取得備份的深入解析。 這類解決方案的使用案例包括:

    • 配置和預測已取用的雲端儲存體。
    • 稽核備份和還原。
    • 找出不同細微性層級的主要趨勢。
  • 此外,

    • 您可以將數據(例如作業、原則等)傳送至 Log Analytics 工作區。 這可讓 Azure 監視器記錄的功能讓數據與 Azure 監視器所收集的其他監視數據相互關聯、將多個 Azure 訂用帳戶和租使用者的記錄項目合併到一個位置進行分析、使用記錄查詢來執行複雜的分析,以及深入了解記錄專案。 在此深入了解
    • 您可以將數據傳送至 Azure 事件中樞,以將專案傳送到 Azure 外部,例如第三方 SIEM(安全性資訊和事件管理)或其他記錄分析解決方案。 在此深入了解
    • 如果您想要保留超過90天的記錄資料進行稽核、靜態分析或備份,您可以將資料傳送至 Azure 儲存體 帳戶。 如果您只需要保留 90 天或更少的事件,則不需要將封存設定至記憶體帳戶,因為活動記錄事件會保留在 Azure 平臺中 90 天。 深入了解

警示

在備份/還原作業因某些未知問題而失敗的案例中。 若要指派工程師進行偵錯,您想要儘快收到失敗的通知。 也可能有一個案例,有人惡意執行破壞性作業,例如刪除備份專案或關閉虛刪除,而您需要這類事件的警示訊息。

您可以設定這類重大警示,並將其路由傳送至任何慣用的通知通道(電子郵件、ITSM、Webhook、Runbook 等等)。 Azure 備份 與多個 Azure 服務整合,以符合不同的警示和通知需求:

  • Azure 監視器記錄 (Log Analytics):您可以設定保存 庫將數據傳送至 Log Analytics 工作區、在工作區上寫入自定義查詢,以及根據查詢輸出設定要產生的警示。 您可以在數據表和圖表中檢視查詢結果;此外,將它們匯出至 Power BI 或 Grafana。 (Log Analytics 也是後續各節所述報告/稽核功能的重要元件。

  • Azure 監視器警示:針對某些預設案例,例如備份失敗、還原失敗、備份數據刪除等,Azure 備份 預設會傳送使用 Azure 監視器呈現的警示,而不需要使用者設定 Log Analytics 工作區。

  • Azure 備份 透過電子郵件提供內建的警示通知機制,以進行失敗、警告和重大作業。 您可以指定要在產生警示時收到通知的個別電子郵件地址或通訊組清單。 您也可以選擇取得每個個別警示的通知,或以每小時摘要將它們分組,然後收到通知。

    • 這些警示是由服務所定義,並支援有限的案例 - 備份/還原失敗、使用保留數據停止保護/停止保護與刪除數據等等。 在此深入了解
    • 如果執行刪除數據的停止保護等破壞性作業,就會引發警示,並將電子郵件傳送給訂用帳戶擁有者、系統管理員和共同管理員,即使未針對復原服務保存庫設定通知也一樣。
    • 某些工作負載可能會產生高頻率的失敗(例如,每 15 分鐘 SQL Server 一次)。 為避免因每次失敗而引發的警示不堪重負,系統會合併警示。 在此深入了解
    • 內建的警示無法自定義,而且僅限於 Azure 入口網站 中定義的電子郵件。
  • 如果您需要 建立自定義警示 (例如成功作業的警示),請使用Log Analytics。 在 Azure 監視器中,您可以在 Log Analytics 工作區中建立自己的警示。 混合式工作負載 (DPM/MABS) 也可以將數據傳送至 LA,並使用 LA 在 Azure 備份 支援的工作負載之間提供常見警示。

  • 您也可以透過內建的復原服務保存庫 活動記錄來取得通知。 不過,它支援有限的案例,不適用於排程備份之類的作業,這比使用活動記錄更符合資源記錄。 若要深入了解這些限制,以及如何針對受 Azure 備份 保護的所有工作負載大規模監視和警示Log Analytics工作區,請參閱這篇文章

自動重試失敗的備份作業

許多失敗錯誤或中斷案例本質上都是暫時性的,您可以藉由設定正確的 Azure 角色型訪問控制 (Azure RBAC) 許可權來補救,或重新觸發備份/還原作業。 由於這類失敗的解決方案很簡單,您不需要花時間等待工程師手動觸發作業或指派相關許可權。 因此,處理此案例的更聰明方式是自動重試失敗的工作。 這會大幅降低從失敗中復原所需的時間。 您可以透過 Azure Resource Graph (ARG) 擷取相關的備份數據,並將其與更正 的 PowerShell/CLI 程式合併,以達成此目的。

觀看下列影片,瞭解如何使用ARG和PowerShell重新觸發所有失敗作業的備份(跨保存庫、訂用帳戶、租使用者)。

將警示路由傳送至您慣用的通知通道

雖然可以修正暫時性錯誤,但某些持續性錯誤可能需要深入分析,而重試作業可能不是可行的解決方案。 您可能有自己的監視/票證機制,以確保已正確追蹤和修正這類失敗。 若要處理這類案例,您可以選擇在警示上建立動作規則,將警示路由傳送至您慣用的通知通道(電子郵件、ITSM、Webhook、Runbook 等等。

觀看下列影片,瞭解如何利用 Azure 監視器來設定重要警示的各種通知機制。

下一步

閱讀下列文章作為使用 Azure 備份 的起點: