隨著企業和應用程序越來越依賴 MySQL 數據庫來管理其關鍵數據，確保數據可靠性和可用性變得至關重要。在這個數字信息時代，強大的備份和恢復策略是應用程序穩定性的支柱。 本文中，我們將回顧所有常用的 MySQL 備份和恢復策略，它們是任何應用程序的基石。對應您的特定場景，有多個選項可供選擇，每個選項都要求我們考慮相關問題以做出明智的決策。

為什么 MySQL 備份很重要？

MySQL 備份在保護數據完整性、防止各種不可預見的災難、硬件故障、數據丟失、損壞和意外刪除方面發揮著關鍵作用。如果沒有可靠的備份，數據丟失的后果可能會很嚴重。企業面臨運營中斷、財務損失、聲譽受損甚至合規違規的風險。了解 MySQL 備份的重要性以及它們如何降低這些風險將有助于組織保證數據一致性、業務連續性，并確保數據在需要時安全且可恢復。

RTO 是什么？

RTO（RecoveryTimeObjective，恢復時間目標）是故障發生到業務恢復能時間點的最大長度。與之相關的問題是： 多久可以恢復？

RPO 是什么？

RPO（RecoveryPointObjective，恢復點目標）是故障發生后業務系統可容忍的數據丟失量。與之相關的問題是： 會丟失多少數據？

MySQL 備份類型有哪些？

MySQL 備份類型主要有兩種：物理備份和邏輯備份。下面我們將提供對這兩種備份類型以及其他一些策略的更多見解。

物理（Percona XtraBackup、RDS/LVM 快照、MySQL Enterprise Backup），只要將 MySQL 服務關閉，也可以使用 cp 或 rsync 命令行來復制數據目錄 datadir。

邏輯（mysqldump、mydumper、mysqlpump、mysql shell 僅適用于 MySQL 8）。

此外，建議創建 binlog 文件的副本。這種做法有一個重要目的：它使我們能夠將數據恢復到最后一個事務。

邏輯備份

這是邏輯數據庫結構（CREATE DATABASE、CREATE TABLE 語句）和內容（INSERT 語句）的轉儲。建議將其用于較小量的數據。如果與物理備份相比，此方法的缺點是速度較慢（備份和恢復）。如果需要，您可以使用 mydumper 備份和恢復單個數據庫或單個表，這對于將某些數據復制到不同的環境以運行測試非常有用。另外，mydumper 可以進行一致（只要所有表都是 InnoDB 引擎）備份并提供準確的主從日志位置。 輸出比物理備份大，特別是以文本格式保存時，但它可以根據您使用的軟件即時壓縮。例如，mydumper 可以壓縮，而 mysqldump 需要添加一個管道將輸出重定向到 gzip 文件。 邏輯備份用于解決數據損壞或恢復表子集的需要。

物理備份

簡而言之，它由數據庫目錄和文件的精確副本組成。這可以是 MySQL datadir 目錄的全部或部分副本。這種備份最常用于輕松快速地恢復或創建新的副本節點，并用于解決主機故障。建議使用相同的 MySQL 版本進行恢復。建議使用 Percona XtraBackup，因為它可以包含任何相關文件，例如 cnf 配置文件等配置文件。

快照備份

某些文件系統實現允許存儲 “快照”。它們提供給定時間點的文件系統的邏輯副本，而不需要整個文件系統的物理副本。MySQL 本身不提供獲取文件系統快照的功能，但可以使用 LVM 或 ZFS 等第三方解決方案來實現。 缺點是有時物理備份不會壓縮太多，因為數據通常是二進制格式，有時表已經被壓縮。

二進制日志備份

Binlog 備份專門針對 RPO。二進制日志文件包含執行的每個發生更改的 SQL 查詢的記錄。 從 MySQL 5.6 開始，您可以使用 mysqlbinlog 從遠程服務器流式傳輸二進制日志。可以將二進制日志備份與 Percona XtraBackup 或 mydumper 備份結合起來，以允許恢復到最近備份的二進制日志的末尾。

增量 / 差異備份

增量備份是對自上次備份以來發生更改的所有內容的備份（二進制日志備份是增量備份的特殊情況）。如果數據集大小很大，這是一個非常好的選擇，因為您可以在本周初進行完整備份并每天運行增量備份。此外，備份大小比完整備份小。 與增量備份相關的主要風險是：

單個損壞的增量備份可能會使所有其他備份失效

增量備份通常會對 RTO 產生負面影響

對于差異備份，它會復制與上次備份的差異，其優點是從一個備份到下一個備份的大量數據不會發生更改，因此結果可以是明顯更小的備份。這可以節省磁盤空間。 Percona XtraBackup 支持增量備份和差異備份。

為什么需要 MySQL 備份？

當出現多種問題時，需要 MySQL 備份：

主機故障：我們可能會因磁盤停滯或磁盤損壞而遇到多種問題。同樣，在云服務中，我們的數據庫實例可能會損壞并且無法訪問。

數據損壞：這可能發生在斷電時，MySQL 無法正確寫入并關閉文件，有時當 MySQL 再次啟動時，由于數據損壞而無法啟動，并且崩潰恢復過程無法修復它。

數據不一致：當人犯錯誤時，通過主節點或副本節點刪除 / 更新錯誤數據。

數據中心故障：停電或互聯網提供商問題。

立法 / 法規：提供一致的商業價值和客戶滿意度。

MySQL 備份和恢復最佳實踐

在本節中，我們將探討基本的 MySQL 備份和恢復最佳實踐，以保護您的數據并確保數據庫順利運行。

異地存儲

強烈建議將所有備份方法復制到另一個地方，例如云或外部文件服務器，這樣在主機故障或數據中心故障的情況下，確保還有另一個副本。 并非所有備份文件都需要上傳到云端，有時您需要花費在下載上的時間比恢復過程中消耗的時間還要多。 一個好的方法是在備份服務器上本地保留 1-7 天，以便需要快速恢復，這取決于您的業務法規。

加密

備份包含敏感數據，因此強烈建議加密，尤其是異地存儲。當您需要恢復備份時，這會增加更多時間，但可以保證數據安全。 GPG 是加密備份的一個不錯的選擇，如果您使用此選項或其他替代方案，請不要忘記獲取密鑰 / 密碼的副本。如果丟失，您的備份將毫無用處。

恢復測試

根據您的業務，強烈建議每月至少測試一次備份。此操作可驗證您的備份未損壞，并提供有關恢復時間的關鍵指標。此過程應該自動化，以獲取完整備份、恢復它，并最終將此服務器配置為當前主服務器或另一個副本的副本。這也有助于驗證復制過程沒有錯誤。 許多客戶正在使用這種方法來刷新他們的 QA/STG 環境，以便從生產備份中獲取最新數據。 除了上述內容之外，建議創建手動或自動恢復文檔流程，以將所有步驟放在一起，以便在發生災難時，您可以遵循它而不會浪費時間。

保留要求

最后但并非最不重要的一點是，保留不同備份類型的多個副本非常重要。 我們最好的建議是：

備份服務器本地的一到兩個物理備份（只要空間允許）。

備份服務器上本地的每日 7 次和每周 4 次邏輯備份。

備份服務器本地 30 天的 binlog 備份。

對于異地備份（如 S3、Google Cloud 等），每月備份保留一年或更長時間。

對于本地備份，請記住，您至少需要當前數據集大小 2.5 倍的可用磁盤空間來保存 / 滿足這些保留策略。不要忘記加密所有備份類型！ 法律或監管要求也可能規定數據必須存檔多長時間。

驗證 MySQL 備份

因此，您已經獲得了遵循所有最佳實踐的備份過程。那你怎么知道備份成功了？你看過文件大小嗎？您是否只檢查創建了一個文件？也許您只查看了您使用的工具的退出代碼？ “在驗證備份之前，你還沒有進行備份。” 很好的建議。換句話說，您所做的每個備份都可以被視為薛定諤的備份；在你驗證之前，能確定它有效嗎？ 這里的最佳實踐是使用您創建的備份簡單地恢復 MySQL 服務器；然而，你創造了它。處理此恢復的機器不需要像源一樣強大；一個簡單的虛擬機就可以管理這項任務，并且可以很好地實現自動化。 您可以使用 mysql 客戶端本身恢復 mysqldump：

zcat my_full_backup.sql.gz | mysql

使用 mydumper/myloader：

myloader --directory dump_dir --overwrite-tables --verbose=3

Percona XtraBackup：

# Prepare the backup
xtrabackup --prepare --parallel 4 --use-memory 4G --target-dir /var/backup
 
# Copy backup to original location (ie: /var/lib/mysql), assuming backup taken on same host
xtrabackup --copy-back --target-dir /var/backup
 
# Fix file permissions if necessary
chown -R mysql:mysql /var/lib/mysql
 
# Start MySQL
systemctl start mysql

是的，Percona XtraBackup 確實需要更多步驟，但物理備份始終是最快的備份方式和最快的恢復方式。

審核編輯：湯梓紅