网站备份策略实战：数据库与文件自动备份到异地

网站备份策略的目标不是生成备份文件，而是能恢复。多数数据丢失事故不是没做备份，而是备份不可用：脚本静默失败、压缩包损坏、恢复时缺了配置。按「定义目标 → 自动执行 → 异地存放 → 恢复演练」展开，脚本可直接在 Linux 跑。

一、先定义恢复目标，再决定备份策略

备份频率由业务能容忍的数据丢失量决定

1. 用 RPO 与 RTO 反推频率

RPO 是可容忍丢失的数据时长，RTO 是从故障到恢复的耗时。日更博客 RPO 取 24 小时即可；订单类站点要在 1 小时以内，需在全量备份之外叠加 binlog 增量，靠 mysqlbinlog 回放到故障前一刻。RTO 决定取回方式：本地磁盘恢复几分钟，从对象存储拉快照可能半小时。

2. 备份内容要覆盖三部分

只备份站点根目录是常见疏漏。完整备份含三部分：站点代码与上传目录、数据库全量导出、服务端配置（Nginx、PHP、SSL 证书、crontab）。上传图片丢了无法找回，配置缺失时即便数据完好，重建环境也得多花几小时。

二、数据库与文件的自动化备份

两类对象用不同工具：数据库走 mysqldump，文件走 rsync 增量同步。

1. mysqldump 全量备份脚本

关键是加 --single-transaction，让 InnoDB 不锁表就能拿到一致性快照；配合 gzip，1GB 的库通常压到 150MB。

DATE=$(date +%F_%H%M); mkdir -p /data/backup/db
mysqldump --single-transaction --quick -u backup_user -p'密码' --databases blog_db | gzip > /data/backup/db/blog_$DATE.sql.gz
find /data/backup/db -name "*.sql.gz" -mtime +7 -delete

--quick 让 mysqldump 逐行读取结果集而非一次性载入内存，大表下可降低内存占用。备份账号只需 SELECT、LOCK TABLES、SHOW VIEW、TRIGGER 权限，不要用 root，避免脚本成为提权入口。

2. rsync 增量同步与保留策略

文件备份用 rsync 增量传输，只同步变化的字节：

rsync -az --delete --exclude='cache/' --exclude='*.log' /www/wwwroot/blog/ /data/backup/files/blog/

-a 保留权限与时间戳，-z 压缩传输，--delete 让目标与源保持一致。但 --delete 只在源目录健康时用，否则源上的误删会同步进备份。建议每日同步到本地盘、每周另打完整快照。

三、异地存放与恢复演练

本地备份挡不住磁盘损坏和误删整目录，异地备份才是最后一道防线。

1. 异地存储与加密上传

用对象存储命令行工具把当日备份推到异地桶，或 rsync over SSH 推到另一机房。敏感数据先用 gpg --symmetric 加密再上传，避免备份桶被读后明文泄露整个库。开启版本控制，30 天前的备份自动转低频存储，压降成本。

2. 每月恢复演练与完整性校验

没演练过的备份等于没有备份。每月至少做一次恢复演练，执行 gunzip -c blog.sql.gz | mysql -u root blog_db，确认可完整导入，并用 gzip -t 校验压缩包未损坏。重点验证：导入无报错、首页能正常打开、上传的图片可访问。

关键配置提示

• 脚本开头加 set -e，任一命令失败立即中止，避免生成半截文件被误认成成功。
• 用 crontab 执行时写绝对路径，并在末尾追加一行日志，便于排查任务没跑的问题。
• 把备份脚本本身纳入版本控制，服务器重装后能拉起整套流程。