適用於：
Azure SQL 資料庫
本文說明 Azure SQL 資料庫的自動備份功能。
若要變更備份設定，請參閱變更設定。 若要還原備份，請參閱使用自動資料庫備份進行復原。
什麼是資料庫備份？
資料庫備份有助於保護您的資料免於損毀或刪除，是商務持續性和災害復原策略中不可或缺的一部分。 這些備份可在設定的保留期間內讓資料庫還原至特定時間點。 如果您的資料保護規則要求備份必須能夠延長使用 (最長至 10 年)，您可以同時為單一和集區資料庫設定長期保留 (LTR)。
對於超大規模資料庫以外的服務層級，Azure SQL 資料庫會使用 SQL Server 引擎技術來備份和還原資料。 超大規模資料庫會使用基於儲存快照的備份和還原。 傳統 SQL Server 備份技術使大型資料庫的備份與還原時間較長。 透過快照，Hyperscale 無論資料庫大小，都能提供即時備份與快速還原功能。 若要深入瞭解，請參閱超大規模資料庫備份。
備份頻率
Azure SQL 資料庫會建立：
交易日誌備份的確切頻率取決於運算規模與資料庫活動量。 當你還原資料庫時，Azure SQL Database 會決定要還原哪些完整、差異及交易日誌備份。
超大規模資料庫結構不需要完整備份、差異備份或記錄備份。 若要深入瞭解，請參閱超大規模資料庫備份。
備份儲存體冗餘
儲存冗餘機制會儲存多份資料，以防計畫內外事件的干擾。 這些事件可能涵蓋暫時性的硬體失敗、網路或電力中斷，或重大自然災害。
依預設，Azure SQL 資料庫中的新資料庫會將備份存放在地理冗餘的儲存體 Blob中，並複製到配對區域。 異地備援有助於防止會影響主要區域中備份儲存體的中斷。 它也可讓您在發生區域性中斷時，在不同的區域中還原資料庫。
Azure 入口網站提供工作負載環境選項，可協助預先設定部分組態設定。 你可以覆寫這些設定。 此選項僅適用於 [建立 SQL Database] 入口網站頁面。
- 選擇開發工作負載環境會設定備份儲存體備援選項，以使用本地備援儲存體。 本地冗餘儲存方案成本較為低廉，適用於不需要區域或地理複寫儲存冗餘的預生產環境。
- 選擇 生產 工作負載環境會將 備份儲存體備援 設定為異地備援儲存體，這是預設值。
- 工作負載環境選項也會改變初始計算設定，但你可以覆寫這個設定。 否則，[工作負載環境] 選項對授權或其他資料庫組態設定沒有任何影響。
為確保備份仍停留在資料庫部署區域內，請將備份備份冗餘從預設的地理冗餘儲存改為其他類型的儲存裝置，將資料保持在該區域內。 設定的備份儲存體備援會套用至短期保留 (Short-Term Retention, STR) 備份和長期保留 (Long-Term Retention, LTR) 備份。 若要深入了解儲存體備援，請參閱資料備援。
你可以在建立資料庫時設定備份儲存冗餘，之後也可以更新。 你對現有資料庫所做的變更只會適用於未來的備份。 您更新現有資料庫的備份儲存體備援之後，最多可能需要 48 小時才會套用變更。
您可以選擇下列其中一個備份的儲存體冗餘：
本地備援儲存體 (LRS)：在主要區域的單一實體位置內，同步複製您的備份三次。 LRS 是成本最低的儲存選項，但不建議用於需要區域性中斷韌性或高資料穩定性保證的應用。
區域備援儲存體 (ZRS)：將您的備份同步複製到主要區域中的三個 Azure 可用性區域。 目前僅在特定地區提供服務。
異地備援儲存體 (GRS)：透過使用 LRS，在主要區域中的單一實體位置內，同步複製您的備份三次。 然後，它會以異步方式將數據複製到 配對次要區域中的單一實體位置三次。
結果如下：
- 有三個同步複本在主要區域。
- 有三個同步複本在配對區域，這些複本是以非同步方式從主要區域複製到次要區域。
Geo-Zone 冗餘儲存（GZRS）：地理區域冗餘儲存（GZRS）結合了跨可用區冗餘（ZRS）所提供的高可用性，以及地理複製（GRS）所提供的區域中斷保護。 在 GZRS 中，Azure 會在主要區域的三個 Azure 可用性區域之間同步複製您的備份，並以非同步方式再複製三次到配對的次要區域中的單一實體位置。
Microsoft 建議針對需要最大一致性、持久性、可用性、絕佳效能，以及針對災害復原恢復的應用程式使用 GZRS。
結果如下：
主要區域中跨 可用性區域的三個同步複本。
配對區域中的三個同步複本，以異步方式從主要區域複製到次要區域。
下圖顯示使用 GZRS 或 RA-GZRS 複寫資料的方式：
警告
- 當資料庫更新為使用本地或區域備援儲存體時，就會立即停用異地還原。
- 所有儲存體備援的圖都會顯示具有多個可用性區域 (multi-az) 的區域。 然而，有些地區只提供單一可用區，且不支援 ZRS。
- 你只能在建立超大規模資料庫時設定備份儲存冗餘。 佈建資源之後，您無法修改此設定。 若要以最短停機時間更新現有超大規模資料庫的備份儲存體備援設定，請使用作用中異地複寫。 或者，您可以使用資料庫複本。 若要深入了解，請參閱超大規模資料庫備份和儲存體備援。
備份使用量
在以下情境下使用自動建立的備份：
使用 Azure 入口網站、Azure PowerShell、Azure CLI 或 REST API，在保留期間內將現有的資料庫還原至過去的時間點。 此作業會在原始資料庫的相同伺服器上建立新資料庫，但使用不同的名稱來避免覆寫原始資料庫。
在還原完成後，您可以選擇性刪除原始資料庫，然後將還原的資料庫重新命名為原始資料庫的名稱。 或者，您可以不刪除原始資料庫並且重新命名，然後將還原的資料庫重新命名為原始的資料庫名稱。
將已刪除的資料庫還原至保留期間內的時間點，包括刪除的時間在內。 你只能在建立原始資料庫的同一台伺服器上還原被刪除的資料庫。 在刪除資料庫前，Azure SQL Database 會進行最後的交易日誌備份，以防止資料遺失。
將資料庫還原到其他地理區域。 地理還原能幫助你從區域故障中恢復，當你無法存取主要區域的資料庫或備份時。 會在任何 Azure 區域中的任何現有伺服器上建立新的資料庫。
重要
異地還原僅適用於已設定異地備援備份儲存體的資料庫。 如果你目前沒有使用地理複製備份來管理資料庫，可以透過 設定備份儲存冗餘來更改此設定。
若資料庫已設定 LTR 政策，則可從單一或池化資料庫的特定長期備份還原資料庫。 LTR 可讓您使用 Azure 入口網站、Azure CLI 或 Azure PowerShell 來還原舊版資料庫，以符合規範要求或執行舊版應用程式。 如需詳細資訊，請參閱長期保存。
警告
當還原資料庫且來源備份儲存冗餘配置為 Geo-Zone 冗餘儲存（GZRS）時，若未明確指定備份備份冗餘配置，新資料庫將繼承原始備份儲存的配置。 此繼承適用於任何還原操作，例如點點還原、資料庫複製、地理還原，以及從長期備份還原。 在此操作期間，若目標 Azure 區域不支援特定的備份儲存冗餘，還原操作將失敗並出現適當的錯誤訊息。 你可以透過明確指定該區域可用的儲存選項來減輕這個錯誤。
在次要複本上進行自動備份
商業關鍵服務層級則從次要副本自動備份。 由於資料會在每個節點上的 SQL Server 進程之間複寫，因此備份服務會從不可讀取次要複本取得備份。 此設計可確保主要複本仍專用於主要工作負載，而可讀取次要複本則專用於唯讀工作負載。 業務關鍵服務層級中的自動備份主要取自次要複本。 如果自動備份在次要副本上失敗，備份服務會從主要副本中取得備份。
次要複本上的自動備份
- 預設啟用。
- 已包含在服務層級的價格中，無需支付額外費用。
- 提升業務關鍵服務層級的效能和可預測性。
注意
建立 Microsoft 支援服務票證，以便停用您執行個體的功能。
恢復功能和特性
下表摘要說明時間點還原 (PITR)、異地還原和長期保留的功能和特性。
如需復原時間的相關信息，請參閱 RTO 和 RPO。
| 備份屬性 | PITR | 異地復原 | LTR |
|---|---|---|---|
| SQL 備份的類型 | 完整、差異、記錄。 | PITR 備份的最新異地複寫複本。 | 僅限於完整備份。 |
| 保留 | 預設為 7 天，可設定為介於 1 到 35 天之間的值 (基本資料庫除外，可設定為介於 1 到 7 天之間)。 | 預設為啟用，與來源相同。2 | 預設不啟用。 保留最多 10 年。 |
| Azure 儲存體 | 預設具有異地備援功能。 您可以選擇設定區域備援或本地備援儲存體。 | 當 PITR 備份儲存冗餘設定為地理冗餘或地理區域冗餘（GZRS）時，可用。 若 PITR 備份儲存體為區域備援或本地備援時，則不可用。 | 預設具有異地備援功能。 您可以設定區域備援或本地備援儲存體。 |
| 將備份設定為 [不可變] | 不支援 | 不支援 | Supported |
| 在相同區域中恢復新資料庫 | 支援 | 支援 | 支援 |
| 在另一個區域復原新的資料庫 | 不支援 | 在任何 Azure 區域中都支援 | 在任何 Azure 區域中都支援 |
| 在另一個訂用帳戶中還原新資料庫 | 不支援 | 不支援3 | 不支援3 |
| 透過 Azure 入口網站還原 | 是的 | 是的 | 是的 |
| 透過 Powershell 還原 | 是的 | 是的 | 是的 |
| 透過 Azure CLI 還原 | 是的 | 是的 | 是的 |
1 對於需要大型資料庫且必須確保商務持續性的業務關鍵應用程式，請使用容錯移轉群組。
2 預設會將所有 PITR 備份儲存在異地備援儲存體上，因此，預設值為啟用異地還原。
3 因應措施是還原至新的伺服器，並使用「資源移動」將伺服器移至另一個訂用帳戶，或使用跨訂用帳戶資料庫複製。
從備份還原資料庫
欲了解更多關於還原資料庫的資訊，請參閱 從備份還原資料庫。 要探索備份設定與還原操作，請參考以下範例。
| 作業 | Azure 入口網站 | Azure CLI | Azure PowerShell |
|---|---|---|---|
| 變更備份保留期 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
| 變更長期備份保留期 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
| 從某個時間點還原資料庫 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
| 還原已刪除的資料庫 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
SQL 資料庫 SQL 受控執行個體 |
注意
目前不支援在 Hyperscale 服務層級與 Azure SQL Database 其他服務層級之間還原資料庫。
匯出資料庫
你無法下載或直接存取 Azure 服務自動備份。 Azure 只用這些備份來做還原操作。
要匯出 Azure SQL Database，請考慮其他替代方案。
- 當你需要匯出資料庫以進行歸檔或遷移到其他平台時，請將 資料庫架構和資料匯出 成 BACPAC 檔案。 BACPAC 檔案是一種副檔名為 BACPAC 的 ZIP 檔案，其中包含來自資料庫的中繼資料和資料。 你可以將 BACPAC 檔案儲存在 Azure Blob 儲存體中，或儲存在內部部署位置的本機儲存體中。 之後你可以把它匯入回 Azure SQL Database、Azure SQL 受控執行個體 或 SQL Server 實例。
- 您也可以使用私人連結匯入或匯出 Azure SQL 資料庫或匯入或匯出 Azure SQL 資料庫，但不允許 Azure 服務存取伺服器。
備份排程設定
第一次完整備份會在建立或還原新資料庫後立即排程。 此備份通常會在 30 分鐘內完成，但如果資料庫很大，則所需時間可能更久。 例如，初始備份在還原的資料庫或資料庫副本上可能會花更長時間。
在第一次完整備份完成後，Azure 會自動排程並管理所有後續備份。 SQL 資料庫服務會精確決定所有資料庫備份的時間，以平衡整體系統的工作負載。 您無法變更備份作業的排程，也無法加以停用。
重要
- 若為新的、已還原的或已複製的資料庫，時間點還原功能會在建立初始完整備份之後的初始交易記錄備份時變為可用。
- 超大規模資料庫會在建立後立即受到保護，不同於初始備份需要時間的其他資料庫。 即使 Hyperscale 資料庫是透過複製或還原所建立，且在建立時已包含大量資料，保護仍會立即生效。 欲了解更多資訊，請參閱 超大規模自動化備份。
備份儲存體耗用量
透過使用 SQL Server 備份和還原技術，將資料庫還原至某個時間點需要不中斷的備份鏈結。 該鏈結包含一個完整備份、選擇性地包含一個差異備份，以及一或多個交易記錄備份。
Azure SQL 資料庫排程每週一次完整備份。 為了在整個保留期內提供 PITR，Azure 必須儲存額外的完整、差異及交易日誌備份，最多可比設定的保留期多一週。
換句話說，對於保留期間內的任何時間點，都必須有早於保留期間最舊時間的完整備份。 必須確保從該完整備份到下一次完整備份之間存在不中斷的差異備份和交易日誌備份鏈。
超大規模資料庫使用不同的備份排程機制。 如需詳細資訊，請參閱超大規模資料庫備份排程。
Azure 會自動刪除不再需要提供 PITR 功能的備份。 由於差分備份和日誌備份需要較早的完整備份才能恢復，Azure 會每週一次將三種備份類型一起清除。
對於所有資料庫，包括 TDE 加密的資料庫，Azure 會壓縮所有完整與差異備份，以降低備份儲存壓縮與成本。 平均備用壓縮比約為三到四倍。 不過，比率可能會根據資料的本質，以及資料庫中是否使用資料壓縮，而更低或更高。
重要
對於 TDE 加密的資料庫，Azure 不會壓縮日誌備份檔案，出於效能考量。 對於非TDE加密的資料庫，日誌備份會被壓縮。
Azure SQL 資料庫會將您的使用期內備份儲存體總計計算為累計值。 Azure 每小時都會向帳單流程報告這個數值。 此管道負責彙總此每小時使用量，以便在每個月底計算您的耗用量。 刪除資料庫後，隨著備份過時並被刪除，消耗量會減少。 刪除所有備份且 PITR 無法再使用之後，就會停止計費。
重要
Azure 會保留資料庫的備份，即使你刪除資料庫，也能提供 PITR。 雖然刪除和重新建立資料庫可能會節省記憶體和計算成本，但可能會增加備份記憶體成本。 原因是 Azure 每次刪除資料庫都會保留備份。
監視耗用量
對於 Azure SQL Database 中的 vCore 資料庫，資料庫監控窗格會將每種備份類型（完整備份、差分備份和日誌備份）所消耗的儲存空間作為獨立的指標。 下列螢幕擷取畫面顯示如何監視單一資料庫的備份儲存體耗用量。
請參閱監視超大規模資料庫備份耗用量，以取得如何監視超大規模資料庫耗用量的指示。
微調備份儲存體耗用量
只要備份儲存體用量不超過資料庫的最大資料大小，就不會收費。 為了減少備份儲存空間的消耗，可以考慮以下幾項調整技巧：
- 針對您的需求，將備份保留期間縮至最短。
- 避免執行大型寫入作業 (如索引重建) 超過您所需的頻率。
- 若是大型資料載入作業，請考慮使用叢集資料行存放區索引，並遵循相關的最佳做法。 另外，也請考慮減少非叢集索引的數目。
- 在一般用途服務層級中，佈建的資料儲存體比備份儲存體的價格便宜。 如果你持續有高額的備份儲存費用，可以考慮增加資料儲存以節省備份儲存的成本。
- 在您的應用程式邏輯中使用
tempdb來儲存暫存結果或暫時性資料，而不使用永久資料表。 - 如果可能的話，請使用本地備援備份儲存體 (例如開發/測試環境)。
備份保留
Azure SQL 資料庫提供備份的短期保留和長期保留。 短期保留允許在資料庫的保留時效內執行 PITR。 長期保留則會針對各種合規性需求提供備份。
短期保留
對於所有新建、還原及複製的資料庫，Azure SQL Database 預設保留足夠的備份，允許在過去七天內進行 PITR。 Azure SQL Database 會定期進行完整、差異及日誌備份，以確保資料庫能在保留期間內恢復至任何時間點。
你可以設定差分備份每 12 小時或每 24 小時一次。 相較於 12 小時的頻率，24 小時的差異備份頻率可能會增加還原資料庫所需的時間。 在虛擬核心模型中，差異備份的預設頻率是 12 小時一次。 在 DTU 模型中，預設頻率為 24 小時一次。
您可以在建立資料庫時為 STR 指定備份儲存體備援選項，之後再加以變更。 如果你更改現有資料庫的備份冗餘選項，新的備份也會使用新的冗餘選項。 Azure 不會移動或複製之前用短期冗餘選項製作的備份副本。 Azure 會將這些資料留在原始儲存帳戶，直到保留期限結束，期限可為 1 至 35 天。
您可以針對每個使用中資料庫變更備份保留期間，範圍是 1 到 35 天；基本資料庫除外，其可設定範圍為 1 到 7 天。 如備份儲存體耗用量所述，儲存以啟用 PITR 的備份可能會比保留期間還舊。 如果您需要保留備份的時間超過 35 天的短期保留期間上限，您可以啟用長期保留。
如果你刪除資料庫，Azure 也會以相同方式保存線上資料庫的備份，並有特定的保留期限。 您無法變更已刪除資料庫的備份保留期間。
重要
如果你刪除一個邏輯 Azure SQL 伺服器，也會刪除該邏輯伺服器上的所有資料庫。 你無法恢復已刪除的資料庫。 你無法還原已刪除的邏輯伺服器。 但如果你設定了資料庫的長期保留，LTR 備份就不會被刪除。 你可以用這些備份，在同一訂閱中還原另一台邏輯伺服器上的資料庫，回到有 LTR 備份的那個時間點。 欲了解更多資訊，請參閱 恢復長期備份。
長期保留
對於 SQL Database，您可以在 Azure Blob 儲存體中設定長達 10 年的完整長期保留 (LTR) 備份。 設定 LTR 政策後，Azure 會自動每週將完整備份複製到不同的儲存容器。
為符合各種合規要求，請選擇不同的保留期，分別為每週、每月及每年的完整備份。 頻率因原則而異。 例如，將 W=0, M=1 設為每月建立一個 LTR 副本。 如需 LTR 的詳細資訊，請參閱長期保留。
更新現有資料庫的備份儲存冗餘只會將變更套用於未來後續的備份，而非現有備份。 資料庫的所有現有 LTR 備份會繼續駐留在現有儲存體 Blob 中。 系統會根據設定的備份儲存體備援來複寫新的備份。
儲存體耗用量取決於選取的頻率和 LTR 備份的保留期間。 使用 LTR 價格計算器 來估算 LTR 儲存體的成本。
從 LTR 備份還原超大規模資料庫時，會停用讀取縮放屬性。 若要在已還原的資料庫上啟用讀取縮放功能，請在建立資料庫後更新它。 從 LTR 備份還原時，您必須指定目標服務等級目標。
你可以為從其他服務層級建立或遷移而來的超大規模資料庫啟用長期保留。 如果您嘗試為尚不支援的超大規模資料庫啟用 LTR，會收到下列錯誤：「啟用此資料庫的長期備份保留時發生錯誤。 請聯絡 Microsoft 客服以啟用長期備份保留。」此時，請聯絡 Microsoft 客服並建立支援單以解決問題。
備份儲存體成本
備份儲存體的價格取決於您的購買模型 (DTU 或 vCore)、選擇的備份儲存體備援選項，以及區域。 你是根據每月消耗的 GB 容量來支付備份儲存費，所有備份的費率都是一樣的。
如需價格，請參閱 Azure SQL 資料庫定價頁面。
注意
Azure 發票只會顯示超額的備份儲存體耗用量，而不是整個備份儲存體耗用量。 舉例來說，假設你配置了 4 TB 的資料儲存空間，你會獲得 4 TB 的備用儲存空間。 如果你總共使用 5.8 TB 的備份儲存空間，Azure 發票只會顯示 1.8 TB，因為你只支付多餘備份儲存的費用。
DTU 模型
在 DTU 模型中，對於資料庫和彈性池，PITR 備份儲存對於預設保留七天及以上不會額外收費。 PITR 備份儲存的價格包含在資料庫或池價中。
在 DTU 模型中，你是根據 LTR 備份實際消耗的儲存量來支付資料庫和彈性池的 LTR 備份 儲存費用。
虛擬核心模型
Azure SQL Database 會將你所有備份檔案的總可計費備份儲存值作為累積值計算。 Azure 每小時都會將這個數值傳送到帳單流程。 管線會將這些每小時的使用量彙總，以計算你每月結束時的備份儲存用量。
如果你刪除資料庫，隨著舊備份的老化和刪除，備份儲存的消耗會逐漸減少。 由於差分備份和日誌備份需要較早的完整備份才能恢復，Azure 會每週一次將三種備份類型一起清除。 刪除所有備份之後，就會停止計費。
超大規模資料庫則使用不同的方法來計算備份儲存成本。 如需詳細資訊，請參閱超大規模資料庫儲存體成本。
對於單一資料庫，你可以免費獲得等於資料庫最大資料儲存容量的備份容量。 以下方程式計算出總可計費備份儲存使用量：
Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage
對於彈性池，你會獲得等於池容量最大資料儲存量的備份儲存量，且不會額外收費。 對於集區資料庫，系統會在集區層級彙總可計費備份儲存體大小總計，其計算方式如下：
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 資料庫報告第 1 至 372 小時（每月上半月）的使用量為 1 GB。 它報告第 373 到 744 小時（下半月）的使用量為 2 GB。 這些用量加總後，最終每月總計為 1,116 GB。
實際的備份計費案例更為複雜。 由於資料庫變更速率取決於工作負載且隨時間變化，因此每個差分備份與日誌備份的大小也會有所不同。 備份儲存體的每小時使用量會隨之波動。
每個差異備份也會包含自上次完整備份以來在資料庫中所做的所有變更。 因此，所有差異備份的總大小會隨著一週的進展而逐漸增加。 然後在一組較舊的完整、差異和記錄備份過期之後，急遽下降。
例如，假設有大量寫入活動 (例如索引重建) 在完整備份完成之後執行。 指數重建所做的修改包括：
- 在重建期間所建立的交易記錄備份中。
- 在下一個差異備份中。
- 在每次差異備份中，直到下一次完整備份發生為止。
在較大資料庫的最後一種情境中，Azure 的優化會建立完整備份，而非差異備份，否則差異備份會過於龐大。 此優化可減少所有差分備份的大小，直到下一次完整備份。
您可以監視一段時間內每種備份類型 (完整、差異、交易記錄) 的備份儲存體耗用量總計，如監視耗用量所述。
監視成本
若要了解備份儲存體成本，請移至 Azure 入口網站中的 [成本管理 + 計費]。 選取 [成本管理]，接著選取 [成本分析]。 選取範圍的所需訂閱，然後篩選您感興趣的時間範圍和服務，如下所示：
新增 [服務名稱] 的篩選條件。
在下拉式清單中，選取 sql Database 來配置為單一資料庫或彈性資料庫集區。
為 [儀表子類別] 新增篩選條件。
若要監視 PITR 備份成本，請在下拉式清單中針對單一資料庫或彈性資料庫集區選取 [單一/彈性集區 PITR 備份儲存體]。 只有在備份儲存體耗用量存在時，才會顯示計量。
若要監視 LTR 備份成本，請在下拉式清單中針對單一資料庫或彈性資料庫集區選取 [LTR 備份儲存體]。 只有在備份儲存體耗用量存在時，才會顯示計量。
您可能會對 [儲存體] 和 [計算] 子類別感興趣，但其與備份儲存體成本無關。
重要
計量僅會針對目前使用中的計數器顯示。 如果計數器無法使用，則類別可能目前未使用。 例如，對於未消耗儲存空間的資源，儲存計數器是看不到的。 如果沒有 PITR 或 LTR 備份儲存體用量，這些計量將不會顯示。
如需詳細資訊，請參閱 Azure SQL 資料庫成本管理。
加密的備份
如果你用 TDE 加密資料庫，備份會自動在靜態時加密，包括 LTR 備份。 Azure SQL 中所有新的資料庫預設都會設定為啟用 TDE。 如需 TDE 的詳細資訊，請參閱 SQL Database 的透明資料加密。
備份完整性
Azure SQL Database 在需要時會自動使用內建技術處理某些類型的資料損毀，且不會造成資料遺失。 在 Azure SQL Database 中，SQL 資料庫引擎 會在服務管理備份及每次還原操作中執行頁面驗證。 完整性檢查期間找到任何問題時，都會對工程小組發出警示。
作為額外的保護層，你可以測試備份還原並執行完整性檢查。 欲了解更多資訊，請參閱 Azure SQL Database 中的資料完整性。
所有資料庫備份都會使用 CHECKSUM 這個選項來提供額外的備份完整性。
備份保護
Microsoft 擁有的 Azure 訂閱透過安全的內部 Azure 儲存體 帳號管理 Azure SQL Database 備份。 這些備份無法外部存取，因此它們提供了強大的資料隔離與保護。 在 Microsoft 內部，只有後端服務能存取、建立、複製或還原這些備份。 Microsoft工程師，包括開發人員，沒有常設存取權。 若要將暴露程度降到最低並最大化安全性，Microsoft在絕對必要的情況下，只能在嚴格的稽核控制下取得 Just-In-Time （JIT） 存取權，以針對特定客戶問題進行疑難解答。
備份會在保留期限屆滿後自動刪除。
透過保留備份實現合規性
如果預設保留期限不符合你的合規要求，請更改PITR保留期限。 如需詳細資訊，請參閱變更時間點復原備份保留期間。
當你將資料庫從基於 DTU 的服務層遷移到 vCore 服務層級時，遷移過程中會保留 PITR 的保留權，以確保你的應用程式資料復原政策不會被破壞。
注意
關於如何在 Azure SQL Database 備份中刪除個人資料以支持GDPR義務的步驟，請參閱「變更自動備份設定」。 如需 GDPR 的一般資訊，請參閱 Microsoft 信任中心的 GDPR 區段和服務信任入口網站的 GDPR 區段。
使用 Azure 原則來強制執行備份儲存體備援
如果您的資料駐留需求要求您將所有資料保留在單一 Azure 區域中，您可以使用 Azure 原則，為您的 SQL 資料庫強制執行區域備援備份或本機備援備份。
Azure 原則是一項服務，可讓您用來建立、指派和管理將規則套用至 Azure 資源的原則。 Azure 原則 幫助您保持這些資源符合企業標準與服務水準協議。 如需詳細資訊，請參閱 Azure 原則概觀。
內建備份儲存體備援原則
若要在組織層級強制執行資料駐留要求，請使用 Azure 入口網站或 Azure PowerShell 為訂閱指派政策。
舉例來說，如果你啟用「Azure SQL DB 應避免使用 GRS 備份」這個政策，使用者就無法將預設儲存空間當作全球冗餘儲存來建立資料庫。 該政策阻止使用者使用 GRS，並回傳錯誤訊息：「在資料庫建立或更新時，將備份儲存帳號類型配置為 'Standard_RAGRS' 失敗。」
如需完整的 SQL 資料庫內建政策定義清單，請參閱 政策參考文獻。
重要
當你用 T-SQL 建立資料庫時，Azure 政策並不會被強制執行。 在使用 T-SQL 建立資料庫時，若要指定資料駐留點，請 在 CREATE DATABASE 語句中的 BACKUP_STORAGE_REDUNDANCY 參數中輸入 LOCAL 或 ZONE。
相關內容
- 若要深入了解其他 SQL Database 商務持續性解決方案，請參閱商務持續性概觀。
- 若要變更備份設定，請參閱變更設定。
- 若要還原備份，請參閱使用備份復原，或使用 PowerShell 將資料庫還原到某個時間點。
- 如需如何在 Azure Blob 儲存體中設定和管理自動備份的長期保留，並從長期保留還原的相關資訊，請參閱管理長期備份保留期。
- 針對 Azure SQL 受控執行個體，請參閱自動備份 SQL 受管理執行個體。