「我就改一行 CSS，能出什么事？」
「我就删个插件，又不动数据库。」
「网站跑三年了，从来没出过问题。」
这三句话，是数据事故的标准前奏。
一、先看几个真实的场景
场景 1：改代码改崩了
改 functions.php 少了个分号 → 白屏 → 后台进不去 → 你没有备份 → 只能一点一点回忆改了什么。
如果这次改的是三个月前的一次改动叠加这次的改动，你可能根本想不起来原版是什么样。
场景 2：更新插件后网站挂了
点了「全部更新」，其中一个插件和新版 WordPress 不兼容 → 网站报错 → 你没有更新前的备份。
你能做的只有：一个一个回滚插件版本，祈祷能试对。
场景 3：误删内容
后台批量操作，选错了，删掉了 200 个产品。回收站清空了。
没有备份 = 200 个产品要重新上传，包括图片、描述、价格、变体。这是几天的工作量。
场景 4：服务器故障 / 服务商跑路
主机商硬盘故障、公司倒闭、账号被封。整台服务器上的东西全没了——包括你以为「服务商会备份」的那些数据。
场景 5：被黑
网站被挂马，你清理完发现页面结构也被改了。想恢复到被黑之前的状态——但你的备份是三个月前的，而且备份本身也是被感染的状态。
二、备份到底要备什么
很多人以为「备份了网站文件」就够了。不够。
一个 WordPress 站由两部分组成，缺一不可：
| 部分 | 包含什么 | 位置 |
|---|---|---|
| 文件 | WordPress 程序、主题、插件、上传的图片 | /wp-content/ 是重点 |
| 数据库 | 文章内容、产品数据、订单、用户、设置 | MySQL |
只备份文件：能恢复程序和图片，但你的文章、产品、订单全没了。
只备份数据库：内容还在，但图片和主题没了，网站打不开。
优先级
- 数据库（最重要，体积小，变化频繁）
- wp-content/uploads（你的图片，丢了没法重新生成）
- 主题和插件（可以重新下载，但定制过的主题必须备份）
- WordPress 核心文件（可以从官方重新下载，优先级最低）
三、多久备份一次
取决于你的网站数据变化频率：
| 网站类型 | 数据库备份 | 文件备份 |
|---|---|---|
| 电商站（每天有订单） | 每天 | 每周 |
| 内容站（经常发文章） | 每天或每周 | 每周 |
| 企业展示站（很少更新） | 每周 | 每月 |
原则：能接受丢多少数据，就按那个频率备份。
「上周三的备份」意味着你可能丢一周的数据——如果那一周有 30 个订单，你能接受吗？
四、备份存在哪：3-2-1 原则
这是业界公认的备份原则：
- 3 份副本
- 2 种不同介质
- 1 份在异地
为什么不能只存在本机
最常见的错误：备份文件就放在网站的服务器硬盘上。
问题：
- 服务器硬盘坏了 → 备份一起没
- 服务器被入侵 → 攻击者可以删掉你的备份
- 磁盘满了 → 备份失败但你不知道
异地方案对比
| 方案 | 成本 | 推荐度 | 说明 |
|---|---|---|---|
| 对象存储（阿里云 OSS / 腾讯云 COS / AWS S3） | 极低（几十 GB 每月几元） | ★★★★★ | 最推荐，自动上传，可靠 |
| 另一台服务器 | 看你有没有 | ★★★★ | 用 rsync/scp 定时同步 |
| 网盘（坚果云、OneDrive、Google Drive） | 免费/低 | ★★★ | 需要脚本同步，容量有限 |
| 本地硬盘（手动下载） | 0 | ★★ | 可靠但依赖人记得下载 |
| GitHub / GitLab 私有仓库 | 免费 | ★★ | 只适合代码，不适合大型备份 |
推荐组合：服务器本地留一份（快速恢复）+ 对象存储留一份（异地容灾）。
五、怎么配（三种难度）
难度 1：插件方案（最简单）
装 UpdraftPlus（免费版够用）：
- 设置 → 备份计划：数据库每天，文件每周
- 远程存储：选你的对象存储或网盘，填入密钥
- 保留份数：设 3-5 份
十分钟配完，之后全自动。这是大多数站的最优解。
难度 2：宝塔面板的计划任务
面板 → 计划任务 → 添加：
- 备份数据库：每天，保留 7 份
- 备份网站：每周，保留 4 份
- 备份到对象存储：宝塔支持 OSS/COS 等，配置一下
难度 3：自己写脚本（最可控）
#!/bin/bash DATE=$(date +%Y%m%d) BACKUP_DIR="/backup" SITE_DIR="/www/wwwroot/你的站点" # 备份数据库 mysqldump -u用户名 -p密码 数据库名 | gzip > $BACKUP_DIR/db-$DATE.sql.gz # 备份文件（只备份 wp-content，核心文件可以从官方重新下载） tar -czf $BACKUP_DIR/site-$DATE.tar.gz $SITE_DIR/wp-content # 上传到对象存储（以阿里云 OSS 为例，需先装 ossutil） ossutil cp $BACKUP_DIR/db-$DATE.sql.gz oss://你的bucket/ ossutil cp $BACKUP_DIR/site-$DATE.tar.gz oss://你的bucket/ # 删除 30 天前的本地备份 find $BACKUP_DIR -name "*.gz" -mtime +30 -delete
加到 crontab 每天跑。
六、最关键的一步：验证备份能用
没验证过的备份，有很大概率恢复不了。
为什么会失效
- 备份任务早就失败了（磁盘满、密码改了、密钥过期），但没人看
- 备份文件损坏（传输中断、磁盘错误）
- 备份的是被感染的版本（网站被黑之后你才发现的备份，里面就有后门）
- 你根本不记得备份文件在哪、怎么恢复
怎么验证
每季度做一次恢复演练：
- 在一台临时环境（本地或者其他服务器）装一个空的 WordPress
- 把备份恢复进去
- 打开看：页面正常吗？图片在吗？文章和产品数量对吗？
花一小时，换来的是真出事时的确定性。很多人是在真正需要恢复的时候，才发现备份根本用不了。
七、改网站前的四步检查
养成习惯，每次动网站之前：
- 确认最近一次备份是成功的（去看一眼备份文件的时间戳，别只看任务状态）
- 如果这次改动比较大，先手动做一次备份（一分钟的事）
- 如果只改一个文件，至少把那个文件下载一份到本地
- 确认你知道怎么回滚
第 3 条是最轻量的做法，但能挡住 80% 的事故——改一个文件改崩了，把原文件传回去就好了。
八、几个特殊提醒
网站迁移时不要删旧服务器
搬完家、测试通过之后，旧服务器至少保留一周再释放。很多迁移后才发现的小问题，靠旧服务器能救回来。
大版本升级前单独做一份备份
PHP 版本升级、WordPress 大版本升级、主题大改版——这些操作前单独存一份备份，并标注清楚（比如命名为 before-php8-upgrade）。
普通的每日备份会滚动覆盖，等你发现问题的时候，升级前那份可能已经被覆盖掉了。
电商站的订单数据要额外小心
如果你要恢复数据库，注意别把新订单覆盖掉。正确做法：
- 先导出当前数据库（哪怕是有问题的）
- 恢复备份
- 对比两份数据，把新增订单手动补回去
最后
备份这件事，价值在于「永远不用」——所以人总是拖延。
但换个角度想：一个运营了三年的网站，里面的内容、产品、客户数据，重做一遍要多久？几天到几周，而且可能永远无法完全还原。
而配好自动备份的时间：十分钟。
这笔账不需要算第二遍。