備份 SQL Server Always On 可用性群組

Azure 備份提供端到端支援，當所有節點皆位在與復原服務保管庫相同區域及訂閱中時，可備份 SQL Server Always On 可用性群組 (AG)。 但如果 AG 節點分散在不同的區域/訂閱/內部部署和 Azure，就有一些考量需要注意。

若要檢視我們今天支援的備份和還原案例，請參閱 支援矩陣。 常見問題請參見 常見問題。

備註

Azure 備份不支援基本可用性群組資料庫的備份。

Azure 備份 SQL AG 所用的備份喜好設定只支援主要複本的完整和差異備份。 因此，不論備份喜好設定為何，這些備份工作一律會在主要節點上執行。 若是只複製完整備份和交易記錄備份，在決定執行備份的節點時，需考量 AG 的備份偏好設定。

AG 備份喜好設定	完整備份和差異備份的執行時間為	僅複製備份和日誌備份已被建立
主要	主要複本	主要复制品
僅次於主要	主要副本	任何一個次要複本
偏好次要	主要複本	最好是次要複本，但您也可以在主要複本上執行備份。
無/任何	主要副本	任何副本

當您使用 Azure 備份服務登錄工作負載備份延伸模組時，模組即會安裝在節點上。 當 AG 資料庫設定執行備份後，備份排程會推送至該 AG 的所有登錄節點。 排程會在所有 AG 節點上運行，這些節點上的工作負載備份擴展模組會在各節點間同步，以決定哪個節點可以執行備份。 節點的選擇取決於備份類型和備份喜好設定，如第 1 節中所述。

選定的節點會繼續執行備份作業，而在其他節點觸發的作業則會被中止或略過。

備註

Azure 備份在次要複本之間做出決定時不考慮備份優先順序或複本。

向復原服務保存庫登錄 AG 節點

復原服務保存庫僅支援從與保存庫相同區域和訂用帳戶中的 VM 備份資料庫。

• 請向保存庫登錄主要節點 (否則無法執行完整備份)。
• 如果備份喜好設定為僅次要，則您必須在保存庫中至少登錄一個次要節點 (否則無法記錄/只複製完整備份)。

如不符合上述條件，AG 資料庫的備份設定將會失敗，並出現錯誤碼 FabricSvcBackupPreferenceCheckFailedUserError。

請考慮以下 AG 部署作為參考。

根據給定的 AG 範例部署，以下是不同的考量事項：

• 因為主要節點位於區域 1 和訂閱 1，所以復原服務保存庫 (保存庫 1) 必須在區域 1 和訂閱 1 中才能保護此 AG。
• VM3 無法登錄到保存庫 1，因其位於不同的訂用帳戶。
• VM4 無法登錄到保存庫 1，因其位於不同的區域。
• 如果備份喜好設定為僅次要，VM1 (主要) 和 VM2 (次要) 必須登錄到保存庫 1 (因為完整備份需要主要節點，而記錄需要次要節點)。 若為其他備份喜好設定，則 VM1 (主要) 必須登錄到保存庫 1，而 VM2 為選擇性 (因為所有備份都可以在主要節點上執行)。
• 雖然 VM3 可以登錄到訂閱 2 的保存庫 2，且 AG 資料庫會在保存庫 2 中顯示保護，但因為保存庫 2 中沒有主要節點，所以設定備份會失敗。
• 同樣地，雖然 VM4 可以登錄到區域 2 的保存庫 4，但因為主要節點不是登錄在保存庫 4 中，所以設定備份會失敗。

處理故障轉移

當 AG 故障轉移到其中一個次要節點之後：

• 如果新的主要節點已登錄到保管庫，則完整和差異備份將會在新的主要節點上繼續。
• 根據備份偏好設定，從主要/次要節點繼續執行日誌和僅複製完整備份。

備註

如果容錯移轉與備份不是同時發生，容錯移轉時就不會發生記錄鏈結中斷。

根據上述的範例 AG 部署，下列為各種故障轉移情況：

• 容錯切換至 VM2
  • 完整和差異備份將由 VM2 執行。
  • 根據備份喜好設定，記錄備份和僅複製的完整備份將由 VM1 或 VM2 執行。
• 故障轉移至 VM3 (其他訂閱)
  • 由於 Vault 2 未配置備份功能，因此不會進行任何備份。
  • 如果備份喜好設定不是僅次要，則可立即在保存庫 2 中設定備份，因為主要節點登錄在此保存庫中。 但這樣會導致衝突/備份失敗。 詳細資訊請參閱設定多區域 AG 備份。
• 容錯移轉至 VM4 (另一個區域)
  • 因為保存庫 4 未設定備份，所以不會進行任何備份。
  • 如果備份喜好設定不是僅次要，則可立即在保存庫 4 中設定備份，因為主要節點登錄在此保存庫中。 但這樣會導致衝突/備份失敗。 詳細資訊請參閱設定多區域 AG 備份。

設定多區域 AG 備份

復原服務保存庫不支援跨訂閱或跨區域備份。 本節會摘要說明如何啟用跨訂閱或 Azure 區域的 AG 備份及相關考量。

• 評估您是否真的需要啟用所有節點的備份功能。 如果某個區域/訂用帳戶擁有大部分的 AG 節點，且很少容錯移轉到其他節點，則在該第一個區域中設定備份即已足夠。 發生到其他區域/訂用帳戶的容錯移轉時如果經常且持續時間長，您可能會想要主動在其他區域設置備份。

• 每個啟用備份的保存庫都有自己的一組復原點鏈結。 這些復原點只能用於還原到僅註冊在該保管庫中的 VM。

• 只有包含主要節點的保存庫，才能成功執行完整/差異備份。 這些備份在其他儲存庫會持續失敗。

• 記錄備份會繼續在之前的保存庫中執行，直到記錄備份開始在新的保存庫中執行 (即新主要節點所在的保存庫)，並中斷舊保存庫的記錄鏈結。

  備註

  固定限制 15 天，超過此期限的記錄備份將開始失敗。

• 僅限複製的完整備份將適用於所有保存庫。

• 每個保存庫中的保護都被視為不同的資料來源，且會另行計費。

為避免兩個保存庫之間發生日誌備份衝突，我們建議您將備份偏好設定為主要。 然後，包含主要節點的任何儲存庫也將執行日誌備份。

根據上述的範例 AG 部署，下列為在所有節點上啟用備份的步驟。 假設所有步驟都能滿足此備份喜好設定。

步驟 1：啟用區域 1、訂閱 1 (保存庫 1) 的備份

因為主要節點位於區域和訂閱中，所以一般啟用備份的步驟為有效。

步驟 2：在區域 1、訂閱 2 (保管庫 2) 中啟用備份

1. 將 AG 容錯移轉至 VM3，讓主要節點出現在保存庫 2 中。
2. 在保存庫 2 中設定 AG 資料庫的備份。
3. 至此：
   1. 保存庫 1 的完整/差異備份將會失敗，因為沒有任何已註冊的節點可以執行此備份。
   2. 保存庫 1 的日誌備份會成功執行直到保存庫 2 中執行日誌備份，而中斷保存庫 1 的日誌鏈結。
4. 將 AG 回切到 VM1。

步驟 3：啟用區域 2、訂閱 1 (保存庫 4) 的備份

與步驟 2 相同。

備份橫跨 Azure 和本地環境的可用性群組 (AG)

適用於 SQL Server 的 Azure 備份無法在內部部署環境中執行。 如果主要節點位於 Azure，而 Azure 中的節點符合備份偏好設定，您即可遵循上述多區域可用性群組的指引，在 Azure 中啟用複本的備份。 如果發生容錯移轉到內部部署節點，Azure 中的完整和差異備份將開始失效。 日誌備份可能會繼續進行，直到發生日誌鏈結中斷或超過 15 天。

AG 資料庫備份工作的限制

目前，備份節流限制僅適用於個別的機器層級。 預設限制為 20，如果同時觸發 20 個以上的備份，則會執行前 20 個備份，其他備份將排入佇列。 當正在執行的工作完成後，排隊中的工作會開始執行。

如果同時執行的備份工作造成節點的記憶體/IO/CPU 負擔，您可以將此值變更為較小的值。 因為節流是在節點層級執行，所以 AG 節點不平衡可能會造成備份同步問題。 為了理解此概念，請考慮 2 個節點的 AG 例子。

例如，第一個節點有 50 個受保護的獨立資料庫，而兩個節點受保護的 AG 資料庫都是 5 個。 結果就是，節點 1 排定了 55 項資料庫備份工作，而節點 2 只有 5 項工作。 此外，所有這些備份都設定在同一時間執行，每小時一次。 在某個時間點，節點 1 上觸發了所有 55 項備份工作，其中的 35 項會排入佇列。 有些可能是 AG 資料庫備份。 但是在節點 2 上，AG 資料庫備份會不需任何排隊地順利進行。

當 AG 資料庫的作業在一個節點上排隊，而在另一個節點上運行時，第 6 節中提到的備份同步將無法正常運作。 節點 2 可能會認為節點 1 故障，因此無法執行來自該節點的工作以進行同步。 這會導致記錄鏈結中斷或額外的備份，因為兩個節點都可以獨立執行備份。

如果受保護的 AG 資料庫數目超過節流限制，就會發生類似的問題。 在這種情況下，例如，DB1 的備份可以在節點 1 上排隊執行，而在節點 2 上運行。

建議使用下列備份喜好設定，以避免這些同步問題：

• 2 節點 AG 的 [備份喜好設定] 請設為 [主要] 或 [僅次要]，如此只有一個節點可以執行備份，另一個節點一律放棄。
• 如果 AG 有 2 個以上的節點，請將 [備份喜好設定] 設為 [主要]，如此只有主要節點可以執行備份，其他節點則會放棄。

AG 備份的計費

與獨立的 SQL 執行個體相同，一個已備份的 AG 執行個體視為一個受保護的執行個體。 執行個體中所有受保護資料庫的前端大小總和會被收費。 請考慮下列部署：

受保護執行個體的計算方式如下：

受保護的執行個體/計費實例	用於計算前端尺寸的資料庫
AG1	DB1、DB2
AG2	DB4
VM2	DB3
VM3	DB6
VM4	DB5

將受保護的資料庫移入或移出 AG

Azure 備份會將 SQL 執行個體或 AG 名稱\資料庫名稱視為資料庫的唯一名稱。 當獨立資料庫受到保護時，其唯一的名稱是 StandAloneInstanceName\DBName。 當其移入 AG 下方時，唯一的名稱會變更為 AGName\DBName。 獨立資料庫的備份將開始失敗，錯誤碼為：UserErrorBackupFailedStandaloneDatabaseMovedInToAG。

資料庫保護必須設定在 AG 下方。 這將會視為具有個別復原點鏈結的新資料來源。 您可以保留數據來終止舊版獨立資料庫的保護，這樣可以避免未來備份被觸發並導致失敗。 同樣地，當受保護的 AG 資料庫移出 AG 成為獨立資料庫後，其備份就會開始失敗，錯誤碼為：UserErrorBackupFailedDatabaseMovedOutOfAG。

必須將資料庫配置在獨立執行個體的保護下。 這將會視為具有個別復原點鏈結的新資料來源。 您可以利用保留資料停止舊版的 AG 資料庫保護，以免日後觸發備份及備份失敗。

新增/移除 AG 的節點

當將新的節點新增至設定備份的 AG 時，在已登錄 AG 節點上執行的工作負載備份延伸模組會偵測 AG 拓撲變更，並在下次排程的資料庫探索工作期間通知 Azure 備份服務。 當此新節點註冊到與其他現有節點相同的復原服務保存庫中以進行備份時，Azure 備份服務會觸發一個工作流程，將執行 AG 備份所需的中繼資料設定到這個新節點。

然後，新的節點就會同步 Azure 備份服務的 AG 備份排程資訊，並開始參與同步的備份流程。 如果新節點無法同步備份排程並參與備份，則在節點上觸發重新登錄，也會強制重新設定此節點執行 AG 備份。 同樣地，新增節點後，工作負載延伸模組會偵測此情況下的 AG 拓撲變更，並通知 Azure 備份服務。 服務會在移除的節點中啟動節點取消設定工作流程，以清除 AG 資料庫的備份排程，並刪除 AG 相關的中繼資料。

在 Azure 備份中取消登錄 AG 節點

如果節點屬於已設定一或多個資料庫備份的 AG，則 Azure 備份不會允許取消登錄該節點。 這是為避免未來的備份失敗，以防萬一沒有此節點將無法滿足備份喜好設定。 若要取消登錄節點，首先必須從 AG 移除該節點。 當節點解除設定工作流程完成後，整理該節點後，您就可以取消註冊該節點。

從 Azure 備份將資料庫還原至 AG SQL 可用性群組，不支援直接將資料庫還原到 AG。 資料庫必須還原至獨立的 SQL 實例，然後需要加入到可用性群組 (AG)。

SQL 資料庫伺服器的可用性群組重新建立案例

在下列情境中：重建可用性群組 (AG)、重複的 AG，及備份項目會被列為可保護項目或受保護項目：

• 在 [設定備份] 頁面和 [受保護的項目] 清單中，重新建立已受到保護的 AG 會顯示為重複的 AG。 如果您想要保留舊版 AG 中已存在的備份資料，請使用 [停止保護並保留資料] 選項來停止備份，然後再重新建立和排程新 AG 項目上的備份。

  根據設計，Azure 備份會列出受保護項目清單上的重複項目，以及設定備份頁面或可保護的項目清單，並顯示這些項目，直到您想要保留備份資料為止。

• 如果您不會想保留舊版 AG 的備份資料，請針對舊的項目使用 [停止保護並刪除資料] 選項來停止備份作業，然後再重新建立和排程新 AG 上的備份。

  警告

  停止保護並刪除資料是一項毀滅性的作業。

• 您可以在執行上述其中一個停止保護程序之後重新建立 AG，以避免備份失敗。

下一步

了解如何：

• 還原 SQL Server 資料庫備份
• 管理 SQL Server 資料庫備份

相關內容

• 透過 REST API 使用 Azure 備份在 Azure VM 中備份 SQL Server 資料庫。
• 使用 REST API 在 Azure VM 中還原 SQL Server 資料庫。
• 使用 Azure 入口網站、 Azure CLI、 REST API 管理 Azure VM 中的 SQL Server 資料庫。