阅读提示
本文约 2,604 字,预计阅读 7 分钟。文中命令与配置均经过实测,可直接参考执行。
本文约 2,604 字,预计阅读 7 分钟。文中命令与配置均经过实测,可直接参考执行。
引言:有备份 ≠ 能恢复
很多人说”我每天都备份”,但真出事时会发现:
- 备份是半年前的;
- 备份只有数据库,插件主题全丢了;
- 备份存在同一块硬盘上,硬盘坏了备份也没了;
- 备份从没验证过,恢复时才发现文件是空的。
备份的目标是可恢复,不是”存在”。要先定义清楚两件事,再选方案。
原理分析:RPO 与 RTO
| 指标 | 含义 | 举例 |
|---|---|---|
| RPO(恢复点目标) | 最多能丢多少数据 | 每天备份一次 → 最坏丢一天的数据 |
| RTO(恢复时间目标) | 多久能恢复服务 | 全站包恢复 30 分钟 vs 重装 + 导数据 4 小时 |
这两个指标决定了备份方案:
- RPO 要求高(电商、论坛)→ 高频备份 + 数据库主从;
- RTO 要求高(商业站点)→ 全站镜像/快照,一键回滚;
- 两者都不高(个人博客)→ 每日数据库 + 每周全站即可。
保姆级实操:粒度选择
三种备份粒度
| 粒度 | 内容 | 恢复速度 | 体积 | 适用 |
|---|---|---|---|---|
| 全站备份 | 文件 + 数据库 | 快 | 大 | 换服务器、灾难恢复 |
| 仅数据库 | 只 SQL | 需重装 WordPress | 小 | 日常误删、内容回滚 |
| 仅文件(wp-content) | 主题插件上传 | 需重建数据库 | 中 | 代码回滚 |
推荐组合(绝大多数站点)
每日:数据库备份(保留 7 份)+ 每周全站备份(保留 4 份)+ 异地存储一份
按站点类型细化
| 类型 | 频率 | 粒度 | 异地 |
|---|---|---|---|
| 个人博客(更新少) | 每周全站 + 每日数据库 | 中 | 网盘/对象存储 |
| 企业官网 | 每日全站(增量)+ 每日数据库 | 中 | 对象存储 + 本地 |
| 电商/会员站 | 数据库每 6 小时 + 每日全站 | 高 | 双异地 |
| 多站点网络 | 每日整库 | 高 | 对象存储 |
用 WP-CLI 落地每日数据库备份
#!/usr/bin/env bash
# /usr/local/bin/wp-backup.sh
set -euo pipefail
SITE_DIR="/var/www/mimangfei.com"
BACKUP_DIR="/backup/mimangfei"
KEEP=7
mkdir -p "$BACKUP_DIR"
cd "$SITE_DIR"
# 数据库
sudo -u www-data wp db export "$BACKUP_DIR/db-$(date +%F).sql"
gzip -f "$BACKUP_DIR/db-$(date +%F).sql"
# 文件(每周日做一次全量)
if [ "$(date +%u)" -eq 7 ]; then
tar czf "$BACKUP_DIR/files-$(date +%F).tar.gz" wp-content wp-config.php .htaccess
fi
# 清理旧备份
find "$BACKUP_DIR" -name "db-*.sql.gz" -mtime +$KEEP -delete
find "$BACKUP_DIR" -name "files-*.tar.gz" -mtime +28 -delete
加入 crontab:
0 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1
异地存储(3-2-1 原则)
3 份副本、2 种介质、1 份异地。落地方式:
# 对象存储(阿里云 OSS 为例)
ossutil cp /backup/mimangfei/db-*.sql.gz oss://my-backup-bucket/wp/ --update
# 或 rclone 同步到任意网盘
rclone copy /backup/mimangfei remote:wp-backup --backup-dir "remote:wp-backup/old/$(date +%F)"
注意:备份里含数据库账号密码与用户数据,异地存储必须加密,且 bucket 设为私有。
gpg --symmetric --cipher-algo AES256 db-2026-10-10.sql.gz
验证备份有效性(不做等于没备份)
# 每月做一次恢复演练
mysql -u root -p -e "CREATE DATABASE wp_restore_test;"
gunzip < db-2026-10-10.sql.gz | mysql -u root -p wp_restore_test
wp --path=/tmp/restore-test option get home
mysql -u root -p -e "DROP DATABASE wp_restore_test;"
常见踩坑与失败案例
- 备份和站点在同一块盘 —— 磁盘故障一起完蛋。必须异地。
- 案例:某站每天备份,但备份脚本里的数据库密码写错,半年来的备份文件全是 0 字节。从不检查备份日志,出事才发现。备份脚本必须有失败告警(邮件或 webhook)。
- 只备份数据库 —— 插件主题丢失,恢复后站点功能全残。
- 保留份数无限增长撑爆磁盘 —— 一定要配
find -mtime -delete或对象存储的生命周期规则。 - 备份文件权限 644 放在 Web 目录 —— 任何人都能下载你的数据库。备份必须放在 Web 根目录之外。
- 加密后忘记密钥 —— 加密备份要单独保管密钥,否则备份等同于丢失。
总结
设计备份方案只需要回答两个问题:最坏能丢多少数据(RPO) 和 多久要恢复(RTO)。据此定频率、粒度和异地策略。落地时记住三条铁律:异地、可验证、有告警。把备份脚本、清理规则、恢复演练做成固定流程,每季度演练一次。备份这件事的价值,只有在你真的恢复过一次之后才会被理解——在那之前,请至少验证一次你的备份能还原。
觉得有用?点个赞支持一下
标签:
# RPO
# RPO RTO 备份
# RTO
# WordPress 备份策略
# WordPress 备份频率
# 全站备份还是数据库备份
# 备份保留份数
# 备份策略
# 异地备份
# 运维规范
