如何备份 WordPress 站点
使用 mysqldump、tar、cron 和 rclone 备份 WordPress 站点。涵盖文件、MySQL 数据库、异地存储和恢复测试。
一份完整的 WordPress 备份需要同时捕获两部分内容：文件和 MySQL 数据库。缺少任何一部分，恢复都会失败。本指南介绍从命令行实现可靠备份的方法——使用 mysqldump、tar 以及将归档文件推送至异地的 cron 任务——让你真正掌控备份，而不是依赖插件。本文也会客观介绍主机和插件方案，并给出能够验证备份有效性的恢复命令。
核心要点
- 完整的 WordPress 备份包含两个必须同时捕获的部分：文件（核心程序、
wp-content、wp-config.php，以及 Apache 环境下的.htaccess）和 MySQL 数据库——单独恢复其中一部分，站点将无法正常运行。 - 初学者最常见的错误是通过 FTP 备份文件却忘记备份数据库，而所有文章、页面、评论、用户和设置实际上都存储在数据库中。
- 核心命令只需一行：
mysqldump --single-transaction -u USER -p DBNAME > db.sql，其中--single-transaction可对运行中的 InnoDB 数据库生成一致性快照。 - 使用 cron 定时执行 shell 脚本来实现自动化：转储数据库、打包
wp-content，并通过rclone将归档文件推送至服务器外——这就是”按时备份”与”自动备份”之间的本质区别。 - 遵循 3-2-1 原则，切勿将唯一的备份保存在与站点相同的服务器上。
完整的 WordPress 备份包含哪些内容？
WordPress 站点由两个独立的系统组成，备份必须同时涵盖两者。文件部分包括 WordPress 核心程序、wp-content 目录下的所有内容——主题、插件以及 uploads 文件夹（通常是最大的部分）——还有根目录下的 wp-config.php。在 Apache 环境下，还需要保存 .htaccess；而在 nginx 或 Caddy 环境下则不存在 .htaccess，因为重写规则位于 Web 根目录之外的服务器配置中。数据库是一个 MySQL 数据库，存储着文章、页面、评论、用户、分类体系，以及所有插件和主题的设置。
初学者最常见的错误是通过 FTP 备份文件却忘记备份数据库。主题和核心程序可以重新下载，但内容数据无法找回。如果”备份”只包含文件，恢复后的站点将没有任何文章和设置。
WordPress 有哪三种备份方式？
Discover how at OpenReplay.com.
实际上有三种可行的备份方案，它们在便捷性和可控性之间各有取舍。
| 方案 | 可控性 | 可脚本化 | 默认异地存储 | 备注 |
|---|---|---|---|---|
| 主机自动备份 | 低 | 否 | 有时 | 保留周期短；主机宕机时无法访问；通常免责声明中说明由用户自行负责 |
| 备份插件 | 中 | 有限 | 是（可配置） | 可在仪表盘中设置计划和云端上传；对于超大型或高度定制化的站点可能力不从心 |
| 手动 / CLI | 完全 | 是 | 自行决定 | mysqldump + tar + 异地推送；本指南的重点 |
主机备份虽然便捷，但不应作为唯一的备份副本——保留窗口期较短，一旦服务器遭到入侵或发生故障，存储在其上的备份也可能一并丢失。UpdraftPlus 等插件可在仪表盘中处理定时备份和云端上传，对于非技术用户来说是合理的选择。CLI 方案则是开发者可以进行版本控制、定时调度和审计的首选方式。
从命令行备份 WordPress
命令行备份通过 SSH 分三步完成：转储数据库、归档文件，然后将两者拉取到服务器外。首先建立连接：
ssh user@example.com -p 2222然后归档文件并转储数据库：
# 从 Web 根目录的上级目录归档站点文件
tar -zcf files.tar.gz public_html
# 使用一致性快照转储数据库
mysqldump --single-transaction -u DB_USER -p DB_NAME > db.sql--single-transaction 标志是使转储在运行中的站点上可信的关键。只有 InnoDB 表才能以一致性状态进行转储；MyISAM 或 MEMORY 表在转储过程中仍可能发生变化。由于 WordPress 默认使用 InnoDB，--single-transaction 远优于 --lock-tables——它完全不需要锁定表，站点在转储期间可以保持正常运行。请使用 mysqldump 而非 mysqlpump——后者已在 MySQL 8.4 中被移除，调用它的脚本在当前服务器上将直接失败。
使用 scp 将两个文件拉取到本地：
scp -P 2222 user@example.com:~/files.tar.gz .
scp -P 2222 user@example.com:~/db.sql .有一个教程常常忽略的细节：scp 使用大写 -P 指定端口，而 ssh 和 mysqldump 分别使用小写 -p（分别表示端口和密码）。混淆大小写是命令执行失败的经典原因。
如果已安装 WP-CLI，使用 wp db export 会更简洁：它调用 mysqldump 工具，使用 wp-config.php 中指定的 DB_HOST、DB_NAME、DB_USER 和 DB_PASSWORD 凭据，并支持所有有效的 mysqldump 标志。
wp db export --single-transaction db.sql在托管主机和 cPanel 主机上，直接运行 mysqldump 在转储表空间时可能因 PROCESS 权限不足而报错。WP-CLI 已对此做了处理：wp db export 默认会为 mysqldump 添加 --no-tablespaces 参数。在托管主机上直接使用 mysqldump 时，需要手动添加 --no-tablespaces。
使用 cron 和 rclone 自动化 WordPress 备份
通过一个简短的 shell 脚本配合 cron 定时任务，可以实现全流程自动化：转储数据库、打包 wp-content，并将归档文件推送至服务器外。rclone——“云存储版 rsync”——支持 S3、Backblaze B2 和 Google Drive 等多种存储目标。
#!/usr/bin/env bash
set -euo pipefail
SITE_DIR="/var/www/example.com"
DEST="b2remote:example-backups" # 已配置的 rclone 远程存储
STAMP="$(date +%F)"
WORK="$(mktemp -d)"
cd "$SITE_DIR"
# 数据库 —— WP-CLI 从 wp-config.php 读取凭据
wp db export --single-transaction "$WORK/db-$STAMP.sql"
# 文件 —— 主题、插件、上传文件及配置
tar -zcf "$WORK/wp-content-$STAMP.tar.gz" wp-content wp-config.php
# 推送至异地存储
rclone copy "$WORK" "$DEST/$STAMP"
rm -rf "$WORK"在 crontab 中添加以下行，设置每天 03:15 执行并记录日志：
15 3 * * * /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1这就是”掌控备份”的价值所在：无需仪表盘，无需插件，无需手动操作。如果未安装 WP-CLI，可将导出行替换为 mysqldump --single-transaction --no-tablespaces -u DB_USER -pPASS DB_NAME > "$WORK/db-$STAMP.sql"。
遵循 3-2-1 原则存储备份
遵循 3-2-1 原则：至少保留三份站点副本，存储在两种不同类型的介质上，其中一份保存在异地。切勿将唯一的备份存放在与站点相同的服务器上——一旦遭到入侵或磁盘故障，两者将同时丢失。这正是上述自动化脚本将备份推送至对象存储而非留在 Web 根目录的原因。由于归档文件包含站点的完整副本（包括 wp-config.php 中的敏感信息），请为存储目标配置强凭据，并为存储账户启用双因素认证。
测试恢复，以及需要避免的常见错误
未经测试的备份不能算作真正的备份。请定期将 .sql 文件和文件归档恢复到预发布环境或本地站点，以验证副本确实能够重建站点：
tar -xzf wp-content-2026-07-06.tar.gz
wp db import db-2026-07-06.sql # 或者，不使用 WP-CLI：
mysql -u DB_USER -p DB_NAME < db-2026-07-06.sql导致站点数据丢失的三种主要故障模式分别是：只备份文件而未备份数据库、将备份保存在与站点相同的服务器上，以及仅依赖主机的自动备份。上述工作流程可以避免所有这些问题。
可靠的备份方案简单而朴实：一个 cron 任务，一致性地转储数据库、归档文件、将两者推送至异地，并定期进行实际的恢复测试。编写一次脚本，指向对象存储，添加 crontab 行，本周就进行一次恢复测试——这才是你真正掌控的备份，而不是寄希望于某个不知是否在运行的任务。
常见问题
wp db export 和直接运行 mysqldump 有什么区别？
wp db export 是对 mysqldump 的轻量封装。它调用 mysqldump 工具，使用已存储在 wp-config.php 中的 DB_HOST、DB_NAME、DB_USER 和 DB_PASSWORD 凭据，因此无需手动查找或传入连接信息，同时支持所有有效的 mysqldump 标志。它还默认添加 --no-tablespaces，从而避免在托管主机上常见的 PROCESS 权限错误。直接使用 mysqldump 可以生成相同的转储文件，但需要自行提供凭据和标志。
为什么 mysqldump 在托管主机上会抛出 PROCESS 权限错误？如何解决？
在托管主机和 cPanel 主机上，mysqldump 会尝试转储表空间信息，这需要共享数据库用户通常不具备的 PROCESS 权限，从而产生“Access denied; you need the PROCESS privilege”错误。添加 --no-tablespaces 标志可跳过该步骤，使转储正常完成。WP-CLI 的 wp db export 会自动添加 --no-tablespaces。在大多数情况下，即使出现该错误，导出仍会成功，因此请通过检查表是否存在来验证转储文件的完整性。
WordPress 核心和插件可以重新下载，我可以跳过文件备份吗？
你可以减少归档的内容，但绝不能完全跳过文件备份。WordPress 核心、主题和插件可以从各自的来源重新下载，因此部分备份工具只存储数据库加上 uploads 文件夹。然而，uploads 文件夹中存放着所有无法重新下载的媒体文件，wp-config.php 中保存着数据库凭据和密钥，任何自定义或修改过的文件都是不可替代的。备份 wp-content 和 wp-config.php 可以捕获站点中真正独一无二的部分。
如何从 mysqldump 和 tar 备份中恢复 WordPress 站点？
使用 tar -xzf archive.tar.gz 将文件归档解压到站点目录，然后导入数据库。使用 WP-CLI 时，运行 wp db import db.sql，它会从 wp-config.php 读取凭据。不使用 WP-CLI 时，对已存在的数据库运行 mysql -u DB_USER -p DB_NAME < db.sql。两部分必须同时恢复；如果域名发生了变化，还需要对数据库执行搜索替换以更新存储的 URL。在用于生产环境之前，务必先在预发布环境或本地站点上测试恢复流程。
mysqldump 现在还安全可用吗？还是应该切换到 mysqlpump？
请使用 mysqldump，而非 mysqlpump。mysqlpump 工具已在 MySQL 8.0.34 中被标记为废弃，并在 MySQL 8.4 中被完全移除，因此调用它的脚本在当前服务器上将直接失败。mysqldump 仍受支持且持续更新；MySQL 官方推荐使用 mysqldump 或 MySQL Shell 转储工具作为替代方案。对于运行中的 InnoDB 站点，使用带有 --single-transaction 标志的 mysqldump 可在不锁定表的情况下生成一致性快照。
