核心思路：備份腳本 + crontab 排程，將備份邏輯封裝為獨立可執行檔，排程僅負責觸發，便於維護與測試。
mkdir -p /mysqlbackup/usr/sbin/bak_mysql.sh#!/bin/bash
# 取得日期標籤（YYYYMMDD）
DATE_TAG=$(date +%Y%m%d)
# 方式一：直接打包資料目錄（需停庫或鎖表，適合純 MyISAM/小型庫）
# tar -zcvf /mysqlbackup/mysql_${DATE_TAG}.tar.gz /var/lib/mysql
# 方式二：邏輯備份 mysqldump（推薦，支援 InnoDB 熱備份、跨版本遷移）
mysqldump --all-databases -u root -p'YourPassword' --single-transaction --routines --triggers --events \
> /mysqlbackup/mysql_${DATE_TAG}.sql
# 可選：壓縮 SQL 檔
gzip -f /mysqlbackup/mysql_${DATE_TAG}.sql關鍵參數說明：
--single-transaction：InnoDB 一致性非阻塞備份--routines --triggers --events：包含存儲過程、觸發器、事件-p'Password'：密碼緊跟 -p 後無空格；生產環境建議改用 --defaults-extra-filechmod +x /usr/sbin/bak_mysql.shvi /etc/crontab新增以下行（欄位：分 時 日 月 週 使用者 指令）：
# 每天凌晨 3:01 執行完整備份
1 3 * * * root /usr/sbin/bak_mysql.sh
# 如需每小時增量備份（需配合二進位日誌），另行規劃
# 2 * * * * root /usr/sbin/bak_mysql_incremental.sh# CentOS/RHEL 6/7
service crond restart
# 或
systemctl restart crond
# Debian/Ubuntu
service cron restart
# 或
systemctl restart cronls -lh /mysqlbackup/
# 預期輸出
mysql_20240520.sql.gz
mysql_20240521.sql.gz
...| 問題 | 原因 | 解決 |
|---|---|---|
| 備份檔為 0 byte | mysqldump 密碼錯誤、權限不足、資料庫服務未啟動 | 手動執行腳本觀察錯誤輸出；檢查 /var/log/cron |
| crontab 不執行 | 腳本無執行權限、Shebang 缺失、環境變數 PATH 不同 | 腳本首行 #!/bin/bash；指令使用絕對路徑 /usr/bin/mysqldump |
| 備份檔案過大佔滿磁碟 | 無清理策略 | 腳本末尾加入 find /mysqlbackup -mtime +7 -name '*.gz' -delete 保留 7 天 |
| 還原測試失敗 | 未定期演練、缺少 --master-data=2 導致無法定位 Binlog 位點 | 每季進行一次完整還原演練；備份時加入 --master-data=2 |
# 腳本末尾新增 rsync 推送至備份伺服器
rsync -avz --password-file=/etc/rsync.pass /mysqlbackup/ backupuser@192.168.1.100::mysql_backup/搭配 Zabbix 監控 /mysqlbackup 目錄下最新檔案大小、修改時間、磁碟剩餘空間，實現「備份可見、異常即知」。
crontab + mysqldump 是最輕量、相容性最廣的 MySQL 定時備份方案。關鍵在於：腳本健壯、權限最小、定期演練、異地留存。將備份納入基礎設施代碼（IaC）管理，才能真正做到「備份無憂」。
