在適用於 MySQL 的 Azure 資料庫中備份與還原

  • 發行項

適用於： 適用於 MySQL 的 Azure 資料庫 - 單一伺服器

重要

適用於 MySQL 的 Azure 資料庫單一伺服器位於淘汰路徑上。 強烈建議您升級至適用於 MySQL 的 Azure 資料庫彈性伺服器。 如需移轉至適用於 MySQL 的 Azure 資料庫彈性伺服器的詳細資訊，請參閱適用於 MySQL 的 Azure 資料庫單一伺服器會發生什麼事？

適用於 MySQL 的 Azure 資料庫會自動建立伺服器備份，並將其儲存在使用者設定的本地備援或異地備援儲存體中。 備份可以用來將伺服器還原至某個時間點。 備份和還原可保護資料免於意外損毀或刪除，是商務持續性策略中不可或缺的一部分。

備份

適用於 MySQL 的 Azure 資料庫會取得資料檔案和交易記錄的備份。 在您設定的備份保留期限內，這些備份可讓您將伺服器還原至任何時間點。 預設的備份保留期限是七天。 您可以選擇性設定保留期間為最多 35 天。 所有備份皆會使用 AES 256 位元加密進行加密。

這些備份檔案不是由使用者公開，而且無法匯出。 這些備份只可供適用於 MySQL 的 Azure 資料庫用於還原作業。 您可以使用 mysqldump 來複製資料庫。

備份類型和頻率取決於伺服器的後端儲存體。

備份類型和頻率

基本儲存體伺服器

基本儲存體是支援基本層伺服器的後端儲存體。 基本儲存體伺服器上的備份是以快照集為基礎。 每日都會執行完整資料庫快照集。 基本儲存體伺服器不會執行差異備份，而且所有快照集備份都只有完整資料庫備份。

交易記錄備份會每五分鐘執行一次。

一般用途儲存體 v1 伺服器 (最多支援 4 TB 儲存體)

一般用途儲存體是支援一般用途和記憶體最佳化層伺服器的後端儲存體。 針對一般用途儲存體最多 4 TB 的伺服器，每週都會進行一次完整備份。 每天執行兩次差異備份。 交易記錄備份會每五分鐘執行一次。 最多 4 TB 儲存體的一般用途儲存體上的備份不是以快照集為基礎，而且在備份時會耗用 IO 頻寬。 針對 4 TB 儲存體上的大型資料庫 (> 1 TB)，建議您考慮

  • 佈建更多 IOP 以考慮備份 IO，或者
  • 或者，如果基礎儲存體基礎結構可在慣用 Azure 區域中使用，則移轉至最多支援 16 TB 儲存體的一般用途儲存體。 最多支援 16 TB 儲存體的一般用途儲存體不需要額外成本。 如需協助移轉至 16 TB 儲存體，請從 Azure 入口網站 開啟支援票證。

一般用途儲存體 v2 伺服器 (最多支援 16 TB 儲存體)

在 Azure 區域子集中，所有新佈建的伺服器最多可以支援 16 TB 儲存體的一般用途儲存體。 換句話說，最多 16 TB 儲存體的儲存體是所有區域的預設一般用途儲存體，而這些區域支援預設一般用途儲存體。 這些 16 TB 儲存體伺服器上的備份是以快照集為基礎。 伺服器建立後，會立即進行第一次快照集備份的排程。 快照集備份會每天進行一次。 交易記錄備份會每五分鐘執行一次。

如需基本和一般用途儲存體的詳細資訊，請參閱儲存體文件。

備份保留

備份會根據伺服器上的備份保留期間設定加以保留。 您可以選取 7 到 35 天的保留期間。 預設保留期間為 7 天。 您可以在建立伺服器期間設定保留期間，或稍後使用 Azure 入口網站或 Azure CLI 更新備份設定，以設定保留期間。

備份保留期限會控制可往回多少時間來擷取時間點還原，因為這會以可用的備份為基礎。 從還原的觀點來看，備份保留期間也可視為復原時段。 備份保留期間內執行時間點還原所需的所有備份都會保留在備份儲存體中。 例如，如果備份保留期間設定為 7 天，則復原時間範圍視為過去 7 天。 在此案例中，系統會保留過去 7 天內還原伺服器所需的所有備份。 備份保留時間範圍為七天：

  • 一般用途儲存體 v1 伺服器 (最多支援 4 TB 儲存體) 最多將會保留 2 個完整資料庫備份、所有差異備份，以及自最早完整資料庫備份以來執行的交易記錄備份。
  • 一般用途儲存體 v2 伺服器 (最多支援 16 TB 儲存體) 將會保留過去 8 天內的完整資料庫快照集和交易記錄備份。

長期保留

該服務目前尚未原生支援長期保留備份 (超過 35 天)。 您可以選擇使用 mysqldump 來取得備份，並長期儲存這些備份。 我們的支援小組已在部落格中新增逐步文章，以分享達成方式。

備份備援選項

適用於 MySQL 的 Azure 資料庫可讓您在一般用途和記憶體最佳化層中，彈性地選擇本地備援或異地備援備份儲存體。 當備份儲存在異地備援備份儲存體中時，這些備份不會只儲存在裝載您伺服器的區域內，也會複寫至配對的資料中心。 此異地複寫提供更好的保護性和功能，當發生災害時，您就可以在不同的區域中還原伺服器。 「基本」層只會提供本地備援的備份儲存體。

注意

針對下列區域：印度中部、法國中部、阿拉伯聯合大公國北部、南非北部，一般用途儲存體 v2 儲存體處於公開預覽狀態。 如果您在上面所提及區域中建立一般用途儲存體 v2 (最多支援 16 TB 儲存體) 的來源伺服器，則不支援啟用異地備援備份。

從本地備援移至異地備援備份儲存體

您只可在伺服器建立期間，為備份設定本地備援或異地備援儲存體。 伺服器佈建完成之後，您無法變更備份儲存體備援選項。 若要將備份儲存體從本地備援儲存體移至異地備援儲存體，使用傾印和還原建立新的伺服器並移轉資料是唯一支援的選項。

備份儲存體成本

適用於 MySQL 的 Azure 資料庫可提供高達 100% 的已佈建伺服器儲存體作為備份儲存體，且不須支付額外費用。 額外使用的任何備份儲存體以每月 GB 數計費。 例如，如果您佈建的伺服器具有 250 GB 儲存體，則有額外 250 GB 儲存體可免費用於伺服器備份。 針對備份超過 250 GB 所耗用儲存體會根據定價模式收費。

您可以使用透過 Azure 入口網站所提供 Azure 監視器中使用的備份儲存體計量來監視伺服器所使用的備份儲存體。 「已使用的備份儲存體」計量代表根據針對伺服器所設定的備份保留期間而保留的所有完整資料庫備份、差異備份和記錄備份所耗用的儲存體總和。 先前已說明備份的頻率由服務管理。 不論資料庫大小總計，伺服器上頻繁的交易活動可能會導致備份儲存體使用量增加。 針對異地備援儲存體，備份儲存體使用量是本地備援儲存體的兩倍。

控制備份儲存體成本的主要方式是設定適當的備份保留期間，然後選擇正確的備份備援選項以符合您所需的復原目標。 您可以從 7 到 35 天的範圍選取保留期間。 一般用途和記憶體最佳化伺服器可以選擇異地備援儲存體供備份使用。

還原

在適用於 MySQL 的 Azure 資料庫中，執行還原時會從原始伺服器的備份建立新的伺服器，並還原伺服器中包含的所有資料庫。 如果原始伺服器處於停止狀態，則目前不支援還原。

有兩種類型的還原可使用：

  • 「時間點還原」可搭配任意備份備援選項使用，而且會在與原始伺服器相同的區域中建立新伺服器，而原始伺服器利用完整與交易記錄備份的組合。
  • 「異地還原」只有在您將伺服器設定為使用異地備援儲存體時才能使用，並且可讓您利用最近採用的備份以將伺服器還原至不同的區域。

伺服器復原的估計時間取決於數個因素：

  • 資料庫的大小
  • 相關的交易記錄數目
  • 需要重新執行以復原到還原點的活動數目
  • 還原到不同區域的網路頻寬
  • 要在目標區域中處理的並行還原要求數目
  • 資料庫的資料表中存在主索引鍵。 若要加快復原速度，請考慮為資料庫中的所有資料表新增主索引鍵。 若要檢查資料表是否有主索引鍵，您可以使用下列查詢：
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

針對大型及/或頻繁使用的資料庫，還原可能需要數小時。 如果區域內發生中斷延長，可能將會起始大量的異地還原要求以進行災害復原。 當有許多要求時，則該區域中個別資料庫的復原時間可能會增加。 大多數資料庫還原都會在 12 小時內完成。

重要

刪除的伺服器只能在備份刪除後的五天內還原。 您只能從裝載伺服器的 Azure 訂用帳戶存取和還原資料庫備份。 若要還原已卸除的伺服器，請參閱記載的步驟。 若要在部署後避免伺服器資源遭到意外刪除或非預期的變更，系統管理員可以利用管理鎖定。

還原時間點

與備份備援選項無關，您可以在備份保留期限內地任何時間點執行還原。 新伺服器會建立在與原始伺服器相同的 Azure 區域中。 其使用原始伺服器的組態來建立，包含定價層、計算世代、虛擬核心數目、儲存體大小、備份保留期限，以及備份備援選項。

注意

還原作業之後，有兩個伺服器參數會重設為預設值 (且不會從主要伺服器複製)

  • time_zone - 此值會設定為預設值 SYSTEM
  • event_scheduler - 還原伺服器上的 event_scheduler 會設定為 OFF

您必須重新設定伺服器參數來設定這些 伺服器參數

時間點還原適用於多種案例。 例如，使用者不小心刪除資料、卸除重要的資料表或資料庫，或是因為應用程式缺失，使應用程式不小心用不正確的資料覆寫正確資料。

您可能需要等候下一個交易記錄備份執行時，才能還原至前五分鐘內的時間點。

異地復原

如果您已將伺服器設定為使用異地備援備份，您可以將伺服器還原到另一個可使用服務的 Azure 區域中。

  • 一般用途儲存體 v1 伺服器 (最多支援 4 TB 儲存體) 可以還原至異地配對區域，或還原至支援適用於 MySQL 的 Azure 資料庫 - 單一伺服器服務的任何 Azure 區域。
  • 一般用途儲存體 v2 伺服器 (最多支援 16 TB 儲存體) 只能還原至支援一般用途儲存體 v2 伺服器基礎結構的 Azure 區域。 如需所支援區域的清單，請檢閱適用於 MySQL 的 Azure 資料庫定價層。

當您的伺服器因為裝載伺服器區域中的事件而無法使用時，異地還原就是預設的復原選項。 如果區域中的大規模意外導致您無法使用資料庫應用程式，則您可以從異地備援備份，將伺服器還原到任何其他區域中的伺服器。 異地還原會利用伺服器的最新備份。 在建立備份及將它複寫至不同區域之間會有延遲。 此延遲可能最長達一小時，因此當發生災害時，最多可能會遺失最長達一小時的資料。

重要

如果針對新建立的伺服器執行異地還原，則初始備份同步可能需要超過 24 小時 (視資料大小而定)，因為初始完整快照集備份複製時間較高。 後續快照集備份是增量複製，因此在建立伺服器 24 小時之後還原的速度會更快。 如果您要評估異地還原以定義 RTO，則建議您只在建立伺服器「24 小時後」才等候和評估異地還原，以取得更佳的估計值。

在異地還原期間，可以進行變更的伺服器設定包括計算世代、vCore、備份保留期間及備份備援選項。 異地還原期間不支援變更定價層 (基本、一般，或記憶體最佳化) 或儲存體大小。

預估的復原時間取決於數個因素，包括資料庫大小、交易記錄大小、網路頻寬，以及在相同區域中同時進行復原的資料庫總數。 復原時間通常不到 12 小時。

執行還原之後的工作

從其中任何一種復原機制還原之後，您應執行下列工作，讓您的使用者和應用程式回復正常執行狀態︰

  • 如果新伺服器就會取代原始伺服器，則將用戶端和用戶端應用程式重新導向至新伺服器
  • 確保有適當的 VNet 規則可供使用者連線。 這些規則不會從原始伺服器複製。
  • 確定有適當的登入和資料庫層級權限
  • 依適當情況設定警示

下一步