備份 SQL Server Always On 可用性群組
Azure 備份提供端對端支援，當所有節點和復原服務保存庫位於相同的區域和訂閱時，可備份 SQL Server Always On 可用性群組 (AG)。 但如果 AG 節點分散在不同的區域/訂閱/內部部署和 Azure，就有一些考量需要注意。
注意
- Azure 備份不支援基本可用性群組資料庫的備份。
- 若要深入了解支援的設定和案例，請參閱 SQL 備份支援矩陣圖。
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 (另一個訂閱)
- 因為保存庫 2 未設定備份，所以不會發生任何備份。
- 如果備份喜好設定不是僅次要，則可立即在保存庫 2 中設定備份，因為主要節點登錄在此保存庫中。 但這樣會導致衝突/備份失敗。 詳細資訊請參閱設定多區域 AG 備份。
- 容錯移轉至 VM4 (另一個區域)
- 因為保存庫 4 未設定備份，所以不會發生任何備份。
- 如果備份喜好設定不是僅次要，則可立即在保存庫 4 中設定備份，因為主要節點登錄在此保存庫中。 但這樣會導致衝突/備份失敗。 詳細資訊請參閱設定多區域 AG 備份。
設定多區域 AG 備份
復原服務保存庫不支援跨訂閱或跨區域備份。 本節會摘要說明如何啟用跨訂閱或 Azure 區域的 AG 備份及相關考量。
評估您是否真的需要備份所有節點。 如果某個區域/訂用帳戶擁有大部分的 AG 節點，且很少容錯移轉到其他節點，則在該第一個區域中設定備份即已足夠。 但若您經常需要容錯移轉到其他區域/訂用帳戶且需要很長時間，您可能會想要主動在其他區域設定備份。
每個啟用備份的保存庫都有自己的一組復原點鏈結。 這些復原點只能還原到該保存庫的登錄 VM。
只有包含主要節點的保存庫，才能成功執行完整/差異備份。 這些備份在其他保存庫都會失敗。
記錄備份會繼續在之前的保存庫中執行，直到記錄備份開始在新的保存庫中執行 (即新主要節點所在的保存庫)，並中斷舊保存庫的記錄鏈結。
注意
固定限制 15 天，超過此期限的記錄備份將開始失敗。
只複製完整備份適用所有保存庫。
每個保存庫中的保護都被視為不同的資料來源，且會另行計費。
為避免兩個保存庫之間發生記錄備份衝突，建議將備份喜好設定設為 [主要]。 然後，凡包含主要節點的保存庫也將可執行記錄備份。
根據上述的範例 AG 部署，下列為在所有節點上啟用備份的步驟。 假設所有步驟都能滿足此備份喜好設定。
步驟 1：啟用區域 1、訂閱 1 (保存庫 1) 的備份
因為主要節點位於區域和訂閱中，所以一般啟用備份的步驟為有效。
步驟 2：啟用區域 1、訂閱 2 (保存庫 2) 的備份
- 將 AG 容錯移轉至 VM3，讓主要節點出現在保存庫 2 中。
- 在保存庫 2 中設定 AG 資料庫的備份。
- 至此：
- 保存庫 1 的完整/差異備份會失敗，因為沒有登錄的節點可以執行此備份。
- 保存庫 1 的記錄備份會一直持續到記錄備份在保存庫 2 中執行，並中斷保存庫 1 的記錄鏈結。
- 將 AG 容錯回復到 VM1。
步驟 3：啟用區域 2、訂閱 1 (保存庫 4) 的備份
與步驟 2 相同。
備份橫跨 Azure 和內部部署的 AG
適用於 SQL Server 的 Azure 備份無法在內部部署環境中執行。 如果主要節點位於 Azure，而 Azure 中的節點滿意備份喜好設定，您即可遵循上述多區域 AG 的指引，在 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，以避免備份失敗。
下一步
了解如何：