共用方式為

Azure SQL 資料庫的自動化備份

  • 發行項

適用於：Azure SQL 資料庫

本文說明 Azure SQL 資料庫的自動備份功能。

若要變更備份設定，請參閱變更設定。 若要還原備份，請參閱使用自動資料庫備份進行復原。

什麼是資料庫備份？

資料庫備份有助於保護您的資料免於損毀或刪除，是商務持續性和災害復原策略中不可或缺的一部分。 這些備份可在設定的保留期間內讓資料庫還原至特定時間點。 如果您的資料保護規則要求備份必須能夠延長使用 (最長至 10 年)，您可以同時為單一和集區資料庫設定長期保留 (LTR)。

對於超大規模資料庫以外的服務層級，Azure SQL 資料庫會使用 SQL Server 引擎技術來備份和還原資料。 超大規模資料庫會根據儲存體快照集使用備份和還原。 使用傳統的 SQL Server 備份技術，較大的資料庫會有很長的備份/還原時間。 透過使用快照集，超大規模資料庫可提供立即備份和快速還原功能，不論資料庫大小為何。 若要深入瞭解，請參閱超大規模資料庫備份。

備份頻率

Azure SQL 資料庫會建立：

交易記錄備份的確切頻率是根據計算大小與資料庫活動數量而定。 在您還原資料庫時，服務會判斷需要還原的完整、差異及交易記錄備份。

超大規模資料庫結構不需要完整備份、差異備份或記錄備份。 若要深入瞭解，請參閱超大規模資料庫備份。

備份儲存體備援

儲存體備援機制會儲存多個資料複本，保護資料免受計劃性和非計劃性事件的影響。 這些事件可能涵蓋暫時性的硬體失敗、網路或電力中斷，或重大自然災害。

依預設，Azure SQL 資料庫中的新資料庫會將備份存放在異地備援儲存體 Blob，其會複寫至配對區域。 異地備援有助於防止會影響主要區域中備份儲存體的中斷。 它也可讓您在發生區域性中斷時，在不同的區域中還原資料庫。

Azure 入口網站提供工作負載環境選項，可協助預先設定部分組態設定。 可以覆寫這些設定。 此選項僅適用於 [建立 SQL Database] 入口網站頁面。

  • 選擇開發工作負載環境會設定備份儲存體備援選項，以使用本地備援儲存體。 本地備援儲存體的成本較低，適用於不需要區域或異地複寫儲存體備援的實際執行前環境。
  • 選擇 [實際執行] 工作負載環境會將備份儲存體備援設定為異地備援儲存體 (此為預設值)。
  • [工作負載環境] 選項也會變更計算的初始設定，不過可以覆寫此設定。 否則，[工作負載環境] 選項對授權或其他資料庫組態設定沒有任何影響。

若要確保您的備份會保留在部署資料庫所在的相同區域內，您可以將備份儲存體備援從預設的異地備援儲存體變更為將您的資料保留在該區域內的其他類型儲存體。 設定的備份儲存體備援會套用至短期保留 (STR) 備份和 LTR 備份。 若要深入了解儲存體備援，請參閱資料備援。

您可以在建立資料庫時設定備份儲存體備援，且可以稍後更新備份儲存體備援。 您對現有資料庫所做的變更只會套用至未來的備份。 您更新現有資料庫的備份儲存體備援之後，最多可能需要 48 小時才會套用變更。

您可以選擇下列其中一個備份的儲存體備援：

  • 本地備援儲存體 (LRS)：在主要區域的單一實體位置內，同步複製您的備份三次。 LRS 是成本最低的儲存體選項，但我們不建議用於需要復原區域中斷或保證高資料持久性的應用程式。

    此圖顯示本地備援儲存體 (LRS) 選項。

  • 區域備援儲存體 (ZRS)：將您的備份同步複製到主要區域中的三個 Azure 可用性區域。 目前僅在特定地區提供服務。

    此圖顯示區域備援儲存體 (ZRS) 選項。

  • 異地備援儲存體 (GRS)：透過使用 LRS，在主要區域中的單一實體位置內，同步複製您的備份三次。 接著將資料以非同步方式複製三次到配對次要區域中的單一實體位置。

    結果如下：

    • 有三個同步複本在主要區域。
    • 有三個同步複本在配對區域，這些複本是以非同步方式從主要區域複製到次要區域。

    此圖顯示異地備援儲存體 (GRS) 選項。

  • 異地區域備援記憶體 （GZRS）：異地區域備援記憶體 （GZRS） 結合了可用性區域 （ZRS） 之間備援所提供的高可用性，以及異地復寫 （GRS） 所提供的區域中斷保護。 將備份同步複製到主要區域中的三個 Azure 可用性區域，並以異步方式將備份複製到配對次要區域中的單一實體位置。

    Microsoft 建議針對需要最大一致性、持久性、可用性、絕佳效能，以及針對災害復原恢復的應用程式使用 GZRS。

    結果如下：

    • 主要區域中跨 可用性區域的三個同步複本。

    • 配對區域中的三個同步複本，以異步方式從主要區域複製到次要區域。

      下圖顯示使用 GZRS 或 RA-GZRS 複寫資料的方式：

    顯示異地區域備援記憶體 （GZRS） 選項的圖表。

警告

  • 當資料庫更新為使用本地或區域備援儲存體時，就會立即停用異地還原。
  • 所有儲存體備援的圖都會顯示具有多個可用性區域 (multi-az) 的區域。 不過，有些區域只提供單一可用性區域，而且不支援 ZRS。
  • 超大規模資料庫的備份儲存體備援只能在建立期間設定。 佈建資源之後，您無法修改此設定。 若要以最短停機時間更新現有超大規模資料庫的備份儲存體備援設定，請使用作用中異地複寫。 或者，您可以使用資料庫複本。 若要深入了解，請參閱超大規模資料庫備份和儲存體備援。

備份使用量

您可以在下列情節中使用自動建立的備份：

  • 使用 Azure 入口網站、Azure PowerShell、Azure CLI 或 REST API，在保留期間內將現有的資料庫還原至過去的時間點。 此作業會在原始資料庫的相同伺服器上建立新資料庫，但使用不同的名稱來避免覆寫原始資料庫。

    在還原完成後，您可以選擇性刪除原始資料庫，然後將還原的資料庫重新命名為原始資料庫的名稱。 或者，您可以不刪除原始資料庫並且重新命名，然後將還原的資料庫重新命名為原始的資料庫名稱。

  • 將已刪除的資料庫還原至保留期間內的時間點，包括刪除的時間在內。 已刪除的資料庫只能在當中已建立原始資料庫的相同伺服器中還原。 刪除資料庫之前，服務會建立最後的交易記錄備份，以防止任何資料遺失。

  • 將資料庫還原到其他地理區域。 異地還原可讓您在無法存取您主要區域中的資料庫或備份時，從區域中斷中復原。 會在任何 Azure 區域中的任何現有伺服器上建立新的資料庫。

    重要

    異地還原僅適用於已設定異地備援備份儲存體的資料庫。 如果您目前未針對資料庫使用異地複寫備份，您可以設定備份儲存體備援來變更此備份。

  • 如果已使用 LTR 原則設定資料庫，請從單一或集區資料庫的特定長期備份還原資料庫。 LTR 可讓您使用 Azure 入口網站、Azure CLI 或 Azure PowerShell 來還原舊版資料庫，以符合規範要求或執行舊版應用程式。 如需詳細資訊，請參閱長期保存。

警告

還原資料庫且來源備份記憶體備援設定為異地區域備援記憶體（GZRS）時，如果未明確指定目標資料庫的備份記憶體備援組態，來源備份記憶體組態就會由新資料庫繼承。 這包括任何還原作業，例如時間點還原、資料庫複製、異地還原、從長期備份還原。 在此作業期間，如果目標 Azure 區域不支援特定的備份記憶體備援，還原作業將會失敗，並出現適當的錯誤訊息。 這可以藉由明確指定區域的可用記憶體選項來緩和。

自動次要複本上的備份

自動備份現在取自業務關鍵服務層級中的次要複本。 由於資料會在每個節點上的 SQL Server 進程之間複寫，因此備份服務會從不可讀取次要複本取得備份。 此設計可確保主要複本仍專用於主要工作負載，而可讀取次要複本則專用於唯讀工作負載。 業務關鍵服務層級中的自動備份主要取自次要複本。 如果次要複本上的自動備份失敗，備份服務會從主要複本取得備份。

自動次要複本上的備份︰

  • 預設啟用。
  • 不包含超出服務層級價格的額外費用。
  • 提升業務關鍵服務層級的效能和可預測性。

注意

  • 建立 Microsoft 支援服務票證，以停用執行個體的功能。

還原的功能和特性

下表摘要說明時間點還原 (PITR)、異地還原和長期保留的功能和特性。

備份屬性 PITR 異地復原 LTR
SQL 備份的類型 完整、差異、記錄。 PITR 備份的最新異地複寫複本。 僅完整備份。
復原點目標 (RPO) 10 分鐘，根據計算大小和資料庫活動量。 最多 1 小時，根據異地複寫。 1 一週 (或使用者的原則)。
復原時間目標 (RTO) 還原通常需要不到 12 小時的時間，但是依大小和活動，時間也可能更長。 請參閱復原。 還原通常需要不到 12 小時的時間，但是依大小和活動，時間也可能更長。 請參閱復原。 還原通常需要不到 12 小時的時間，但是依大小和活動，時間也可能更長。 請參閱復原。
保留 預設為 7 天，可設定為介於 1 到 35 天之間的值 (基本資料庫除外，可設定為介於 1 到 7 天之間)。 預設為啟用，與來源相同。2 預設不啟用。 保留最多 10 年。
Azure 儲存體 預設具有異地備援功能。 您可以選擇設定區域備援或本地備援儲存體。 當 PITR 備份儲存體備援設定為異地備援時可供使用。 若 PITR 備份儲存體是區域備援或本地備援則無法使用。 預設具有異地備援功能。 您可以設定區域備援或本地備援儲存體。
將備份設定為 [不可變] 不支援 不支援 不支援
在相同區域中還原新資料庫 支援 支援 支援
在另一個區域中還原新資料庫 不支援 在任何 Azure 區域中都支援 在任何 Azure 區域中都支援
在另一個訂用帳戶中還原新資料庫 不支援 不支援3 不支援3
透過 Azure 入口網站還原 Yes .是 Yes
透過 Powershell 還原 Yes .是 Yes
透過 Azure CLI 還原 Yes .是 Yes

1 對於需要大型資料庫且必須確保商務持續性的業務關鍵應用程式，請使用容錯移轉群組。
2 預設會將所有 PITR 備份儲存在異地備援儲存體上，因此，預設值為啟用異地還原。
3 因應措施是還原至新的伺服器，並使用「資源移動」將伺服器移至另一個訂用帳戶，或使用跨訂用帳戶資料庫複製。

從備份還原資料庫

若要執行還原，請參閱從備份還原資料庫。 您可以使用下列範例來探索備份設定和還原作業。

作業 Azure 入口網站 Azure CLI Azure PowerShell
變更備份保留期 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體
變更長期備份保留期 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體
從某個時間點還原資料庫 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體
還原已刪除的資料庫 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體		 SQL Database
SQL 受控執行個體

匯出資料庫

Azure 服務所建立的自動備份無法直接下載或存取。 它們只能用於透過 Azure 進行還原作業。

您也可以用另類方法匯出 Azure SQL 資料庫。 當您需要匯出資料庫以封存或移至另一個平台時，可以將資料庫結構描述和資料匯出至 BACPAC 檔案。 BACPAC 檔案是一種副檔名為 BACPAC 的 ZIP 檔案，其中包含來自資料庫的中繼資料和資料。 BACPAC 檔案可以儲存在 Azure Blob 儲存體或內部部署位置的本機儲存體中，稍後再匯回 Azure SQL 資料庫、Azure SQL 受控執行個體或 SQL Server 執行個體。

您也可以使用私人連結匯入或匯出 Azure SQL 資料庫或匯入或匯出 Azure SQL 資料庫，但不允許 Azure 服務存取伺服器。

備份排程

新的資料庫建立或還原後，就會立即排程第一次完整備份。 此備份通常會在 30 分鐘內完成，但如果資料庫很大，則所需時間可能更久。 例如，在還原的資料庫或資料庫複本上，初始備份可能需要較長的時間，通常會大於新的資料庫。

第一次完整備份之後，所有進一步的備份都會自動排程和管理。 資料庫備份的確切時間，依 SQL Database 服務整體系統工作負載維持平衡而決定。 您無法變更備份作業的排程，也無法加以停用。

重要

  • 若為新的、已還原的或已複製的資料庫，時間點還原功能會在建立初始完整備份之後的初始交易記錄備份時變為可用。
  • 超大規模資料庫會在建立後立即受到保護，不同於初始備份需要時間的其他資料庫。 即使透過複製或還原以大量資料建立超大規模資料庫，仍會立即保護。 若要深入了解，請檢閱超大規模資料庫自動備份。

備份儲存體耗用量

透過使用 SQL Server 備份和還原技術，將資料庫還原至某個時間點需要不中斷的備份鏈結。 該鏈結包含一個完整備份、選擇性地包含一個差異備份，以及一或多個交易記錄備份。

Azure SQL 資料庫排程每週一次完整備份。 若要在整個保留期間內提供 PITR，系統必須儲存額外的完整、差異和交易記錄備份，且儲存時間最多比設定的保留期間長一週。

換句話說，對於保留期間內的任何時間點，都必須有早於保留期間最舊時間的完整備份。 也必須從該完整備份到下一次完整備份間的差異與交易記錄備份不中斷的鏈結。

超大規模資料庫使用不同的備份排程機制。 如需詳細資訊，請參閱超大規模資料庫備份排程。

不再需要用來提供 PITR 功能的備份會自動刪除。 由於差異備份與記錄備份需要有更早的備份才能還原，因此會每週將這三種類型的備份一起清除。

針對所有資料庫 (包括 TDE 加密資料庫)，所有完整和差異備份會經過壓縮以減少備份儲存體壓縮和成本。 平均備份壓縮比率為 3 到 4 倍。 不過，比率可能會根據資料的本質，以及資料庫中是否使用資料壓縮，而更低或更高。

重要

對於 TDE 加密的資料庫，基於效能考慮，記錄備份檔案不會壓縮。 非 TDE 加密資料庫的記錄備份會進行壓縮。

Azure SQL 資料庫會將您的使用期內備份儲存體總計計算為累計值。 每隔 1 小時便會向 Azure 計費管線回報此值。 此管道負責彙總此每小時使用量，以便在每個月底計算您的耗用量。 刪除資料庫之後，耗用量會減少，因為備份會達到年限並且刪除。 刪除所有備份且 PITR 無法再使用之後，就會停止計費。

重要

資料庫的備份會保留以提供 PITR，即使資料庫已刪除也一樣。 雖然刪除和重新建立資料庫可能會節省儲存體和計算成本，但是備份儲存體的成本可能會增加。 原因是每一次刪除資料庫時，服務都會保留每一個已刪除資料庫的備份。

監視耗用量

針對 Azure SQL 資料庫中的 vCore 資料庫，每種類型的備份 (完整、差異和記錄) 所使用的儲存體在資料庫監視窗格上報告為個別的計量。 下列螢幕擷取畫面顯示如何監視單一資料庫的備份儲存體耗用量。

此螢幕擷取畫面顯示 Azure 入口網站中監視資料庫備份耗用量的選項。

請參閱監視超大規模資料庫備份耗用量，以取得如何監視超大規模資料庫耗用量的指示。

微調備份儲存體耗用量

最多可達資料庫資料大小上限的備份儲存體使用量不會收費。 多餘的備份儲存體使用量取決於工作負載和個別資料庫的大小上限。 請考慮使用下列幾項微調技術，以減少備份儲存體耗用量：

  • 針對您的需求，將備份保留期間縮至最短。
  • 避免執行大型寫入作業 (如索引重建) 超過您所需的頻率。
  • 若是大型資料載入作業，請考慮使用叢集資料行存放區索引，並遵循相關的最佳做法。 另外，也請考慮減少非叢集索引的數目。
  • 在一般用途服務層級中，佈建的資料儲存體比備份儲存體的價格便宜。 如果您的超額備份儲存體成本一直很高，可以考慮增加資料儲存體，以節省備份儲存體。
  • 在您的應用程式邏輯中使用 tempdb 來儲存暫存結果或暫時性資料，而不使用永久資料表。
  • 如果可能的話，請使用本地備援備份儲存體 (例如開發/測試環境)。

備份保留

Azure SQL 資料庫提供備份的短期保留和長期保留。 短期保留可在資料庫的保留期間內進行 PITR。 長期保留則會針對各種合規性需求提供備份。

短期保留

所有新的、還原的和複製的資料庫，Azure SQL 資料庫都保留足夠的備份，預設允許過去 7 天內的 PITR。 服務會定期執行完整、差異和記錄備份，以確保資料庫可以還原至資料庫所定義保留期間內的任何時間點。

差異備份可以設定為在 12 小時或 24 小時內發生一次。 相較於 12 小時的頻率，24 小時的差異備份頻率可能會增加還原資料庫所需的時間。 在虛擬核心模型中，差異備份的預設頻率是 12 小時一次。 在 DTU 模型中，預設頻率為 24 小時一次。

您可以在建立資料庫時指定 STR 的備份儲存體備援選項，然後在稍後進行變更。 如果您在建立資料庫之後變更備份備援選項，新的備份將會使用新的備援選項。 不會移動或複製先前 STR 備援選項所做的備份複本。 這些備份會保留在原始儲存體帳戶中，直到保留期間到期為止，可能是 1 到 35 天。

您可以針對每個使用中資料庫變更備份保留期間，範圍是 1 到 35 天；基本資料庫除外，其可設定範圍為 1 到 7 天。 如備份儲存體耗用量所述，儲存以啟用 PITR 的備份可能會比保留期間還舊。 如果您需要保留備份的時間超過 35 天的短期保留期間上限，您可以啟用長期保留。

如果您刪除資料庫，系統保留備份的方式，就像保留具有特定保留期間的線上資料庫一樣。 您無法變更已刪除資料庫的備份保留期間。

重要

如果您刪除伺服器，則該伺服器上的所有資料庫也會一併刪除，且無法復原。 您無法還原已刪除的伺服器。 但是，如果您已為資料庫設定長期保留，則不會刪除 LTR 備份。 您才能使用這些備份，將資料庫還原至相同訂用帳戶中的不同資料庫，以及還原到建立 LTR 備份的時間點。 若要深入了解，請檢閱還原長期備份。

長期保留

對於 SQL Database，您可以在 Azure Blob 儲存體中設定長達 10 年的完整長期保留 (LTR) 備份。 設定 LTR 原則之後，每週都會自動將完整備份複製到不同的儲存體容器。

為了符合各種合規性需求，您可以針對每週、每月和/或每年完整備份選取不同的保留期限。 頻率因原則而異。 例如，設定 W=0, M=1 會在每月建立 LTR 複本。 如需 LTR 的詳細資訊，請參閱長期保留。

更新現有資料庫的備份儲存體備援，只會將變更套用至未來建立的後續備份，而不是針對現有的備份。 資料庫的所有現有 LTR 備份會繼續駐留在現有儲存體 Blob 中。 系統會根據設定的備份儲存體備援來複寫新的備份。

儲存體耗用量取決於選取的頻率和 LTR 備份的保留期間。 您可以使用 LTR 定價計算機來估算 LTR 儲存體的成本。

從 LTR 備份還原超大規模資料庫時，會停用讀取縮放屬性。 若要在已還原的資料庫上啟用讀取縮放，請在建立資料庫之後加以更新。 從 LTR 備份還原時，您必須指定目標服務等級目標。

可以為從其他服務層級建立或移轉的超大規模資料庫啟用長期保留。 如果您嘗試為尚不支援的超大規模資料庫啟用 LTR，會收到下列錯誤：「啟用此資料庫的長期備份保留時發生錯誤。 請連絡 Microsoft 支援，以啟用長期備份保留。」在此情況下，連絡 Microsoft 支援服務，並建立支援票證以解決此問題。

備份儲存體成本

備份儲存體的價格取決於您的購買模型 (DTU 或 vCore)、選擇的備份儲存體備援選項，以及區域。 備份儲存體會根據每個月耗用的 GB 來收費，與所有備份的費率相同。

備份儲存體備援會以下列方式影響備份成本：

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2

如需價格，請參閱 Azure SQL 資料庫定價頁面。

注意

Azure 發票只會顯示超額的備份儲存體耗用量，而不是整個備份儲存體耗用量。 例如，在假設的案例中，如果您已佈建 4 TB 的資料儲存體，您將會取得 4 TB 的可用備份儲存體空間。 如果您使用總計 5.8 TB 的備份儲存空間，Azure 發票只會顯示 1.8 TB，因為您只需要支付已使用的超額備份儲存體費用。

DTU 模型

在 DTU 模型中，對於資料庫和彈性集區，預設保留 7 天及以上的 PITR 備份儲存體不會額外收費。 PITR 備份儲存體的價格是資料庫或集區價格的一部分。

重要

在 DTU 模型中，資料庫和彈性集區會根據 LTR 備份所耗用的實際儲存體，針對 LTR 備份 儲存體收費。

虛擬核心模型

Azure SQL 資料庫會將所有可計費備份儲存體計算為所有備份檔案的累計值。 每隔 1 小時便會向 Azure 計費管線回報此值。 此管道會彙總此每小時使用量，以便在每個月底取得您的備份儲存體耗用量。

如果刪除了資料庫，備份儲存體耗用量將會逐漸降低，因為較舊的備份會達到年限並且刪除。 由於差異備份與記錄備份需要有更早的備份才能還原，因此會每週將這三種類型的備份一起清除。 刪除所有備份之後，就會停止計費。

超大規模資料庫會以不同的方式計算備份儲存體成本。 如需詳細資訊，請參閱超大規模資料庫儲存體成本。

針對單一資料庫，會提供等於資料庫資料儲存體上限 100% 的備份儲存體數量，不另外收取費用。 下列方程式用於計算可計費備份儲存體使用量總計：

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

針對彈性集區，會提供等於集區資料儲存體大小上限 100% 的備份儲存體數量，不另外收取費用。 對於集區資料庫，系統會在集區層級彙總可計費備份儲存體大小總計，其計算方式如下：

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

可計費備份儲存體總計 (如果有的話) 會依據所使用的備份儲存體備援費率，以每個月的 GB 為單位收費。 這個備份儲存體耗用量取決於工作負載和個別資料庫、彈性集區和受控執行個體的大小。 經過大量修改的資料庫具有較大的差異和記錄備份，因為這些備份的大小與變更的資料量成正比。 因此，這類資料庫有較高的備份費用。

簡單的範例是，假設資料庫累積 744 GB 的備份儲存體，而且這個數量因為資料庫完全閒置以致整個月都保持固定不變。 若要將此累計儲存體耗用量轉換成每小時使用量，請將此數量除以 744.0 (每月 31 天乘以 每天 24 小時)。 SQL Database 向 Azure 計費管線報告資料庫每小時耗用 1 GB 的 PITR 備份 (固定費率)。 Azure 帳單會彙總此耗用量，並顯示整個月的使用量為 744 GB。 費用會根據您區域每個月的 GB 費率而定。

以下是另一個範例。 假設同一個閒置資料庫的保留在當月的月中從 7 天增加至 14 天。 這項增加會導致備份儲存體總計加倍成為 1,488 GB。 SQL Database 會報告 1 到 372 個小時 (上半月) 有 1 GB 的使用量。 報告 373 到 744 個小時 (下半月) 有 2 GB 的使用量。 此使用量會彙總為每個月 1,116 GB 的最終帳單。

實際的備份計費案例更為複雜。 由於資料庫中的費率變更取決於工作負載，並且會隨著時間變動，因此每個差異和記錄備份的大小也會不同。 備份儲存體的每小時使用量會隨之波動。

每個差異備份也會包含自上次完整備份以來在資料庫中所做的所有變更。 因此，所有差異備份的總大小會隨著一週的進展而逐漸增加。 然後在較舊的完整、差異和記錄備份逾期之後，急遽下降。

例如，假設有大量寫入活動 (例如索引重建) 在完整備份完成之後執行。 則索引重建所做的修改將會包含在：

  • 在重建期間所建立的交易記錄備份中。
  • 在下一個差異備份中。
  • 在每個差異備份中，直到發生下一次的完整備份為止。

在較大型資料庫中，若是最後一個案例，如果差異備份會非常大，則服務中的最佳化會建立完整備份，而不是差異備份。 這樣會減少所有差異備份的大小，直到下次完整備份。

您可以監視一段時間內每種備份類型 (完整、差異、交易記錄) 的備份儲存體耗用量總計，如監視耗用量所述。

監視成本

若要了解備份儲存體成本，請移至 Azure 入口網站中的 [成本管理 + 計費]。 選取 [成本管理]，接著選取 [成本分析]。 針對 [範圍] 選取所需的訂用帳戶，然後篩選您感興趣的時間期間和服務，如下所示：

  1. 新增 [服務名稱] 的篩選條件。

  2. 在下拉式清單中，選取單一資料庫或彈性資料庫集區的 sql Database 。

  3. 為 [計量子類別] 新增其他篩選條件。

  4. 若要監視 PITR 備份成本，請在下拉式清單中針對單一資料庫或彈性資料庫集區選取 [單一/彈性集區 PITR 備份儲存體]。 只有在備份儲存體耗用量存在時，才會顯示計量。

    若要監視 LTR 備份成本，請在下拉式清單中針對單一資料庫或彈性資料庫集區選取 [LTR 備份儲存體]。 只有在備份儲存體耗用量存在時，才會顯示計量。

您可能會對 [儲存體] 和 [計算] 子類別感興趣，但其與備份儲存體成本無關。

顯示備份儲存體成本分析的螢幕擷取畫面。

重要

計量僅會針對目前使用中的計數器顯示。 如果無法使用計數器，可能是目前未使用該類別。 例如，不會對未使用儲存體的資源顯示儲存體計數器。 如果沒有 PITR 或 LTR 備份儲存體耗用量，就不會顯示這些計量。

如需詳細資訊，請參閱 Azure SQL 資料庫成本管理。

加密的備份

如果您的資料庫使用 TDE 加密，則備份會在靜止時自動加密 (包括 LTR 備份)。 Azure SQL 中所有新的資料庫預設都會設定為啟用 TDE。 如需 TDE 的詳細資訊，請參閱 SQL Database 的透明資料加密。

備份完整性

Azure SQL 工程小組會持續自動測試自動資料庫備份的還原。 進行時間點還原時，資料庫也會收到使用 DBCC CHECKDB 的完整性檢查。

完整性檢查期間找到任何問題時，都會對工程小組發出警示。 如需詳細資訊，請參閱 SQL Database 中的資料完整性。

系統會使用 CHECKSUM 選項來執行所有資料庫備份，以提供額外的備份完整性。

法規遵循

當您將資料庫從以 DTU 為基礎的服務層級，移轉至以虛擬核心為基礎的服務層級時，系統會保留時間點復原保留期，確保不會危害您應用程式的資料復原原則。 如果預設保留不符合合規性需求，您可以變更 PITR 保留期間。 如需詳細資訊，請參閱變更時間點復原備份保留期間。

注意

變更自動備份設定一文提供關於如何從裝置或服務刪除個人資料的步驟，並且可以用來支援遵循 GDPR 的義務。 如需 GDPR 的一般資訊，請參閱 Microsoft 信任中心的 GDPR 區段和服務信任入口網站的 GDPR 區段。

使用 Azure 原則來強制執行備份儲存體備援

如果您有資料落地需求，您必須將所有資料保留在單一 Azure 區域中，您可能想要使用 Azure 原則，針對您的 SQL 資料庫強制執行區域備援或本地備援的備份。

Azure 原則是一項服務，可讓您用來建立、指派和管理將規則套用至 Azure 資源的原則。 Azure 原則可協助讓這些資源符合您的公司標準及服務等級協定等規範。 如需詳細資訊，請參閱 Azure 原則概觀。

內建備份儲存體備援原則

若要在組織層級強制執行資料落地需求，您可以使用 Azure 入口網站或 Azure PowerShell，將原則指派給訂用帳戶。

例如，如果您啟用原則「Azure SQL DB 應該避免使用 GRS 備份」，就無法使用預設儲存體建立資料庫作為全域備援儲存體，而且使用者將無法使用 GRS，並出現錯誤訊息「將備份儲存體帳戶類型設定為『Standard_RAGRS』，在資料庫建立或更新期間失敗」。

如需 SQL Database 的內建原則定義完整清單，請檢閱原則參考。

重要

您透過 T-SQL 建立資料庫時，不會強制執行 Azure 原則。 若要在使用 T-SQL 建立資料庫時指定資料落地，請在 CREATE DATABASE 陳述式中使用 'LOCAL' 或 'ZONE' 做為 BACKUP_STORAGE_REDUNDANCY 參數的輸入。

相關內容