一、备份是运维的底线
做 IDC 运维多年，最深的体会是：机器可以宕，业务可以挂，但数据不能丢。磁盘损坏、误删文件、勒索病毒、机房火灾——任何一次灾难都可能让多年的数据灰飞烟灭。备份不是"有空再做"的锦上添花，而是运维工作的底线。本文从备份策略、rsync 增量同步、异地容灾三个层面，讲清楚一套可落地的备份体系。
二、先定备份策略：3-2-1 原则
业界公认的备份黄金法则是 3-2-1：至少 3 份数据副本，存储在 2 种不同的介质上，其中 1 份存放在异地。落到 IDC 场景就是：本机一份、备份服务器一份、异地机房或云对象存储一份。备份频率按业务重要性分级：核心数据库每日全备 + 每 2 小时增量；重要配置文件每日备份；日志类数据保留 30 天即可。
同时要明确保留周期：全量备份一般保留 7~14 天，增量备份保留 30 天，月度归档保留 12 个月。定期清理过期备份，避免备份盘被写满——备份盘写满导致备份静默失败，是运维里最隐蔽的事故之一。
三、rsync 增量同步详解
rsync 是 Linux 下最强大的文件同步工具，支持增量传输、断点续传、SSH 加密传输，是搭建备份体系的核心组件。先看最常用的命令：
# 本机目录同步（镜像模式，慎用 --delete） rsync -avz /data/www/ /backup/www/ # 推送到远程备份服务器 rsync -avz --delete /data/www/ rsync@backup.7ehl.com:/backup/www/ # 从远程拉取 rsync -avz rsync@backup.7ehl.com:/backup/www/ /data/www/ # 限速传输，避免影响业务带宽 rsync -avz --bwlimit=2048 /data/www/ /backup/www/
参数说明：-a 归档模式（保留权限、属主、时间戳），-v 显示过程，-z 传输时压缩，--delete 删除源端已不存在的文件（保持两端完全一致）。重要提醒：--delete 是双刃剑，如果源目录路径写错或挂载失败，会瞬间把备份目录清空，务必在命令里加 --dry-run 先演练一遍。
四、用 rsync + SSH 密钥实现免密自动备份
定时备份必须免密执行。先生成 SSH 密钥并分发到备份服务器：
# 在源服务器生成密钥（一路回车即可） ssh-keygen -t ed25519 # 将公钥拷贝到备份服务器 ssh-copy-id rsync@backup.7ehl.com # 测试免密登录 ssh rsync@backup.7ehl.com 'echo OK'
然后编写备份脚本 /usr/local/bin/backup_www.sh：
#!/bin/bash
# 网站目录备份脚本
BACKUP_HOST="rsync@backup.7ehl.com"
BACKUP_DIR="/backup/www"
SRC_DIR="/data/www"
LOG="/var/log/backup.log"
echo "[$(date '+%F %T')] 开始备份 $SRC_DIR" >> $LOG
rsync -avz --delete --bwlimit=2048 \
--exclude='cache/' --exclude='tmp/' \
$SRC_DIR/ ${BACKUP_HOST}:${BACKUP_DIR}/ >> $LOG 2>&1
if [ $? -eq 0 ]; then
echo "[$(date '+%F %T')] 备份成功" >> $LOG
else
echo "[$(date '+%F %T')] 备份失败！请检查" >> $LOG
fi用 --exclude 排除 cache、tmp 这类无需备份的临时目录，能大幅缩短备份时间、减少带宽占用。
五、数据库备份与一致性保证
文件同步解决不了数据库的一致性问题——直接 rsync 数据文件，备份出来的可能是写了一半的脏数据。MySQL 必须用官方工具导出：
# 全量备份（含锁表保证一致性） mysqldump -uroot -p --single-transaction --master-data=2 \ --all-databases | gzip > /backup/mysql/full_$(date +%F).sql.gz # 定时任务：每天凌晨 2 点全备 0 2 * * * /usr/local/bin/backup_mysql.sh # 备份后 rsync 到异地 rsync -avz /backup/mysql/ rsync@backup.7ehl.com:/backup/mysql/
备份完成后必须做恢复演练：定期把备份文件恢复到测试库，验证数据可读、可还原。没有验证过的备份等于没有备份。
六、异地容灾与冷备介质
光有备份服务器还不够——如果备份服务器和业务服务器在同一个机房，机房断电或火灾时数据依然全灭。所以要异地容灾：
# 每日增量同步到异地机房 rsync -avz --delete rsync@backup.7ehl.com:/backup/ rsync@dr.7ehl.com:/backup/ # 或上传到云对象存储（如阿里云 OSS、腾讯云 COS） ossutil cp -r -u /backup/ oss://my-bucket/backup/
对于核心数据（数据库、证书私钥、配置），建议每月刻录一次光盘或写入离线硬盘，妥善保管在保险柜——这是抵御勒索病毒的最后防线，因为离线介质不受网络攻击影响。
七、备份监控：让备份失败第一时间被发现
备份脚本跑没跑、成没成功，不能靠肉眼去看。三件事必做：
1. 日志留痕：所有备份操作写入 /var/log/backup.log，保留 90 天。
2. 结果检查：脚本末尾比对备份文件大小和时间，异常时退出码非 0。
3. 告警通知：备份失败立即发告警，可结合企业微信/钉钉机器人 Webhook：
curl -s -X POST 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=XXXX' \
-H 'Content-Type: application/json' \
-d '{"msgtype":"text","text":{"content":"【告警】备份失败！'$(hostname)' 请立即检查"}}'八、灾难恢复演练
备份体系的最后一块拼图是演练。建议每季度做一次：
# 1. 在测试机恢复最新全量备份 gunzip -c full_20260810.sql.gz | mysql -uroot -p # 2. 应用增量备份 mysqlbinlog binlog.000123 | mysql -uroot -p # 3. 校验数据完整性 mysql -e "SELECT COUNT(*) FROM orders;" # 4. 恢复后启动业务，验证服务正常
记录每次演练的恢复耗时，目标 RTO（恢复时间目标）一般不超过 4 小时，RPO（数据丢失容忍）不超过 2 小时。如果演练发现恢复不了，问题一定出在备份环节，趁早修正，别等灾难真来了才后悔。
九、总结
一套合格的备份体系 = 明确的 3-2-1 策略 + rsync 增量同步 + 数据库一致性备份 + 异地容灾 + 失败告警 + 定期演练。工具本身不复杂，难的是坚持执行和验证。从今天开始，把备份脚本写好、调度配上、告警接通、演练排上日程——这是花最小成本买最大保险的运维投资。
评论