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

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

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

備份

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

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

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

備份類型和頻率

基本儲存體伺服器

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

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

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

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

  • 布建更多 IOPs 以考慮備份 IOs 或
  • 或者,如果您偏好的 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 的儲存體) ,則不支援啟用 Geo-Redundant 備份。

從本機冗余移至異地冗余備份儲存體

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

備份儲存體成本

適用於 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-此值會設定為預設值 系統
  • 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 規則,讓使用者能夠連接。 這些規則不會從源伺服器複製。
  • 確定有適當的登入和資料庫層級權限
  • 依適當情況設定警示

後續步驟