長期保留 - Azure SQL Database 和 Azure SQL 受控執行個體

  • 發行項

適用於：Azure SQL 資料庫Azure SQL 受控執行個體

本文提供 Azure SQL 資料庫 和 Azure SQL 受控執行個體 備份長期保留的概念概觀。 Azure SQL 資料庫 備份最多可以設定 10 年的長期保留期（包括超大規模資料庫服務層級），以及 Azure SQL 受控執行個體。

若要設定長期保留，請參閱 設定 Azure SQL Database LTR 和 設定 Azure SQL 受控執行個體 LTR。

長期保留的運作方式

長期備份保留：許多應用程式具有法規、相容性或其他商務用途，資料庫備份需要的保留期限，超過 Azure SQL Database 自動備份所提供的 1-35 天。 長期備份保留期 （LTR） 依賴 Azure SQL 服務自動建立的完整資料庫備份。 如需自動備份的詳細資訊，請參閱自動備份在 Azure SQL Database 或 Azure SQL 受控執行個體。

使用長期保留 (LTR) 功能，您可以將指定的 SQL Database 和 SQL 受控執行個體完整備份儲存在 Azure Blob 儲存體中並設定備援多達 10 年。 接著可將 LTR 備份還原為新的資料庫。 如果已設定 LTR 原則，系統會將自動備份複製到不同的 Blob，以供長期記憶體使用，然後用來將資料庫還原至特定時間點。 複製是背景工作，對資料庫工作負載不會有任何效能影響。 SQL Database 中每個資料庫的 LTR 原則也可以指定建立 LTR 備份的頻率。

注意

  • 目前無法將 Azure SQL 資料庫 和 Azure SQL 受控執行個體 的備份設定為固定。
  • 在 Azure SQL 受控執行個體中，請使用 SQL Agent 作業來排程僅限複製的資料庫備份，以替代超過 35 天的 LTR。

若要啟用 LTR，您可以用這四個參數的組合定義原則：每週備份保留 (W)、每月備份保留 (M)、每年備份的保留期 (Y) 及年度週次 (WeekOfYear)。 如果指定 W，每週一次的備份會複製到長期儲存體。 如果指定 M，每月的第一個備份會複製到長期儲存體。 如果指定 Y，在以 WeekOfYear 指定的當週進行的一次備份會複製到長期儲存體。 如果在設定原則時指定的 WeekOfYear 為過去時間，則將在明年建立第一個 LTR 備份。 每個備份都會根據建立 LTR 備份時所設定的原則參數，保留在長期儲存體中。

LTR 原則的任何變更僅適用於未來的備份。 例如，如果修改了每週備份保留 (W)、每月備份保留 (M) 或每年備份保留 (Y)，則新的保留設定只會套用至新的備份。 不會修改現有備份的保留。 如果您想要在保留期到期之前刪除舊的 LTR 備份，則必須手動刪除備份。

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 備份的時間由 Azure SQL Database 控制。 您無法手動建立 LTR 備份或控制備份建立時間。 設定 LTR 原則之後，第一個 LTR 備份最多可能需要七天才會顯示在可用備份清單上。

如果您刪除邏輯伺服器或受控執行個體，則該伺服器或受控執行個體上的所有資料庫也會一併刪除且無法復原。 您無法還原已刪除的伺服器或受控執行個體。 但是，如果您已針對資料庫或受控執行個體設定 LTR，則不會刪除 LTR 備份，並且可以用來將相同訂用帳戶中不同伺服器或受控執行個體上的資料庫，還原到執行 LTR 備份的時間點。

同樣地，如果您刪除資料庫，則不會刪除 LTR 備份，並會根據設定保留期間進行保留。 這些備份可以還原到相同伺服器或相同訂用帳戶內的不同伺服器。

異地複寫和長期備份保留

如果您使用作用中異地複寫或容錯移轉群組作為商務持續性解決方案，您應該為最終容錯移轉做好準備，並在次要資料庫或執行個體上設定相同 LTR 原則。 由於備份不是從次要產生，因此您的 LTR 儲存體成本不會增加。 只有當次要變成主要時，才會建立備份。 這可確保，當觸發容錯移轉，以及主要區域移到次要區域時，LTR 備份可以不受中斷地產生。

注意

當原本的主要資料庫從造成容錯移轉的中斷情況中復原時，其會變成新的次要資料庫。 因此，備份的建立不會繼續，而且現有的 LTR 原則將不會生效，除非它再次變成主要資料庫。

設定長期備份保留期

您可以針對 Azure SQL Database 和 Azure SQL 受控執行個體，使用 Azure 入口網站和 PowerShell 來設定長期備份保留。 若要從 LTR 儲存體還原資料庫，可以依時間戳記選取特定備份。 資料庫可以還原至與原始資料庫相同訂用帳戶底下的任何現有伺服器或受控執行個體。

若要了解如何使用 Azure 入口網站或 PowerShell，針對 SQL Database 設定長期保留或從備份還原資料庫，請參閱管理 Azure SQL Database 長期備份保留。

若要了解如何使用 Azure 入口網站或 PowerShell，針對 SQL 受控執行個體設定長期保留或從備份還原資料庫，請參閱管理 Azure SQL 受控執行個體長期備份保留。

在 LTR 保留期間的最後 7 天起始還原要求時，Azure 會自動延長所有備份的到期日 +7 天，以防止 LTR 備份在還原期間過期。

注意

如果您使用 LTR 備份來符合合規性或其他任務關鍵性需求，請考慮執行定期復原演練，以確認可以還原 LTR 備份，以及還原會導致預期的資料庫狀態。

相關內容

因為資料庫備份可保護資料免於意外損毀或刪除，是商務持續性和災害復原策略中不可或缺的一環。

如需設定和管理 LTR 備份的教學課程，請瀏覽：