邏輯備份包含資料庫中的資料，其中採用的格式可由 MySQL 解譯為 SQL 格式或分隔的文字格式。它是以一系列 SQL 陳述式呈現的資料庫表示法，可用來執行重建資料庫物件和匯入資料。這種備份類型適合小型資料庫，因為邏輯備份作業的還原時間可能比還原實體備份更長。當您遷移資料至雲端的代管資料庫服務或從中移轉時，這個備份類型也非常實用。

優點：

邏輯備份相當有彈性。針對伺服器層級 (所有資料庫)、資料庫層級 (特定資料庫中的所有資料表)、資料表層級，甚至是資料列層級 (資料表中符合指定的 WHERE 條件的資料列) 提供精細程度很高的備份和還原作業。

邏輯備份較容易還原：只要將備份檔案傳輸至 MySQL 用戶端，然後使用 LOAD DATA 陳述式或 mysqlimport 指令載入分隔的文字檔案。

邏輯備份可透過其他機器遠端執行，這樣您就能透過網路備份與還原資料庫。這對於雲端資料庫 (例如 Google Cloud SQL、Amazon RDS 和 Microsoft Azure) 而言非常實用，因為使用者無法直接存取虛擬機器。

邏輯備份可避免資料損毀。實體備份資料可能會損毀，而且可能會到驗證後才發現。邏輯備份通常是文字檔案，因此使用文字編輯器可以更輕鬆地查看，並發現任何損毀情形。邏輯備份極少損毀。

有別於實體備份，邏輯備份在平台、作業系統和 MySQL 版本之間具高度可攜性。

邏輯備份具有高度壓縮能力。

缺點：

邏輯備份的建立速度較慢，因為您需要查詢 MySQL 伺服器以取得結構定義和資料列，然後轉換成邏輯格式

此外，由於 MySQL 需要執行 SQL 陳述式來建立資料表、匯入資料列及重建索引，因此邏輯備份的還原速度較慢

與實體備份相比，邏輯備份需要更多伺服器資源 (CPU、RAM 和磁碟 I/O) 才能進行備份與還原作業

一些常見的邏輯備份工具

MySQL 殼層公用程式 — 轉儲 | 載入

時間點復原 (PITR)

顧名思義，時間點復原可協助您將執行個體復原至特定時間點。舉例來說，如果錯誤導致資料遺失，您可以將資料庫復原為發生錯誤之前的狀態。

PITR 是兩個步驟的流程，仰賴使用二進位記錄檔：

還原完整的實體或邏輯備份，使伺服器處於備份時相同的狀態
套用二進位記錄檔，以重播備份時間點與所需時間點之間的變更

二進位記錄檔包含對資料庫執行個體所做的任何變更，例如建立資料表、插入/更新/刪除資料列等。舉例來說，假設每天的備份在早上 6:00 執行，而您希望將執行個體復原至上午 10:15 分之前。為了要復原在上午 10:15 的狀態，您必須先還原從上午 6:00 開始的完整備份，然後再重播從早上 6:00 到 10:15 二進位記錄檔事件。這會讓伺服器在所需時間達到所需的狀態。

複製和 PITR 時必須指定二進位記錄檔；它和基礎資料一樣重要。您必須即時備份二進位記錄檔，才能在還原規劃中有效執行，並使用 mysqlbinlog 指令下載。

舉例來說：

mysqlbinlog --host=<hostname> --port=<port> --user=<user> --password=<password> --read-from-remote-server --raw --stop-never <binlog_filename>

<binlog_filename> 將是第一個要下載的檔案，mysqlbinlog 之後將自動切換至下一個檔案。這些二進位記錄檔會寫入目前執行 mysqlbinlog 指令的伺服器所在目錄。您可以使用 --result-file 選項來變更檔案名稱和位置。您也可以使用 --stop-never 選項，讓 mysqlbinlog 二進位記錄檔與伺服器保持連線，並在寫入時下載新變更。

詳情請參閱 mysqlbinlog 手冊，瞭解如何連線至遠端伺服器並在寫入時下載二進位記錄檔。

MySQL 適用的 Cloud SQL 備份與還原

Cloud SQL 是適用於 MySQL 的 Google Cloud 代管資料庫服務，提供自動備份和時間點復原 (PITR) 機制，方便您保護資料。根據預設，系統會啟用這些功能，這是在 MySQL 適用的 Cloud SQL 執行個體上啟用高可用性 (HA) 的必要條件。

所有 Cloud SQL 備份都是實體備份的一種，因為這些備份是在永久磁碟 (PD) 中拍攝的快照。Cloud SQL 提供彈性的自動備份機制，您隨時可以視需求執行備份作業。您仍可使用標準 MySQL 邏輯備份工具 (例如 mysqldump、mydumper、mysqlpump 等) 進行邏輯備份，而不會干擾代管備份。

讓我們來深入探討 Cloud SQL 備份的運作方式。

瞭解 Cloud SQL 快照

Cloud SQL 使用 Persistent Disk (PD) 做為儲存空間，而且每個 Cloud SQL 執行個體中都有一個永久性資料磁碟，用於儲存資料庫檔案和目錄。

Cloud SQL 使用 PD 快照進行備份，這些快照則是指資料磁碟在特定時間點的狀態。PD 的第一個快照是包含 PD 所有資料的完整快照，後續的快照則是隨著時間增加，且只包含自上次快照以來的任何新資料或修改後的資料。您可以將這些快照視為雲端代管永久性資料磁碟實體副本，這類快照是所有 Cloud SQL 備份與還原功能 (包括 PITR) 的基礎。

Cloud SQL 備份

Cloud SQL 會執行兩種類型的代管備份：自動化與隨選。根據預設，這兩種類型都會儲存在最接近執行個體的多區域位置。舉例來說，如果您的 Cloud SQL 執行個體位於 us-central1，系統預設會將備份儲存在美國的多區域。不過，australia-southeast1 之類的預設位置在多區域之外，將會放置在最接近的多區域，也就是亞洲。或者，您也可以為備份選擇自訂位置。

自動備份

系統每天都會自動在指定的 4 小時內擷取備份。備份作業會在備份期間開始，並可能會在備份時間之外繼續執行，直到備份完成為止。您可以設定要保留的自動備份數量 (從 1 到 365)。預設保留政策是保留最近七個備份。

隨選備份

也可以隨時建立隨選備份。如果需要備份，而且不想等到備份時間，這些方法就能派上用場。此外，有別於自動備份，系統不會自動刪除隨選備份。它們會一直存在，直到您刪除隨選備份或刪除其執行個體為止。

還原 Cloud SQL 備份

您可以將備份還原至相同位置的執行個體，或還原至同一專案中的其他執行個體。請注意，在還原備份時，目標執行個體不應是唯讀備用資源本身，也不應有唯讀備用資源，因為唯讀備用資源是主要執行個體副本，並造成備用資源無法與主要執行個體保持同步的風險。之後隨時可以新增唯讀備用資源。

還原備份時，系統會從該備份快照建立新的 PD，並將其附加至執行個體。資料庫會先使用新的磁碟，並執行標準 MySQL 當機復原程序，然後從快照進行更新的還原，並恢復完善的 MySQL 資料庫運作。

還原至相同執行個體

從備份還原至相同執行個體時，該執行個體的資料也會回到當初建立備份時的狀態。

還原至其他執行個體

從備份還原至不同的執行個體時，會將目標執行個體中的資料更新為當初建立備份時的來源執行個體狀態。

重要事項：還原備份會覆寫目標執行個體中的所有現有資料，包括之前的時間點復原記錄。資料一經覆寫即無法復原。

Cloud SQL 時間點復原 (PITR)

在 Cloud SQL 中，PITR 一律會建立新的執行個體，其會沿用來源執行個體的設定，與複製執行個體作業類似。您必須在來源執行個體中啟用自動備份和時間點復原功能 (二進位記錄檔)，才能使用這項功能。二進位記錄檔的預設保留政策為 7 天，您可以將保留期限設定為 1 至 7 天。

PITR 是透過原始執行個體備份建立的新執行個體，並將原始執行個體資料磁碟中儲存的二進位記錄檔重播至指定的時間點來進行。

在 Cloud SQL 中執行 PITR 時，客戶可以選擇複製執行個體的目前狀態，或複製到過去的時間戳記。

執行 PITR 的 UI 如下所示。

Google Cloud 提供代管的 MySQL 資料庫，可滿足您的業務需求，包括淘汰地端部署資料中心、執行軟體式服務 (SaaS) 應用程式，以及遷移核心業務系統等。

Cloud SQL

MySQL 適用的全代管資料庫

MySQL 備份與還原

備份類型

實體備份