備份策略核心原則
- 3-2-1 原則：3 份副本、2 種介質、1 份異地
- RPO/RTO 定義：RPO(數據丟失容忍度)、RTO(恢復時間目標) 驅動方案選型
- 備份類型：全量、增量、差異；邏輯 vs 物理；熱/溫/冷備份
- 驗證機制：定期演練恢復，校驗數據完整性 (checksum、行數、關鍵業務查詢)
方案一：mysqldump + Binlog (邏輯備份、通用性最強)
適用場景
- 中小數據集 (< 50GB)、跨版本遷移、異構導出、開發測試數據生成
- MyISAM 只能溫備 (加讀鎖)，InnoDB 支持熱備 (
--single-transaction)
核心參數
mysqldump -u root -p \
--single-transaction \ # InnoDB 熱備核心：啟動一致性快照讀
--master-data=2 \ # 註釋記錄 Binlog 位置 (CHANGE MASTER TO)
--routines --triggers --events \ # 存儲過程/觸發器/事件
--hex-blob \ # 二進制列十六進制導出
--quick \ # 流式讀取，不緩存全表結果集
--all-databases > full_$(date +%F).sql
增量備份：Binlog 導出
# 1. 滾動日志 (切換新 Binlog)
mysql -u root -p -e "FLUSH LOGS;"
# 2. 導出指定位置區間
mysqlbinlog --start-position=14203 --stop-position=14527 mysql-bin.000001 > incr_$(date +%F_%H).sql
# 3. 或導出時間區間
mysqlbinlog --start-datetime="2023-10-01 10:00:00" --stop-datetime="2023-10-01 14:30:00" mysql-bin.000001 > incr.sql
恢復流程
# 1. 停服務/只讀模式
mysql -u root -p -e "SET GLOBAL read_only=1;"
# 2. 全量恢復
mysql -u root -p < full_2023-10-01.sql
# 3. 增量恢復 (按順序應用多個 Binlog)
mysql -u root -p < incr_2023-10-01_10.sql
mysql -u root -p < incr_2023-10-01_14.sql
# 4. 驗證並開放
mysql -u root -p -e "SET GLOBAL read_only=0;"
優缺點總結
| 優點 | 缺點 |
|---|
| 跨版本/引擎兼容、文本可讀、可編輯、壓縮率高 | 大表備份/恢復極慢、佔用 CPU、Binlog 位置管理複雜、恢復後需重建索引統計 |
方案二：LVM 快照 + Binlog (物理備份、秒級凍結)
前提條件
- 數據目錄位於 LVM 邏輯卷 (
/dev/vg1/mysql)
- 事務日志 (ib_logfile*) 與數據文件在同一卷 (保證崩潰一致性)
- 預留 10-20% VG 空間給快照卷
備份流程
# 1. 全局讀鎖 + 刷盤 + 記錄 Binlog 位置
mysql -u root -p -e "FLUSH TABLES WITH READ LOCK; FLUSH LOGS;"
mysql -u root -p -e "SHOW MASTER STATUS;" > /backup/lvm_$(date +%F)/binlog_pos.txt
# 2. 創建快照卷 (幾乎瞬間完成)
lvcreate -L 10G -s -n mysql_snap /dev/vg1/mysql
# 3. 立即釋放鎖 (業務恢復正常)
mysql -u root -p -e "UNLOCK TABLES;"
# 4. 掛載快照並複製數據 (可並行壓縮)
mount /dev/vg1/mysql_snap /mnt/snap
tar czf /backup/lvm_$(date +%F)/data.tar.gz -C /mnt/snap .
umount /mnt/snap
lvremove -f /dev/vg1/mysql_snap
恢復流程
# 1. 停服務
systemctl stop mysqld
# 2. 清空數據目錄 (或重建卷)
rm -rf /var/lib/mysql/*
# 3. 解壓全量備份
tar xzf /backup/lvm_2023-10-01/data.tar.gz -C /var/lib/mysql/
chown -R mysql:mysql /var/lib/mysql
# 4. 啟動服務 (InnoDB 自動崩潰恢復)
systemctl start mysqld
# 5. 應用 Binlog 增量 (從 binlog_pos.txt 記錄位置開始)
mysqlbinlog --start-position=187 mysql-bin.000004 | mysql -u root -p
優缺點總結
| 優點 | 缺點 |
|---|
| 備份窗口極短(秒級)、對業務影響最小、恢復快(順序讀取)、文件系統級一致性 | 依賴 LVM、需規劃存儲、跨機器遷移麻煩、MyISAM 仍需全局鎖 |
方案三：Percona XtraBackup (物理熱備、企業級首選)
核心優勢
- 完全非阻塞熱備 (InnoDB)、支持增量、支持壓縮/加密/流式傳輸、支持單表導入 (需
innodb_file_per_table=ON)、自動驗證備份完整性
- 官方文檔：percona.com
安裝
# CentOS/RHEL
yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
yum install -y percona-xtrabackup-80 # 匹配 MySQL 8.0
# 或下載 RPM 手動安裝
rpm -ivh percona-xtrabackup-8.0.x-x.el7.x86_64.rpm
全量備份
innobackupex --user=root --password='pass' --no-timestamp /backup/full_2023-10-01
# 輸出目錄結構：
# xtrabackup_checkpoints (LSN 範圍、備份類型)
# xtrabackup_binlog_info (Binlog 文件+位置)
# xtrabackup_logfile (備份過程 Redo Log 拷貝)
# backup-my.cnf (備份時配置)
# 各庫目錄下 .ibd/.frm 文件
備份「準備」 (必須步驟，回滾未提交事務、應用 Redo Log)
innobackupex --apply-log /backup/full_2023-10-01
# 完成後 xtrabackup_checkpoints 顯示 Backup_type = full-prepared
增量備份
# 第 1 次增量 (基於全量)
innobackupex --user=root --password='pass' --incremental /backup/incr --incremental-basedir=/backup/full_2023-10-01
# 第 2 次增量 (基於上一增量)
innobackupex --user=root --password='pass' --incremental /backup/incr --incremental-basedir=/backup/incr/2023-10-01_10-00-00
# 第 3 次增量... 以此類推
增量合併準備 (逆序合併到全量)
# 1. 全量準備 (僅 redo)
innobackupex --apply-log --redo-only /backup/full_2023-10-01
# 2. 合併第 1 增量
innobackupex --apply-log --redo-only /backup/full_2023-10-01 --incremental-dir=/backup/incr/2023-10-01_10-00-00
# 3. 合併第 2 增量
innobackupex --apply-log --redo-only /backup/full_2023-10-01 --incremental-dir=/backup/incr/2023-10-01_14-00-00
# 4. 最後一次不加 --redo-only (回滾未提交事務)
innobackupex --apply-log /backup/full_2023-10-01
恢復 (--copy-back)
# 1. 停服務、清空數據目錄
systemctl stop mysqld
rm -rf /var/lib/mysql/*
# 2. 複製回數據目錄
innobackupex --copy-back /backup/full_2023-10-01
chown -R mysql:mysql /var/lib/mysql
# 3. 啟動驗證
systemctl start mysqld
單表恢復 (需 innodb_file_per_table=ON)
# 1. 目標庫創建同結構空表
CREATE TABLE testdb.tbl LIKE prod.tbl;
ALTER TABLE testdb.tbl DISCARD TABLESPACE;
# 2. 複製 .ibd + .cfg (xtrabackup --export 生成) 到數據目錄
cp /backup/full_2023-10-01/testdb/tbl.{ibd,cfg} /var/lib/mysql/testdb/
# 3. 導入表空間
ALTER TABLE testdb.tbl IMPORT TABLESPACE;
三大方案綜合對比選型表
| 維度 | mysqldump | LVM Snapshot | XtraBackup |
|---|
| 備份類型 | 邏輯 | 物理 | 物理 |
| 阻塞寫入 | MyISAM 鎖表 / InnoDB 無鎖 | 秒級全局鎖 | 完全無鎖 (InnoDB) |
| 備份速度 | 慢 (SQL 解析+網絡) | 極快 (文件系統級) | 快 (順序讀+並行) |
| 恢復速度 | 極慢 (SQL 重放+建索引) | 快 (順序寫+崩潰恢復) | 快 (順序寫+崩潰恢復) |
| 增量支持 | Binlog 手工管理 | Binlog 手工管理 | 原生 LSN 增量 |
| 壓縮/加密 | 管道 gzip/openssl | tar gzip/openssl | 原生 --compress/--encrypt |
| 跨版本遷移 | ✅ 最佳 | ❌ 同版本同參數 | ⚠️ 大版本需升級 |
| 單表恢復 | ✅ 輕鬆 | ❌ | ✅ 支持 (需 file_per_table) |
| 存儲開銷 | 壓縮後 ~30% 數據量 | 快照佔用變更量空間 | ~數據量 (可壓縮) |
| 適用數據量 | < 50GB | 任意 (需 LVM) | > 50GB 企業級首選 |
| MyISAM 支持 | 溫備 (鎖表) | 溫備 (鎖表) | 溫備 (鎖表) |
生產環境推薦架構
# 每日 02:00 全量 XtraBackup (保留 7 天)
# 每 1 小時增量 XtraBackup (保留 24 個)
# Binlog 實時異地同步 (rsync/kafka/云存儲)
# 每月 1 號 mysqldump 導出核心表 (審計/異構)
# 季度演練全量+增量恢復至測試環境，校驗核心業務數據
關鍵監控與告警
- 備份任務成功/失敗 (Exit code、日志關鍵字
completed OK!)
- 備份耗時超閾值 (全量 > 4h、增量 > 30min)
- 備份文件大小異常變化 (±50%)
- Binlog 積壓未同步 (> 1GB 或 > 30min)
- 磁盤剩餘空間 < 20%
- 恢復演練 RTO/RPO 達標情況
