备份与恢复
没演练过的备份，等于没有备份
十个被误删、被改坏、被升级搞崩的站里，有七个说自己”有备份”。真到要用的那天，才发现备份停在半年前、压缩包打不开、或者只备了数据库没备 uploads。这一页写给正在给企业站定备份制度的人，讲清备什么、多久备一次、存在哪、以及怎么在真正出事之前先演练一遍恢复。
三样东西缺一不可
少一样都恢复不出原样
WordPress 的数据分散在两处：数据库存内容和配置，文件系统存程序、主题、插件、图片。两者必须来自同一时刻，差一天就会出问题——数据库里有新文章的记录，配图文件还没上传，恢复后就是一片裂图。
数据库
体积小、变化快，是备份里最该高频的一份。一个两千篇文章的企业站，导出的 SQL 通常在 30 到 120MB 之间。别只信插件生成的压缩包，定期用命令行导一次，能顺便验证数据库本身是否健康。
- 包含文章、页面、菜单、用户、插件配置
- 不含图片、不含主题模板文件
wp-content 目录
站点的真实重量在这里。uploads 三年下来轻松到几个 GB，如果做过产品图批量上传，十几个 GB 也常见。很多”备份成功”的假象，就是备份工具默认排除了 uploads。
- 主题、插件、上传文件都在这一层
- cache 与 backup 子目录可以排除，能省一半体积
根目录配置文件
wp-config.php、.htaccess、robots.txt 这些几 KB 的文件，恢复时最容易被忘。数据库密码、伪静态规则、站点验证文件全在里面，丢了要一项项重配。
还有一个反直觉的点：备份文件不能放在网站目录里。放在 /wp-content/backup/ 或根目录的 ZIP，一旦目录索引没关、或文件名可预测，任何人用浏览器就能把整站拖走。备份要落在 web 根目录之外，或直接推到对象存储。
多久备一次
按”能接受丢多少”倒推
备份频率不是拍脑袋定的，它由两个问题决定：站点多久变一次，出事后能接受退回多久之前。
按更新节奏分档
- 纯展示型企业站：数据库每日一次，文件每周一次
- 每周发 2 到 5 篇内容的站：数据库每日两次，文件每周一次
- 商城或有询盘表单的站：数据库每 6 小时一次，文件每日一次
- 大促、展会前一周：临时改为每日全量，活动结束再降回来
保留策略用滚动窗口
常见做法是”近 7 天每天一份 + 近 4 周每周一份 + 近 12 个月每月一份”。这样既能应对”昨天手滑删了一个产品”，也能应对”三个月前被植入的东西一直没发现”。只留最近 3 份是最典型的错误：问题潜伏超过一周，所有备份就都被污染了。
3-2-1 不是口号
三份副本、两种介质、一份异地。落到实处是：服务器本地一份用于快速回滚，对象存储一份应对整机故障，本地电脑或 NAS 一份应对前两者同时失效。三份都在同一台服务器上，在硬盘损坏或欠费停机面前等于零。
两种常用方式
插件与命令行
日常交给插件跑定时任务，迁移和大改之前用命令行做一份干净快照，两者互补。
UpdraftPlus 后台配置
装在「插件 → 安装插件」里，启用后进「设置 → UpdraftPlus 备份」。要动的几个选项：备份计划里把文件与数据库分开设频率；”保留备份”填 7；”分段上传”在小内存主机上必须打开，否则大站会在 90% 处卡死；排除列表里加上 cache、ai1wm-backups、wp-content/upgrade。
- 远程存储建议选对象存储，别只存本地
- 首次备份完成点”立即重新扫描远程存储”确认可读
mysqldump 与 wp db export
SSH 里最稳的一条：mysqldump -u 用户 -p --single-transaction --quick 库名 | gzip > db-$(date +%F).sql.gz。--single-transaction 保证 InnoDB 的一致性快照，不锁表。装了 WP-CLI 的话 wp db export backup.sql 更省事，会自动读 wp-config 里的连接信息。
- 导出前确认磁盘留有 2 倍数据库体积
- 导完 gunzip 看一眼结尾有没有 Dump completed
恢复演练
每季度做一次，别等出事
演练不是”证明备份能用”，而是把恢复流程跑熟、把隐藏问题提前暴露。我们做维护时，季度演练是固定动作，通常放在流量最低的周三上午。
搭一个隔离环境
在测试子域或另一台低配服务器上还原，绝不要直接在生产站上试。数据库名、用户名、密码先建好，字符集统一用 utf8mb4，排序规则跟原站一致，否则中文和表情符号会变成问号。
先文件后数据库
按”程序文件 → wp-content → 数据库”的顺序还原。先导数据库再放文件也可以，但要在导完数据库后立刻把 .maintenance 文件删掉，否则前台一直显示”Briefly unavailable for scheduled maintenance”。
换域名用序列化安全工具
测试环境域名不同，必须替换数据库里的旧域名。不要用 phpMyAdmin 的”查找替换”，主题选项、页面构建器数据都是序列化字符串，长度字段对不上就整段失效。用 wp search-replace 'https://old.com' 'https://test.old.com' --all-tables --precise。
跑一遍验证清单
首页、产品详情、表单提交、后台登录、媒体库缩略图、多语言切换，逐项点。缩略图全裂说明 uploads 没还原完整；后台能进但前台 404 说明 .htaccess 漏了。
恢复后打不开
三种现象对三种原因
恢复失败很少是”备份坏了”，更多是环境差异。下面这些报错原文，运维同事一年能碰上几十次。
Error establishing a database connection
wp-config 里的库名、用户、密码、主机四项与新环境不符。注意 DB_HOST 在新主机上常常不是 localhost，而是带端口的内网地址。改完仍然报错，检查数据库用户是否授权了该库。
整站白屏，无任何报错
多半是 PHP 版本落差。老站跑在 7.4，新服务器默认 8.2，主题里一处过时语法就足以致命。临时在 wp-config 打开 WP_DEBUG 看具体行号，但不要在生产环境长时间开着，报错会把绝对路径暴露给访客。
后台进得去，前台全是 404
伪静态规则没跟过来。Apache 环境要重新生成 .htaccess，Nginx 要在站点配置里补 try_files。这个问题在换服务器时几乎必现，处理细节见固定链接与伪静态规则。
三种备份方案对比
按站点规模选
成本一列只写相对量级，具体以服务商当期报价为准。
| 方案 | 覆盖范围 | 恢复耗时 | 适用规模 | 主要短板 |
|---|---|---|---|---|
| 插件定时备份到对象存储 | 数据库 + 指定目录 | 30 分钟至 2 小时 | 5GB 以下企业站 | 大站在压缩阶段易超时 |
| 命令行全量 + rsync 异地 | 整站含隐藏文件 | 1 至 4 小时 | 10GB 以上或商城 | 需要 SSH 权限与脚本维护 |
| 主机面板快照 | 整台服务器 | 10 至 40 分钟 | 不想折腾的中小站 | 粒度粗，单文件误删也要整机回滚 |
| 混合方案（推荐） | 快照兜底 + 每日增量 | 按场景 10 分钟至 2 小时 | 有询盘与订单的站 | 成本略高，需定期核对一致性 |
无论选哪种，都要把”备份成功”和”备份可用”分开验证。我们习惯在任务跑完的第二天抽查一个压缩包：解压、看文件数、看 SQL 结尾是否完整。这步不做，前面所有配置都只是心理安慰。恢复后若出现表损坏提示，处理思路见WordPress 数据库报错处理。
备份恢复常见五问
不能。插件只保证”打包并上传完成”，不保证内容完整。常见问题是压缩时 PHP 超时导致包被截断、分片上传只成功一半、数据库导出到一半断连。判断依据是包大小是否和上次接近、能否正常解压、SQL 结尾有没有 Dump completed。
商城每季度一次，纯展示站每半年一次。另外两个时间点必须做：换服务器之前、大版本升级之前。不需要全员参与，一个人按文档走一遍、记下耗时和卡点就够。
可以，大站上反而更合理。uploads 变化少、体积大，适合 rsync 增量同步，每天只传新增的几十 MB；数据库体积小变化快，适合高频全量。总耗时比每次整站打包短得多，前提是两边的还原时间点能对上。
要看备份时间点。入侵可能潜伏数周，最近几份备份里已经带了后门，回滚只是把马一起搬回来。正确顺序是先定位最早的异常时间，找一份早于该时间的干净备份，恢复后立刻改全部密码与密钥，再做加固。流程见WordPress 安全加固与木马清理。
先排除三类可再生文件：缓存目录、备份目录自身、旧版核心升级包。图片不要二次压缩，那是画质损失不是节省。更有效的是把 uploads 里几年不用的原图做冷存储分层，热数据留本地。
不确定现有备份能不能用
我们替你跑一次恢复
提供主机面板入口与备份文件位置，我们先做一次只读检查：包是否完整、是否含 uploads、数据库能否导入，再在隔离环境实跑一遍恢复。也可以直接并入年度维护，把备份、更新、演练做成固定节奏。相关阅读：UpdraftPlus 备份插件、WordPress 托管维护。
电话/微信 13280692153 邮箱 web@wordpressx.com 地址 山东省淄博市张店区电子产业创新园 B 座