每天定时备份和三个月才备一次恢复差距不在恢复工具而在备份频率和异地存储，数据库恢复的生存法则全解析

数据库恢复的四层保障，缺任何一层恢复时都可能翻车

一、MySQL批量备份：mysqldump的正确用法

mysqldump是MySQL自带的数据导出工具，免费、稳定、兼容性好，90%的MySQL数据库备份恢复场景它都能搞定。它的核心逻辑是把数据库的表结构和数据导出为SQL文本文件，恢复时重新执行这些SQL语句即可重建数据库。

多站点场景下最推荐的方式是每个数据库单独导出为一个文件，而不是一个--all-databases全量导出。原因很简单：15个站对应15个数据库，如果全量导出一个文件，恢复时必须全部恢复，没法只恢复某一个站。而分别导出的话，哪个站出问题恢复哪个，不会影响其他正常运行的站。

#!/bin/bash# 批量备份MySQL所有数据库（每个库单独一个文件）# 保存为 /opt/scripts/mysql_batch_backup.shBACKUP_DIR="/data/backups/mysql"DATE=$(date +%Y%m%d_%H%M%S)MYSQL_USER="root"MYSQL_PASS="你的密码"RETENTION_DAYS=30  # 保留最近30天的备份# 创建当天备份目录mkdir -p "$BACKUP_DIR/$DATE"# 获取所有数据库列表（排除系统库）DATABASES=$(mysql -u$MYSQL_USER -p$MYSQL_PASS -e "SHOW DATABASES;" | \grep -v "Database\|information_schema\|performance_schema\|mysql\|sys")# 逐个备份for db in $DATABASES; doecho "正在备份: $db"mysqldump -u$MYSQL_USER -p$MYSQL_PASS \--single-transaction \--routines \--triggers \--events \--set-gtid-purged=OFF \"$db" | gzip > "$BACKUP_DIR/$DATE/${db}.sql.gz"if [ $? -eq 0 ]; thenecho "  ✓ $db 备份成功 ($(du -h "$BACKUP_DIR/$DATE/${db}.sql.gz" | cut -f1))"elseecho "  ✗ $db 备份失败！"fidone# 清理超过保留天数的旧备份find "$BACKUP_DIR" -maxdepth 1 -type d -mtime +$RETENTION_DAYS -exec rm -rf {} \;echo "备份完成，备份目录: $BACKUP_DIR/$DATE"

这个脚本的几个关键参数：--single-transaction保证InnoDB表在备份期间的一致性（不会锁表，不影响网站正常运行）；--routines --triggers --events把存储过程、触发器、事件也一起备份（很多人只备份了表结构和数据，丢了这些东西）；gzip压缩大幅减小文件体积，15个WP数据库压缩前可能3-5GB，压缩后通常只有500MB-1GB。

二、批量恢复：单个库恢复和全量恢复的完整命令

备份做完了，恢复才是关键时刻。恢复分两种场景：单个库恢复（某一个站的数据出了问题需要回滚）和全量恢复（服务器挂了所有数据库都需要重建）。

#!/bin/bash# 批量恢复MySQL数据库# 用法: ./mysql_batch_restore.sh [单个数据库名或"all"]BACKUP_DATE="$2"  # 指定恢复哪个日期的备份，如 20250728_030000BACKUP_DIR="/data/backups/mysql/$BACKUP_DATE"MYSQL_USER="root"MYSQL_PASS="你的密码"restore_single_db() {local db=$1local backup_file="$BACKUP_DIR/${db}.sql.gz"if [ ! -f "$backup_file" ]; thenecho "✗ 备份文件不存在: $backup_file"return 1fiecho "正在恢复: $db"# 先删除旧库再重建（确保干净恢复）mysql -u$MYSQL_USER -p$MYSQL_PASS -e "DROP DATABASE IF EXISTS \`$db\`; CREATE DATABASE \`$db\`;"gunzip < "$backup_file" | mysql -u$MYSQL_USER -p$MYSQL_PASS "$db"if [ $? -eq 0 ]; thenecho "  ✓ $db 恢复成功"elseecho "  ✗ $db 恢复失败！"fi}restore_all() {echo "===== 开始批量恢复所有数据库 ====="local total=0local success=0for f in "$BACKUP_DIR"/*.sql.gz; doif [ -f "$f" ]; thendb=$(basename "$f" .sql.gz)total=$((total+1))restore_single_db "$db" && success=$((success+1))fidoneecho "===== 恢复完成: $success/$total 个数据库成功 ====="}# 主逻辑if [ "" = "all" ]; thenrestore_allelif [ -n "" ]; thenrestore_single_db ""elseecho "用法: 

wp_site1 20250728_030000"echo "示例: all 20250728_030000"fi

· 在生产环境恢复前，先在测试环境跑一遍确认SQL文件可用

mysqldump做全量备份 + WP-CLI做迁移时的URL替换。mysqldump负责每天定时导出所有WP数据库，WP-CLI负责在需要迁移到新服务器时批量替换域名：

# WP-CLI批量替换域名（迁移到新服务器后执行）wp search-replace 'http://旧域名.com' 'https://新域名.com' \--all-tables --precise --dry-run # 先dry-run预览，确认无误后去掉--dry-run正式执行# 遍历所有WP站点批量替换for site in /var/www/*/; docd "$site"if [ -f wp-config.php ]; thenecho "处理: $site"wp search-replace 'oldsite.com' 'newsite.com' --all-tables --precisefidone

在备份脚本后面加几行，自动把备份文件同步到云存储。以阿里云OSS为例，用ossutil命令行工具：

# 在mysql_batch_backup.sh末尾追加异地同步# 同步到阿里云OSS（提前安装ossutil并配置好AK）ossutil cp -r "$BACKUP_DIR/$DATE" oss://你的bucket名/mysql-backups/ --update# 或者同步到另一台服务器rsync -avz --delete "$BACKUP_DIR/" backup@192.168.1.100:/data/backups/mysql/# 或者用rclone同步到Google Driverclone copy "$BACKUP_DIR/$DATE" gdrive:mysql-backups/

设置crontab让备份脚本每天凌晨3点自动跑：

# crontab -e 添加以下行# 每天凌晨3点执行数据库备份0 3 * * * /bin/bash /opt/scripts/mysql_batch_backup.sh >> /var/log/mysql_backup.log 2>&1# 每周日凌晨4点检查备份日志并发送汇总邮件（可选）0 4 * * 0 tail -20 /var/log/mysql_backup.log | mail -s "数据库备份周报" admin@example.com

备份脚本每天在跑，日志显示"备份成功"，云存储上文件大小也正常。等到真需要恢复的时候才发现——备份文件是损坏的，SQL语法有错误，或者导出时漏了某个关键表。这不是假设，是真实发生过的。

每月抽一个备份文件，恢复到一台测试服务器上，确认数据完整可用。不需要全部恢复，只需要随机抽一个库验证。如果15个站点，每月随机抽3个库恢复验证，三个月轮完一轮。< "$RANDOM_FILE" | mysql -u$MYSQL_USER -p$MYSQL_PASS "$TEST_DB"if [ $? -eq 0 ]; then# 验证：查表数量和行数TABLE_COUNT=$(mysql -u$MYSQL_USER -p$MYSQL_PASS -e "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='$TEST_DB';" -N)echo "✓ 恢复成功！共 $TABLE_COUNT 张表"# 清理测试库mysql -u$MYSQL_USER -p$MYSQL_PASS -e "DROP DATABASE \`$TEST_DB\`;"elseecho "✗ 恢复失败！备份文件可能损坏: $RANDOM_FILE"# 发送告警fi

#!/bin/bash# 恢复验证脚本：随机抽取一个数据库恢复到测试环境# 在测试服务器上运行BACKUP_DIR="/mnt/backups/mysql"TEST_DB_PREFIX="verify_" # 测试恢复的数据库名前缀MYSQL_USER="root"MYSQL_PASS="测试环境密码"# 随机选一个备份日期RANDOM_DATE=$(ls "$BACKUP_DIR" | sort -R | head -1)echo "验证日期: $RANDOM_DATE"# 随机选一个数据库备份文件RANDOM_FILE=$(ls "$BACKUP_DIR/$RANDOM_DATE"/*.sql.gz | sort -R | head -1)DB_NAME=$(basename "$RANDOM_FILE" .sql.gz)TEST_DB="${TEST_DB_PREFIX}${DB_NAME}"echo "验证数据库: $DB_NAME -> $TEST_DB"# 恢复到测试库mysql -u$MYSQL_USER -p$MYSQL_PASS -e "DROP DATABASE IF EXISTS \`$TEST_DB\`; CREATE DATABASE \`$TEST_DB\`;"gunzip

这个脚本每月跑一次，放到crontab里。如果恢复失败立即告警，说明备份脚本或备份文件出了问题，赶在真正需要恢复之前修复。

UC建站系统

数据库修复有一个铁律：修复之前先备份当前的数据库文件（包括损坏的）。

innodb_force_recovery