WordPress 重装与故障恢复：安全备份、核心修复和迁移手册

先恢复服务能力，不要把“重装”当作清空

WordPress 的核心程序、站点内容和运行配置是不同资产。替换核心文件通常不需要删除数据库、wp-config.php 或 wp-content；恢复备份也不应先运行全新安装向导。本手册最后核对于 2026 年 9 月 1 日，目标是在可回滚、可验证的前提下处理故障，而不是用删除掩盖原因。

如果怀疑入侵，重装核心并不等于清除后门。先隔离主机、保全日志和磁盘证据，停止执行站点中的 PHP、WP-CLI、插件和 MU 插件，并按事件响应流程轮换凭据、密钥与 salts。只有在确认不是安全事件，或已在可信环境完成取证后，才执行下面的站点命令。

1. 先分类事件并决定停机窗口

情况	典型证据	正确起点
核心文件损坏或校验失败	版本仍明确，数据库和内容完整	在 staging 以同版本、同 locale 的已验证核心替换核心文件
更新中断	.maintenance 遗留、版本混杂、数据库升级未完成	保留现状快照，部署一个明确版本，再评估数据库升级
新主机重建或迁移	原主机退役、运行栈不再受支持	在隔离的新主机恢复内容和数据库，测试后切换流量
数据误删或站点状态回退	已知恢复点晚于最后正确状态	先在 staging 恢复同一时点的数据库与文件备份
疑似入侵	未知管理员、陌生 PHP、异常计划任务或外连	隔离、取证、轮换秘密并从已知可信来源重建

先指定变更负责人、维护窗口、允许的数据丢失范围、健康检查、回滚负责人和停止条件。若无法证明备份可读、staging 数据库与生产隔离、目标版本兼容，立即停止。不要把生产环境当作首次演练场。

2. 建立只读清单和证据

记录主机、PHP、数据库服务器、Web 服务器、WordPress 版本与 locale、站点 URL、表前缀、活动主题、插件、MU 插件、drop-ins、计划任务、对象缓存、媒体存储、反向代理、DNS、TLS 和定时备份。保存 wp-admin、wp-includes、根目录文件和 wp-content 的哈希；日志与清单可能包含私人路径和 IP，只能进入受限证据库。

下面的 WP-CLI 检查只适用于“没有怀疑入侵”的情况，并从可信的 WP-CLI 安装运行。--skip-plugins --skip-themes 不会跳过 MU 插件；若 MU 插件不可信，不要执行 WP-CLI。

set -eu

SITE_ROOT=/srv/www/example
EVIDENCE_DIR=/srv/backups/example/20260901T124200Z-evidence

test -d "$SITE_ROOT/wp-admin"
test -d "$SITE_ROOT/wp-includes"
test -d "$SITE_ROOT/wp-content"
test ! -e "$EVIDENCE_DIR"
install -d -m 0700 "$EVIDENCE_DIR"

wp --path="$SITE_ROOT" core version --skip-plugins --skip-themes
wp --path="$SITE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$SITE_ROOT" plugin list --format=json --skip-plugins --skip-themes > "$EVIDENCE_DIR/plugins.json"
wp --path="$SITE_ROOT" theme list --format=json --skip-plugins --skip-themes > "$EVIDENCE_DIR/themes.json"
find "$SITE_ROOT" -xdev -type f -print0 | sort -z | xargs -0 sha256sum > "$EVIDENCE_DIR/site-files.sha256"

校验失败只说明文件与官方发布不一致，不能单独区分合法定制、损坏和入侵。不要用 --insecure 绕过 TLS；WP-CLI 官方文档明确警告它会让下载暴露于中间人攻击。

3. 制作完整、受保护且可测试的备份

WordPress 官方备份指南要求同时备份数据库和文件。至少保存：数据库、wp-content/uploads、themes、plugins、MU plugins、drop-ins、wp-config.php、.htaccess 或同等服务器规则、robots 文件、自定义 PHP 配置、定时任务、Web/PHP/缓存配置、TLS 与 DNS 清单，以及外部对象存储的版本信息。数据库和配置包含个人数据及秘密，应加密、限制权限、设定保留期，并与生产故障域分离。

以下示例新建一个专用目录，从 wp-config.php 读取数据库连接而不把密码写入命令。先把示例路径改成已批准的绝对路径。若目录已经存在，它会停止；它不会删除生产文件。

set -eu

SITE_ROOT=/srv/www/example
BACKUP_ROOT=/srv/backups/example/20260901T124200Z

test -d "$SITE_ROOT/wp-content"
test ! -e "$BACKUP_ROOT"
install -d -m 0700 "$BACKUP_ROOT/files"

wp --path="$SITE_ROOT" db export "$BACKUP_ROOT/database.sql" --single-transaction --skip-plugins --skip-themes

for item in wp-config.php wp-content .htaccess .user.ini robots.txt; do
  if test -e "$SITE_ROOT/$item"; then
    cp -a -- "$SITE_ROOT/$item" "$BACKUP_ROOT/files/"
  fi
done

find "$BACKUP_ROOT" -type f ! -name SHA256SUMS -exec sha256sum {} + > "$BACKUP_ROOT/SHA256SUMS"
chmod 0600 "$BACKUP_ROOT/database.sql" "$BACKUP_ROOT/SHA256SUMS"

用主机管理员的受限渠道另行复制 Apache、Nginx 或其他入口配置、PHP-FPM、systemd、cron、缓存和证书引用；不要把私钥放进博客仓库或工单。快照不是测试：必须验证校验和，并在隔离数据库上完成一次恢复。

4. 先在干净 staging 完整恢复

staging 必须使用独立域名、独立数据库和最小权限数据库用户，阻止外发邮件、支付、Webhook、搜索引擎抓取和生产队列。不要把生产 wp-config.php 直接复制过去；创建 staging 专用配置，并通过受控秘密存储注入凭据。

在继续前比较数据库名，避免把测试导入生产。下面的复制和导入只指向明确的 staging 路径；确认两条 test 都通过后再运行。

set -eu

PROD_ROOT=/srv/www/example
STAGE_ROOT=/srv/www/example-staging
BACKUP_ROOT=/srv/backups/example/20260901T124200Z

test "$STAGE_ROOT" != "$PROD_ROOT"
test -f "$STAGE_ROOT/wp-config.php"
test "$(wp --path="$STAGE_ROOT" config get DB_NAME --skip-plugins --skip-themes)" != "$(wp --path="$PROD_ROOT" config get DB_NAME --skip-plugins --skip-themes)"

cp -a -- "$BACKUP_ROOT/files/wp-content/." "$STAGE_ROOT/wp-content/"
wp --path="$STAGE_ROOT" db import "$BACKUP_ROOT/database.sql" --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" db check --skip-plugins --skip-themes

恢复后先保持 staging 私有，检查文章、用户、媒体、菜单、widgets、表数量和前缀，再处理 URL。对数据库的任何写操作都要先有新的 staging 快照。

5. 选择最小修复分支

分支	保留内容	何时使用	不应做什么
A：替换核心文件	数据库、wp-config.php、整个 wp-content、服务器规则	核心损坏且版本已知	不删除数据库表或内容目录
B：修复失败更新	A 的全部内容，加上更新前快照	版本混杂或维护模式残留	不盲目继续到 latest
C：干净主机重建	从可信备份选择性恢复	主机迁移、运行栈更换或安全重建	不复制未知系统二进制和秘密
D：从备份恢复	同一恢复点的数据库与文件	数据损坏或错误发布	不把不同时点的数据库与 uploads 拼接

一旦原因和目标分支不一致，停止并重新分类。把多个分支同时执行会扩大变更面，也会破坏回滚证据。

6. 分支 A：以验证过的同版本核心替换核心文件

WP-CLI `core download`可下载指定版本和 locale；不要使用 latest、nightly 或 --insecure。先在站点之外创建干净核心，再用 `core verify-checksums`核对。版本必须来自兼容性评审和 WordPress 官方发布档案。

set -eu

SITE_ROOT=/srv/www/example-staging
CORE_STAGE=/srv/releases/wordpress-core-X.Y.Z-zh_CN
QUARANTINE=/srv/quarantine/example-core-20260901T124200Z
TARGET_VERSION=X.Y.Z
TARGET_LOCALE=zh_CN

test -d "$SITE_ROOT/wp-content"
test -f "$SITE_ROOT/wp-config.php"
test ! -e "$CORE_STAGE"
test ! -e "$QUARANTINE"
install -d -m 0750 "$CORE_STAGE"
install -d -m 0700 "$QUARANTINE"

wp core download --path="$CORE_STAGE" --version="$TARGET_VERSION" --locale="$TARGET_LOCALE" --skip-content
wp core verify-checksums --path="$CORE_STAGE" --version="$TARGET_VERSION" --locale="$TARGET_LOCALE"

mv -- "$SITE_ROOT/wp-admin" "$QUARANTINE/wp-admin"
mv -- "$SITE_ROOT/wp-includes" "$QUARANTINE/wp-includes"
cp -a -- "$CORE_STAGE/wp-admin" "$SITE_ROOT/wp-admin"
cp -a -- "$CORE_STAGE/wp-includes" "$SITE_ROOT/wp-includes"
find "$CORE_STAGE" -maxdepth 1 -type f -print0 |
while IFS= read -r -d '' core_file; do
  core_name=${core_file##*/}
  if test -f "$SITE_ROOT/$core_name"; then
    cp -a -- "$SITE_ROOT/$core_name" "$QUARANTINE/$core_name"
  fi
  cp -a -- "$core_file" "$SITE_ROOT/$core_name"
done

wp --path="$SITE_ROOT" core verify-checksums --include-root --version="$TARGET_VERSION" --locale="$TARGET_LOCALE" --skip-plugins --skip-themes

该 allowlist 只移走并替换 wp-admin、wp-includes 和官方包的根文件；不会删除 wp-content、wp-config.php 或数据库。--include-root 报告额外根文件后，逐一识别并移动到 quarantine，不要用通配符批量删除。完成 staging 测试后，按同一受审步骤部署生产。

7. 分支 B：修复失败更新

先记录实际文件版本、目标版本、.maintenance、PHP 错误日志和更新日志。部署一个明确版本的完整核心后再次校验。只有代码版本一致、数据库备份已验证且官方升级路径要求时，才运行 `wp core update-db`；这是数据库写操作，不是普通健康检查。

set -eu

SITE_ROOT=/srv/www/example-staging

wp --path="$SITE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$SITE_ROOT" maintenance-mode activate --skip-plugins --skip-themes
wp --path="$SITE_ROOT" core update-db --skip-plugins --skip-themes
wp --path="$SITE_ROOT" maintenance-mode deactivate --skip-plugins --skip-themes

如果 WP-CLI 无法启动，不要反复执行。把根目录 .maintenance 精确移动到 quarantine 后测试，而不是删除任意点文件。任何一步报错都保持维护模式，保存日志并回滚。官方升级指南要求升级前完成备份，并明确保留 wp-config.php、wp-content 和自定义服务器规则。

8. 分支 C：在干净主机重建

新主机先安装当前受支持且与站点兼容的 PHP、数据库、Web 服务器和扩展，启用时间同步、日志、备份、监控和 HTTPS。创建专用系统账户、站点目录及最小权限数据库账户，不复用 root 数据库账户，也不在命令、聊天或仓库中粘贴密码。

用指定版本和 locale 下载并校验核心；创建新的 wp-config.php，生成新的 salts，并仅选择性恢复已审核的 uploads、themes、plugins、MU plugins 与 drop-ins。导入数据库前证明目标为空且不是生产数据库。官方迁移指南提醒域名或路径变化会涉及数据库中的 URL；必须使用理解序列化数据的工具，而不是普通 SQL 文本替换。

若这是安全重建，只迁移经过审查的数据和媒体，不搬运未知 PHP、缓存、旧 secrets 或系统配置。上线前撤销旧主机凭据并验证没有仍指向旧端点的队列、cron、Webhook 或对象缓存。

9. 分支 D：从已知良好备份恢复

选择满足恢复点目标的数据库和文件集合，并验证版本、校验和、加密密钥及恢复说明。数据库、uploads 与订单等外部系统必须处于一致时间点。先恢复到 staging；不要先安装空站点并用它生成新表，也不要删除生产所有表来“准备”导入。

切换生产前先进入维护窗口，保存当前故障状态快照，然后按主机批准的方法导入目标数据库并原子切换已验证的文件 release。生产导入是破坏性恢复门：必须由授权人核对目标数据库名、备份时间、当前快照和回滚命令。导入后不要立即清理旧 release 或备份。

10. URL 变更必须理解序列化数据

WordPress 选项和插件数据可能是 PHP 序列化值。普通 sed 或 SQL REPLACE 会破坏长度信息。WP-CLI `search-replace`能够处理序列化数据；先限定表前缀并运行 --dry-run。通常跳过 guid，因为文章 GUID 不是显示 URL。Multisite、域名映射和自定义表需要单独方案。

set -eu

STAGE_ROOT=/srv/www/example-staging
OLD_URL=https://www.example.com
NEW_URL=https://staging.example.net

wp --path="$STAGE_ROOT" search-replace "$OLD_URL" "$NEW_URL" --all-tables-with-prefix --skip-columns=guid --dry-run --skip-plugins --skip-themes

审查 dry-run 的表和变更数，拍摄新的数据库快照，再移除 --dry-run 执行一次。不要使用 --all-tables，除非已证明数据库不与其他应用共享。完成后读取 home、siteurl 和关键插件设置，检查 HTTP 内容是否仍被硬编码。

11. 隔离插件、主题、MU 插件和 drop-ins

先在 staging 复现故障。常规插件可用官方 `wp plugin deactivate`停用；这会写数据库，必须在快照之后执行。逐批恢复并记录触发条件。不要依据“全部更新后看看”来改变证据。

set -eu

STAGE_ROOT=/srv/www/example-staging

wp --path="$STAGE_ROOT" plugin deactivate --all --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" plugin list --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" theme list --skip-plugins --skip-themes

MU plugins 会自动加载，advanced-cache.php、object-cache.php、db.php 等 drop-ins 也不等同于普通插件。先记录哈希，再把单个可疑文件移动到 staging quarantine；不要重命名或删除整个生产 wp-content。主题切换会改变渲染与 widgets，应只在 staging 使用一个已安装、已审核且兼容的主题做诊断。

按官方加固指南和文件权限指南设置专用 owner/group，让 Web 服务仅写业务必需目录。不要递归 chmod 777，也不要让 PHP 进程拥有部署密钥或整棵代码树的写权限。先用 find ... -ls 审计实际 owner、group 和 mode，再按主机模型逐项修正。

12. 固定链接、HTTPS、缓存和服务器规则

先恢复并比较原来的 .htaccess、Nginx/Caddy 路由、反向代理头、PHP-FPM、缓存和安全头。WordPress 的固定链接文档说明 Apache 的 .htaccess 写入取决于权限；Nginx、Caddy 或托管代理需要在服务器层维护等效路由，不能靠重复保存后台设置修复。

set -eu

STAGE_ROOT=/srv/www/example-staging

wp --path="$STAGE_ROOT" option get home --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" option get siteurl --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" rewrite flush --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" rewrite list --skip-plugins --skip-themes

只在确认 URL 与服务器规则后刷新 rewrite。检查首页、文章、分页、feed、REST API、媒体和后台路由；不要在 Nginx/Caddy 上使用 --hard 期待 WP-CLI 修改服务器配置。按 WordPress HTTPS 指南检查证书链、反向代理 HTTPS 识别、home/siteurl、安全 cookie、混合内容和 HTTP 到 HTTPS 跳转。刷新对象缓存、页面缓存和 CDN 时记录范围，避免把旧错误再次注入。

13. 验证、上线和回滚

层面	上线门	回滚触发
文件	核心校验通过；无未解释额外文件；权限符合主机模型	校验变化、未知 PHP 或 owner 异常
数据库	db check 通过；表数、用户、内容和业务记录抽检一致	SQL 错误、序列化损坏或数据时点不一致
应用	登录、发布、媒体、搜索、表单、cron、REST 和邮件沙箱通过	PHP fatal、队列重复、写入失败或外发失控
Web/TLS	关键路由、跳转、证书、缓存头和代理来源正确	跳转环、混合内容、5xx 或私有 staging 暴露
可观测性	错误率、延迟、磁盘、数据库连接和队列有基线	指标持续超阈值或日志出现新错误

set -eu

STAGE_ROOT=/srv/www/example-staging
STAGE_URL=https://staging.example.net

wp --path="$STAGE_ROOT" core verify-checksums --include-root --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" db check --skip-plugins --skip-themes
wp --path="$STAGE_ROOT" cron event list --skip-plugins --skip-themes
curl --fail --silent --show-error --head "$STAGE_URL/"
curl --fail --silent --show-error --head "$STAGE_URL/wp-json/"

以小流量或原子 release 切换上线，保持旧 release、数据库快照、配置和 DNS 回退路径。上线后在约定观察窗内比较基线。触发停止条件时，不继续“修一项看看”：恢复旧 release 与同一时点数据库，恢复服务器规则，清理新缓存，再验证回滚后的健康状态。最后记录原因、命令、版本、哈希、审批、数据差异和后续修复。

14. 当前官方参考

• WordPress：备份
• WordPress：升级
• WordPress：迁移
• WordPress：加固
• WordPress：文件权限
• WordPress：HTTPS
• WordPress：固定链接设置
• WordPress：发布档案
• WP-CLI：`core download`
• WP-CLI：`core verify-checksums`
• WP-CLI：`core update-db`
• WP-CLI：`db export`
• WP-CLI：`db import`
• WP-CLI：`db check`
• WP-CLI：`search-replace`
• WP-CLI：`plugin deactivate`
• WP-CLI：`maintenance-mode`
• WP-CLI：`rewrite flush`

15. 2011 年原文精确存档

下面是完整可见的 source_export 正文。原文文字、链接、空白和标点均未修改；只增加了惰性的外层代码围栏。原始导出和 Git 历史保持不变。

警告：存档中的顺序会先删除全部数据库表和配置，不能作为当前操作指南。请使用上面的维护版手册。

Table of Contents

Toggle

- [wordpress重装](https://blog.lazying.art/en/html/computer_internet/wordpress/390/wordpress%e9%87%8d%e8%a3%85.html/#wordpress%E9%87%8D%E8%A3%85)

# wordpress重装

1、进入phpmyadmin，导出数据库。事先若能用wordPress Database Backup备份数据库也可以。备份的时候，不要忘了/wp-content/uploads文件夹下的东东啊。
 2、删除WordPress已安装数据库里所有table表。
 3、用免费ftp工具或在线文件管理进入WordPress安装目录，删除config.php和.htaccess这两个记录文件或安装痕迹。
 4、重新设置config.php。[可选]（WordPress一般会自动创建这个配置文件）
 5、浏览器输入你WordPress网址，重装WordPress。填写数据库信息、管理员信息。
 6、记住admin密码，进入重装后的WordPress后台，修改admin密码。[可选]
 7、再次进入phpmyadmin，恢复或导入数据库。