自動備份超大規模資料庫

適用於:Azure SQL Database

本文說明如何在 Azure SQL Database 中使用超大規模資料庫的自動備份功能。

超大規模資料庫採用獨特架構,具備可高度調整的儲存體和計算效能層。 超大規模資料庫備份是以快照集為基礎,而且幾乎是即時的。 備份保留期間,記錄備份會儲存於長期的 Azure 儲存體。

超大規模資料庫架構不需要完整備份、差異備份或記錄備份, 因此備份頻率、儲存體成本、排程、儲存體備援和還原功能都與 Azure SQL 資料庫的其他資料庫不同。

備份和還原效能

藉由區隔儲存體和計算作業,超大規模資料庫可將備份和還原作業下推到儲存體層,減少計算複本的資源耗用量。 資料庫備份不會影響主要或次要計算複本的效能。

由於超大規模資料庫的備份和還原作業都是使用儲存體快照集,因此速度很快,不會受資料大小所影響。 備份作業幾乎是立即完成。

資料庫可以還原到備份保留期間內的任何時間點,方法包括:

  1. 還原到適用的檔案快照集。
  2. 套用交易記錄,讓還原的資料庫與當時的交易保持一致。

因此,還原不是維持不變的資料大小作業。 在同一個 Azure 區域內還原超大規模資料庫可在幾分鐘內完成,不必耗費數小時或數天,即使資料庫超過 1 TB 也一樣。

發出還原時變更記憶體備援可能會導致還原時間增長,因為還原涉及資料大小,因此時間會與資料庫大小成正比。

如果還原現有的備份或複製資料庫,藉以建立新的資料庫,也會利用超大規模資料庫區隔計算作業和儲存體的機制。 您可以針對開發或測試目的建立資料庫複本時,即使資料庫大小超過 1 TB,只要使用相同的儲存體類型,在相同區域內執行作業依然可以在幾分鐘內完成。

備份保留

超大規模資料庫預設的短期備份保留期限為 7 天。

自 2023 年 9 月起,超大規模資料庫在 1 到 35 天內的備份短期保留和長期備份保留功能已正式推出。 如需詳細資訊,請參閱長期保留 - Azure SQL 資料庫和 Azure SQL 受控執行個體

備份排程

超大規模資料庫並沒有傳統的完整、差異和交易記錄備份。 而是改採用資料檔案的一般儲存體快照集。

在設定的保留期間內,所產生的交易記錄會以原狀保留。 還原時,相關的交易記錄會套用至已還原的儲存體快照集。 如此一來,資料庫截至保留期間內指定時間的所有資料都不會遺失,且會與當時的交易保持一致。

監視備份儲存體耗用量

在超大規模資料庫中,Azure 監視器計量會向您回報下列耗用量資訊:

  • 資料備份儲存體大小 (快照集備份大小)
  • 資料儲存體大小 (配置的資料庫大小)
  • 記錄備份儲存體大小 (交易記錄備份大小)

若要在 Azure 入口網站中檢視備份和資料儲存體計量,請依下列步驟操作:

  1. 前往您要監視備份和資料儲存體計量的超大規模資料庫。
  2. 在 [監視] 區段中選取 [計量] 頁面。
  3. 從 [計量] 下拉式清單中,選取具有適當彙總規則的 [資料備份儲存體]、[資料儲存體大小] 和 [記錄備份儲存體] 計量。

Screenshot of the Azure portal that shows selections for viewing Hyperscale backup storage consumption.

降低備份儲存體耗用量

超大規模資料庫的備份儲存體耗用量取決於保留期間、所選區域、備份儲存體備援和工作負載類型。 請考慮使用下列幾項微調技巧,以降低超大規模資料庫的備份儲存體耗用量:

  • 在能滿足您需求的前提下,將備份保留期間盡可能縮短。
  • 避免頻繁執行不必要的大量寫入作業,例如索引維護。 如需索引維護建議,請參閱將索引維護最佳化以改善查詢效能並降低資源耗用量
  • 如適用,大型資料載入作業請考慮使用資料壓縮。
  • 在應用程式邏輯中使用 tempdb 資料庫儲存暫時性結果及/或暫時性資料,不要使用永久資料表。
  • 如果沒必要使用異地還原功能 (例如在開發/測試環境中),請使用本地備援或區域備援備份儲存體。

備份儲存體成本

超大規模備份儲存體成本取決於您選擇的區域和備份儲存體備援。 工作負載類型也是影響因素。

大量寫入的工作負載更可能經常變更資料頁,導致較大的儲存體快照集。 這類工作負載也會產生較多交易記錄,增加整體備份成本。 費用依您每月耗用的備份儲存體 (以 GB 為單位) 計價。 如需價格的詳細資料,請參閱 Azure SQL Database 定價頁面。

超大規模資料庫計費備份儲存體的計算方式如下:

Total billable backup storage size = (data backup storage size + log backup storage size)

資料儲存體大小不會列入計費備份中計算,因為其費用已包含在所配置的資料庫儲存體中。

為支援恢復到刪除前的某個時間點,已刪除的超大規模資料庫會產生備份成本。 已刪除之超大規模資料庫計費備份儲存體的計算方式如下:

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

資料儲存體大小已包含在公式中,因為已配置的資料庫儲存體不會單獨計費已刪除的資料庫。 資料庫刪除後,您所刪除的資料會妥善存放,以便於所設定的備份保留期間復原。

已刪除資料庫的計費備份儲存體會在刪除後與日俱減。 不再保留備份且資料不再能夠復原時,備份儲存體就會歸零。 如果是永久刪除,而且不再需要備份,您可以在刪除資料庫之前縮短保留期限,將成本最佳化。

監視備份成本

若要瞭解備份儲存體的成本:

  1. 在 Azure 入口網站中,前往 [成本管理 + 計費]。

  2. 選取 [成本管理] > [成本分析]。

  3. 針對 [範圍] 選取所需的訂用帳戶。

  4. 依下列步驟篩選您想使用的時段和服務:

    1. 新增 [服務名稱] 的篩選條件。
    2. 從下拉式清單中選擇 [sql-database]。
    3. 為 [計量] 新增其他篩選條件。
    4. 若要監視時間點復原的備份成本,請從下拉式清單中選取 [儲存的資料 - 備份 - RA]。

成本分析如以下螢幕擷取畫面所示。

Screenshot of the Azure portal that shows Hyperscale Backup storage costs.

資料和備份儲存體備援

超大規模資料庫支援可設定的儲存體備援。 建立超大規模資料庫時,您可以選擇您偏好的儲存體類型:讀取權限異地區域備援儲存體 (RA-GZRS)、讀取權限異地備援儲存體 (RA-GRS)、區域備援儲存體 (ZRS) 或本地備援儲存體 (LRS)。

  • 異地區域備援儲存體:在主要區域中將備份同步複製到三個 Azure 可用性區域, 類似於區域備援儲存體 (ZRS)。 此外,這還會將資料以非同步方式複製到配對次要區域中的單一實體位置。 目前只有特定區域可使用這項服務。

若要了解更多關於如何針對其他儲存體類型複寫備份的資訊,請參閱備份儲存體備援

由於超大規模資料庫會使用儲存體快照集來備份,因此資料和備份會共用相同的儲存體帳戶。 因此,您選取的備份儲存體備援會同時適用於資料和備份。

注意

建立超大規模資料庫時,請考慮謹慎是否備份儲存體備援,因為您只能在資料庫建立期間加以設定。 佈建資源後,您就無法修改這項設定。

若要在最短的停機時間內更新現有超大規模資料庫的備份儲存體備援設定,請使用作用中異地複寫。 或者,您也可以使用資料庫複本

警告

  • 資料庫更新為使用本地或區域備援儲存體後,就會立即停用異地還原
  • 區域備援儲存體目前僅適用於特定區域
  • 異地區域備援儲存體目前僅適用於特定區域

將超大規模資料庫還原至不同區域

您可能需要將超大規模資料庫還原到與目前所在區域不同的區域, 常見原因包括災害復原作業或演練,或是重新配置。 主要方法是執行資料庫的異地還原作業。 這與將 SQL Database 資料庫的其他任何資料庫還原至不同區域,步驟完全相同:

  1. 如果您還沒有適當的伺服器,請在目的地區域中建立伺服器。 此伺服器的擁有者應為與原始 (來源) 伺服器相同的訂閱。
  2. 請遵循從自動備份還原 Azure SQL Database 資料庫頁面中異地復原一節中的指示。

注意

由於來源和目標位於不同的區域,資料庫無法像在非異地還原作業中一樣,與來源資料庫共用快照集儲存體。 不論資料庫大小為何,非異地還原作業都能快速完成。

即使目標位於異地複寫儲存體的配對區域,超大規模資料庫的異地還原作業還是屬於全資料寫入作業 (size-of-data operation)。 因此,相較於相同區域中的時間點還原作業,異地還原作業需要遠遠更多時間。

如果目標位於配對的區域內,資料就會在單一區域內傳輸, 傳輸速度會比跨區域資料傳輸更快, 但這項作業依然需要寫入所有資料。

如果您要的話,您也可以將資料庫複製到不同的區域。 如果因為您所選取的儲存體備援類型不支援而無法使用異地還原功能,請使用此方法。 如需詳細資訊,請參閱超大規模資料庫複本

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