適用於：
Azure SQL DatabaseAzure SQL 受控執行個體
本文提供 Azure SQL Database 與 Azure SQL 受控執行個體 長期保留（LTR）備份的概念性概述。 Azure SQL Database（包括超大規模服務層級）及 Azure SQL 受控執行個體 的備份，可設定長達 10 年的長期保留。
若要開始使用長期保留備份功能，請參閱：
重要
部分用於長期保留（LTR）備份操作的舊 API 已被棄用且不再支援。 避免使用舊版的 PowerShell Cmdlet，例如 Copy-AzSqlDatabaseLongTermRetentionBackup。 請改用本文所描述的支援還原方法。
長期保留的運作方式
許多應用程式因為法規要求、合規性或其他商業原因，需要保留資料庫備份的時間超過自動備份的短期保留期（1-35 天）。 長期備份保留（LTR）依賴由 Azure SQL 服務自動建立的完整資料庫備份。 更多資訊請參閱Azure SQL Database<>中的
透過使用 LTR 功能，你可以將指定的完整 SQL 資料庫和 SQL 受管理執行個體 備份儲存在冗餘的 Azure Blob 儲存空間中，並可設定最多可設定 10 年的保留政策。 接著可將 LTR 備份還原為新的資料庫。 如果已設定 LTR 原則，系統會將自動備份複製到不同的 Blob，以供長期記憶體使用，然後用來將資料庫還原至特定時間點。 複製程式是背景作業，對資料庫工作負載沒有效能影響。 每個資料庫的 LTR 原則也可以指定建立 LTR 備份的頻率。
注意
若要啟用 LTR，您可以用這四個參數的組合定義原則：每週備份保留 (W)、每月備份保留 (M)、每年備份的保留期 (Y) 及年度週次 (WeekOfYear)。 如果指定 W，每週一次的備份會複製到長期儲存體。 如果指定 M，每月的第一個備份會複製到長期儲存體。 如果指定為 Y，則會將在 WeekOfYear 所指定的那一週進行的一次備份複製到長期儲存區中。 如果在設定原則時指定的 WeekOfYear 為過去時間，則將在明年建立第一個 LTR 備份。 每個備份都會根據建立 LTR 備份時所設定的原則參數，保留在長期儲存體中。
LTR 原則的變更僅適用於未來的備份。 例如，如果您修改每周備份保留期 （W）、每月備份保留期 （M），或每年備份保留期 （Y），新的保留設定只適用於新的備份。 不會修改現有備份的保留期。 LTR 政策可以在 Azure SQL Database 和 Azure SQL 受控執行個體 中的每個資料庫中設定。 如果您想要在保留期間到期之前刪除舊的 LTR 備份，您可以 手動刪除備份。
注意
在 Azure SQL Database 和 Azure SQL 受控執行個體 中，當你首次啟用資料庫的 LTR 政策時，最近一次從點點還原（PITR）的完整備份會被複製到長期儲存。
LTR 原則的範例：
W=0, M=0, Y=5, WeekOfYear=3每年的第三個完整備份會保留五年。
W=0, M=3, Y=0每月的第一個完整備份會保留三個月。
W=12, M=0, Y=0每個每週完整備份皆會保留 12 週。
W=6, M=12, Y=10, WeekOfYear=20每個每週完整備份皆會保留六週。 但每月的第一個完整備份除外，這個備份會保留 12 個月。 每年第 20 週的完整備份除外，這個備份將保留 10 年。
下表說明以下原則的長期備份日程和到期日：
W=12 weeks （84天）、 M=12 months （365天）、 Y=10 years （3650天）、 WeekOfYear=20 （5月13日後一周）
以下日期遵循 ISO 8601 格式（YYYY-MM-DD）。
| PITR 備份至 LTR | 到期 W | 到期 M | 到期 Y |
|---|---|---|---|
| 2018 年 3 月 7 日 | 2019-03-02 | ||
| 2018 年 3 月 14 日 | 2018 年 6 月 6 日 | ||
| 2018 年 3 月 21 日 | 2018 年 6 月 13 日 | ||
| 2018 年 3 月 28 日 | 2018 年 6 月 20 日 | ||
| 2018 年 4 月 4 日 | 2019-03-30 | ||
| 2018 年 4 月 11 日 | 2018 年 7 月 4 日 | ||
| 2018 年 4 月 18 日 | 2018 年 7 月 11 日 | ||
| 2018 年 4 月 25 日 | 2018 年 7 月 18 日 | ||
| 2018 年 5 月 2 日 | 2019-04-27 | ||
| 2018 年 5 月 9 日 | 2018 年 8 月 1 日 | ||
| 2018 年 5 月 16 日 | 2028 年 5 月 13 日 | ||
| 2018 年 5 月 23 日 | 2018 年 8 月 15 日 | ||
| 2018 年 5 月 30 日 | 2018 年 8 月 22 日 | ||
| 2018 年 6 月 6 日 | 2019-06-01 | ||
| 2018 年 6 月 13 日 | 2018 年 9 月 5 日 | ||
| 2018 年 6 月 20 日 | 2018 年 9 月 12 日 | ||
| 2018 年 6 月 27 日 | 2018 年 9 月 19 日 | ||
| 2018 年 7 月 4 日 | 2019-06-29 | ||
| 2018 年 7 月 11 日 | 2018 年 10 月 3 日 | ||
| 2018 年 7 月 18 日 | 2018 年 10 月 10 日 | ||
| 2018 年 7 月 25 日 | 2018 年 10 月 17 日 | ||
| 2018 年 8 月 1 日 | 2019-07-27 | ||
| 2018 年 8 月 8 日 | 2018 年 10 月 31 日 | ||
| 2018 年 8 月 15 日 | 2018 年 11 月 7 日 | ||
| 2018 年 8 月 22 日 | 2018 年 11 月 14 日 | ||
| 2018 年 8 月 29 日 | 2018 年 11 月 21 日 |
如果您修改此原則並設定 W=0 （沒有每周備份），則每周備份會保留到備份到期為止，然後服務只會保留每月和每年的備份。 未來的每周備份不會儲存在 LTR 原則下。 保留這些備份所需的儲存體數量會隨之減少。
重要
個別 LTR 備份的時間由 Microsoft 控制。 您無法手動建立 LTR 備份或控制備份建立時機。 設定 LTR 原則之後，可能需要最多七天的時間，第一個 LTR 備份才會顯示在可用的備份清單中。
如果您刪除邏輯伺服器或 SQL 受控實例，也會刪除該伺服器或受控實例上的所有資料庫。 您無法還原已刪除的邏輯伺服器或 SQL 受控實例。 不過，如果您已針對資料庫設定 LTR，則 LTR 備份將不會被刪除，並且可以用於將資料庫還原至相同訂用帳戶中的不同伺服器或受管理的實例，還原到進行 LTR 備份的時間點。
同樣地，如果您刪除資料庫，不會刪除 LTR 備份，並保留已設定的保留期間。 這些備份可以還原到相同伺服器或相同訂用帳戶內的不同伺服器。
異地複寫和長期備份保留
如果您使用主動式異地復寫或故障轉移群組作為商務持續性解決方案，請準備應對可能的故障轉移，並在次要資料庫或實例上設定與主要資料庫或實例相同的 LTR 原則。 您的 LTR 記憶體成本不會增加，因為備份不會從次要資料庫產生。 只有在次要節點變成主要節點之後，才會建立備份，以確保在觸發故障轉移且主要節點移至次要區域時，不中斷產生 LTR 備份。
當原始主資料庫從造成故障轉移的中斷中復原時，它就會變成新的輔助資料庫。 因此，備份建立不會在新的次要資料庫上繼續，而且現有的長期保留 (LTR) 原則在重新成為主要資料庫之前不會生效。
網路安全邊界與 LTR 還原（預覽版）
注意
網路安全邊界（預覽）只適用於 Azure SQL Database。 Azure SQL 受控執行個體 不是已導入的資源，因此本節不適用於它。 有關目前的清單，請參閱 已上線的 Private Link 資源。
LTR 還原是一種平台管理的操作，將資料庫從長期備份還原到目標邏輯伺服器。 當任一邏輯伺服器屬於周邊時，還原必須遵守周邊的存取規則。
該服務會檢查來源伺服器的出站存取（當該伺服器仍然存在時）以及目標伺服器的入站存取。 若來源邏輯伺服器被刪除，則只能執行目標端的入站檢查。
支援的配置
LTR 還原同時在過渡模式和強制模式下運作。 在過渡模式下，還原在沒有存取規則的情況下也能成功。 切換到強制模式前先設定規則。
在強制模式下，支援以下配置：
| 來源伺服器 | 目標伺服器 | 必須設定存取規則 |
|---|---|---|
| 在範圍內 | 在相同範圍內 | None. 同一邊界內的資源間存取始終被允許。 |
| 在周界內 | 在不同的範圍內 | 來源為出站，目標為入站。 |
| 在周界內 | 不在周界內 | 從來源送出。 |
| 不在周界內 | 在周界內 | 正朝目標前進。 |
| 已刪除 | 在周界內 | 正朝向目標前進。 |
| 不在周界內 | 不在周界內 | None. |
LTR 還原不需要受控識別。
設定 LTR 還原的存取規則
- 如果還沒做，請將每個邏輯伺服器與其周邊網路關聯起來。 對於位於邊界外的伺服器或已刪除的來源伺服器，可以跳過這個步驟。
- 如果來源伺服器在邊界內，而目標伺服器不在同一邊界內，請在來源設定檔上新增一個出站規則，目的地 類型 設為 FQDN，並輸入目標伺服器的完全限定網域名稱。
- 如果目標伺服器在邊界內，而來源伺服器不在同一邊界內，請在目標設定檔案中加入輸入規則。 還原請求來自 Azure SQL 管理基礎設施，而非來源伺服器。 在規則中，允許以下來源之一：
- 來源伺服器的訂閱 ID（建議）。
- 服務標籤（建議使用）。
- IP 位址範圍。 在公共雲中，Azure IP 範圍與服務標籤——公共雲列出每個服務標籤及其 IP 位址範圍。 服務標籤名稱為
SqlManagement。 Microsoft 不會依區域發布這些範圍，所以允許所有這些範圍。
- 伺服器仍處於過渡模式時，執行還原並檢查 網路安全邊界診斷日誌 中是否有非預期的拒絕事件。
- 只有在所有診斷檢查通過後才切換到強制模式。
限制與行為差異
- 當你的邊界關聯處於強制模式時，你無法刪除有 LTR 備份的邏輯伺服器。 不可變的 LTR 備份也會阻止刪除，不論伺服器是否位於周邊網路中。 欲了解更多資訊，請參閱 不可變更的長期備份和刪除邏輯伺服器。
- 如果你在關聯處於轉換模式時刪除來源伺服器，服務就無法再讀取該伺服器的周界中繼資料，因此只能驗證還原的目標端。 如果你依賴來源端驗證作為控制，請將此缺口納入考量。
- 在過渡模式下，即使缺少所需規則，還原仍會成功。 在強制模式下，相同的還原作業會被阻擋。
設定長期備份保留期
重要
部分用於長期保留（LTR）備份操作的舊 API 已被棄用且不再支援。 避免使用舊版的 PowerShell Cmdlet，例如 Copy-AzSqlDatabaseLongTermRetentionBackup。 請改用本文所描述的支援還原方法。
你可以使用 Azure 入口網站和 PowerShell for Azure SQL Database 和 Azure SQL 受控執行個體 來設定長期備份保留。 若要從 LTR 儲存體還原資料庫，可以依時間戳記選取特定備份。 資料庫可還原至與原始資料庫 同一訂閱的 現有伺服器或管理實例。 欲了解完整的還原功能、限制與功能，請參閱Azure SQL 受控執行個體中的
在 LTR 保留期間的最後七天起始還原要求時，即使保留期間已過期，仍只會在還原作業完成後刪除 LTR 備份。
注意
目前不支援在 Hyperscale 服務層級與 Azure SQL Database 其他服務層級之間還原資料庫。
在 Azure SQL 受控執行個體 中，你可以使用 SQL Agent 作業排程 僅為複製用途的資料庫備份，並將其移至您自己的儲存帳號，以作為下述替代方案：
- 將備份保留超過10年。
- 保留資料庫的每日復本超過 35 天。
- 將資料庫備份儲存在不可變的記憶體上。
小提示
如果您使用 LTR 備份來符合合規性或其他任務關鍵性需求，請考慮進行定期復原演練，以確認可以還原 LTR 備份，且還原會導致預期的資料庫狀態。
注意
LTR 備份取決於完整備份成功。 完整的交易日誌可能會阻止排程的完整備份，進而阻礙長期備份。 變更資料擷取（CDC）及其他防止交易日誌截斷的功能，可能會延遲 LTR 備份，而 LTR 只有在完整備份成功後才會成功。 評估防止交易日誌截斷的功能，並考慮暫時停用這些功能，直到備份作業恢復。
後續步驟
相關內容
因為資料庫備份可保護資料免於意外損毀或刪除，是商務持續性和災害復原策略中不可或缺的一環。