WordPress部署在香港CentOS服务器上，数据库与文件备份如何安排恢复演练

先确定备份什么：数据库和文件必须成对管理

WordPress 备份不能只导出数据库，也不能只打包网站目录。数据库保存文章、页面、评论、用户和大部分插件设置；文件目录保存 WordPress 程序、主题、插件、上传图片以及配置文件。恢复时，数据库与文件如果来自不同时间点，可能出现图片记录存在但图片文件缺失、插件配置与插件版本不匹配等问题。

比较稳妥的做法是：按计划备份数据库和完整站点文件，记录同一轮备份的时间与校验值，再将备份副本保存到服务器以外的位置。内容更新频繁的网站可以每天备份，低频更新的网站可按实际发布节奏安排；上线前、升级主题或插件前、批量导入内容前，另做一次手动备份。保留周期可先按“每日备份保留 7 至 14 天、每周备份保留 4 至 8 周”规划，再根据空间与恢复要求调整。

如果网站允许持续写入，怎样确保两份备份对应同一状态？关键在于备份期间协调写入：短暂停止 WordPress 的 PHP 请求和计划任务，再依次导出数据库、打包文件，完成后恢复服务。若无法安排短暂停机，至少要使用支持事务的 InnoDB 表，并采用数据库一致性导出；但文件仍可能在打包时发生变化，严格一致性仍需要短暂冻结写入或使用经过验证的文件系统快照方案。

备份前先核对环境和恢复目标

以下示例适用于常见的 CentOS 环境，假设网站目录为 /var/www/html、数据库名为 wordpress，数据库通过 MySQL 或 MariaDB 管理。实际路径、服务名称和数据库账号需按服务器现状替换。先核对网站根目录、数据库名称、运行服务及磁盘空间：

cat /etc/centos-release
grep -E '^(DB_NAME|DB_USER|DB_HOST)' /var/www/html/wp-config.php
systemctl list-units --type=service | grep -E 'php-fpm|mariadb|mysqld|httpd|nginx'
df -h

wp-config.php 包含数据库连接信息，不要把命令输出、配置文件或备份文件粘贴到公开渠道。若使用多个站点、独立上传目录或非默认安装路径，还要逐一确认对应目录和数据库，避免只备份了其中一部分。

开始前还要想清楚恢复目标：最多能接受丢失多久的数据，以及希望多长时间内恢复网站。这两个目标决定备份频率和保留方式。例如，每天凌晨备份意味着发生故障时，未备份时段的更新可能无法找回；若网站每小时都有订单或内容变更，就需要更短的备份间隔，并确认数据库导出和备份传输能否及时完成。

建议至少准备以下内容：

• 服务器上足够的临时空间。数据库导出文件和压缩包在处理过程中可能同时存在，空间应按网站文件与数据库大小留出余量。
• 可读取的数据库账号，以及具备读取网站文件权限的备份执行账号。
• 服务器之外的备份存储位置。服务器本机上的另一目录不算独立副本，整机故障或误删可能同时影响网站和备份。
• 一次可安排的维护时段，用于一致性备份和后续恢复演练。

怎样让数据库与文件来自同一轮备份

先确认 PHP-FPM 服务名称，不要直接假设每台 CentOS 服务器都使用同一个服务名：

systemctl list-units --type=service | grep php-fpm

假设查到的服务名是 php-fpm，且站点使用该服务处理请求，可以在维护时段停止它，阻止新的 WordPress 请求写入。若网站还有独立的计划任务或队列程序，也要先暂停相应的写入任务。停止服务会使网站暂时无法正常处理动态请求，执行前应确认维护安排；不要在业务高峰期直接操作。

为避免把数据库密码写在命令行参数中，可为 root 用户建立仅允许 root 读取的客户端配置文件。先确认当前数据库客户端支持的配置格式，再编辑文件：

install -m 600 /dev/null /root/.my.cnf

文件内容示例：

[client]
user=backup_user
password=替换为实际密码
host=localhost

数据库账号应仅具备备份所需权限，不宜直接复用网站管理账号或赋予不必要的管理权限。完成配置后，可先测试连接：

mysql --defaults-extra-file=/root/.my.cnf -e 'SELECT 1;'

如果系统没有 mysql 命令，应根据已安装的 MySQL 或 MariaDB 客户端确认对应工具名称，不要盲目安装或替换数据库软件。

下面示例先停止 PHP-FPM，再生成带时间戳的数据库和文件备份，最后恢复服务。数据库名、目录及服务名均需按实际情况修改：

set -euo pipefail

SITE_DIR="/var/www/html"
DB_NAME="wordpress"
BACKUP_ROOT="/srv/backups/wordpress"
STAMP="$(date +%Y%m%d-%H%M%S)"
DEST="${BACKUP_ROOT}/${STAMP}"
PHP_SERVICE="php-fpm"

mkdir -p "$DEST"
chmod 700 "$BACKUP_ROOT" "$DEST"

systemctl stop "$PHP_SERVICE"

restore_service() {
  systemctl start "$PHP_SERVICE"
}
trap restore_service EXIT

mysqldump \
  --defaults-extra-file=/root/.my.cnf \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  "$DB_NAME" | gzip -c > "${DEST}/database.sql.gz"

tar -czf "${DEST}/site-files.tar.gz" -C "$(dirname "$SITE_DIR")" "$(basename "$SITE_DIR")"

(
  cd "$DEST"
  sha256sum database.sql.gz site-files.tar.gz > SHA256SUMS
)

gzip -t "${DEST}/database.sql.gz"
tar -tzf "${DEST}/site-files.tar.gz" >/dev/null
sha256sum -c "${DEST}/SHA256SUMS"

echo "备份完成：${DEST}"

此处的 --single-transaction 主要适用于 InnoDB 表；若数据库中存在非事务型表，或备份期间仍有其他程序写入数据库，它不能单独保证全库处于同一时点。应先确认表引擎，并暂停其他写入来源。若 mysqldump 不支持某个参数，先检查客户端版本和帮助信息，再选择与当前数据库兼容的参数，不要在未确认的情况下删除错误选项后继续把备份当作有效副本。

set -e 可让多数命令失败时停止后续流程；trap 用于在脚本退出时尝试启动 PHP-FPM。但如果服务器断电、进程被强制终止，服务仍可能未恢复，因此备份后要主动检查：

systemctl is-active php-fpm

如果输出不是 active，应先查看服务状态和日志，并恢复网站服务，而不是继续执行清理或覆盖操作：

systemctl status php-fpm --no-pager
journalctl -u php-fpm -n 50 --no-pager

备份包生成后，还要将其复制到服务器之外的受控存储位置。传输前确认目标目录权限和可用空间；传输后再次校验文件大小或校验值。备份里通常含有用户信息、配置和业务数据，传输与存放都应限制访问权限。不要为了节省空间而在唯一一份备份上直接覆盖或删减文件。

备份频率和保留多久，怎样按网站变化调整

备份频率不应只按服务器空间决定，还应看网站数据变化速度和可接受的数据损失窗口。以下是可作为起点的安排：

表中的天数是规划参考，不是通用标准。若每天备份一次，而网站每天新增内容，最坏情况下可能丢失接近一天的更新；将数据库备份改为每小时一次可以缩小这个时间窗口，但会增加存储和运维工作，也不能替代文件备份。是否采用更短间隔，应结合内容写入速度、备份耗时和可接受的数据丢失量判断。

保留周期也要考虑误操作发现时间。只保留最近几份备份，若错误数据连续写入数日，可能找不到错误发生前的版本。一种容易管理的做法是保留近期每日备份，再额外保留若干周备份；在上线、迁移或批量操作前生成的手动备份，可单独标记并设置明确的保留期限。

清理旧备份时，先确认备份目录中有哪些文件、当前脚本是否正在写入、异地副本是否已经完成校验。不要对整块备份盘执行不加限制的删除命令。若使用按日期目录保存，建议先列出将被清理的目录并人工核对，再仅对指定目录执行清理。任何自动清理策略都应先在测试目录验证匹配范围，避免路径变量为空或写错后影响网站文件。

恢复演练为什么不能只看“备份文件存在”

备份文件生成成功，不等于网站可以恢复。压缩包可能损坏，数据库导出可能缺表，恢复后也可能因 PHP 扩展、文件权限、数据库字符集或配置不匹配而无法启动。恢复演练的目标，是证明备份能在独立环境中还原，并确认页面、媒体文件和后台操作符合预期。

优先在隔离的测试环境演练，不要直接覆盖线上站点。测试环境应使用独立目录和独立数据库，避免误连线上数据库，也不要将测试站点公开给无关访问者。演练前记录备份时间、文件大小、校验结果、恢复开始时间和恢复完成时间；这些记录能帮助判断备份是否满足预期恢复速度。

用副本进行恢复验证

以下操作会写入测试数据库和测试目录。请先确认 test_wordpress 是专门用于演练的空数据库，/var/www/restore-test 是独立测试目录；不要把示例中的名称替换成线上数据库后直接执行。恢复前确认备份校验通过：

cd /srv/backups/wordpress/替换为备份时间目录
sha256sum -c SHA256SUMS

创建测试数据库的命令涉及数据库变更，应使用仅能操作演练数据库的账号，并在执行前确认库名。若测试数据库已存在且内有数据，不要直接删除或覆盖，应另建新的测试库：

mysql --defaults-extra-file=/root/.my.cnf -e \
  "CREATE DATABASE test_wordpress DEFAULT CHARACTER SET utf8mb4;"

导入前先检查导出文件是否能读取，再导入到测试库：

gzip -t database.sql.gz
gzip -dc database.sql.gz | mysql \
  --defaults-extra-file=/root/.my.cnf \
  test_wordpress

还原文件到独立目录，而非线上目录：

mkdir -p /var/www/restore-test
tar -xzf site-files.tar.gz -C /var/www/restore-test

如果备份包内目录结构为 /var/www/html，解包后通常会得到 /var/www/restore-test/html。先用 find 确认实际路径，再检查 wp-config.php 是否仍指向线上数据库。演练前应修改测试副本中的数据库连接配置，确保它只连接 test_wordpress。不要在备份副本里改完配置后，又误将其覆盖回线上目录。

随后通过受控的测试站点配置访问页面。检查首页、文章页、后台登录、媒体图片、主题样式及关键插件页面；若站点有表单或其他写入功能，只在测试环境验证。若使用 WordPress 命令行工具，可以在测试目录中查询站点信息，但需先确认工具已安装且命令运行账号有适当权限：

wp --path=/var/www/restore-test/html core is-installed

演练成功至少应满足：数据库可连接，关键内容可读取，抽查的图片文件存在，页面没有明显的程序错误，测试站点不会写入线上数据库。再记录从选择备份到完成检查所需的时间，并与团队预期的恢复时限比较。

恢复失败时先定位，再决定是否回滚

若校验失败，说明文件可能已损坏或传输不完整。不要尝试用这份副本覆盖线上数据，应重新从另一份经过校验的备份复制，并核对两端文件大小和校验值。

若数据库导入报错，先区分是认证失败、数据库不存在、权限不足，还是导出文件与当前数据库版本不兼容。查看错误信息后，在测试库中排查；不要通过删除线上数据库或降低权限来“快速修复”。若恢复出的页面缺少图片，检查打包路径是否覆盖实际上传目录，以及数据库记录的路径与文件目录是否一致。

如果恢复后 WordPress 报数据库连接错误，先检查测试副本中的数据库名称、用户、主机和密码，再确认数据库账号能否连接测试库。若页面出现文件权限错误，先比对线上原有的目录属主、权限和 SELinux 状态，不要对整个网站递归开放写权限。权限调整会影响文件访问范围；操作前记录原属主与权限，并只在确认具体目录后修正。线上回滚时则保持原站文件和数据库不动，撤销测试站点配置即可。

真正需要恢复线上站点时，先安排维护窗口并再备份当前数据库与文件，哪怕当前状态有问题，也能保留回滚入口。确认待恢复备份的时间点和校验值后，暂停写入，再按既定恢复步骤分别还原数据库与文件；恢复前必须确认目标库名和站点路径，避免把旧数据导入错误站点。完成后检查首页、后台、媒体文件、关键功能和日志。若恢复结果不符合预期，停止对故障现场继续覆盖，改用恢复前保存的当前状态副本回滚，并重新在隔离环境定位问题。

条件变化时，备份方案也要跟着改

网站迁移、升级 PHP 或数据库、替换主题和插件后，旧备份不一定能直接用于新环境。重大变更前应做独立备份，并在测试环境确认其可读；变更完成后再生成一份新备份，避免长期只保留变更前版本。若站点目录不止一个、数据库分散在多个实例，或上传文件存放在独立挂载盘，备份脚本也必须覆盖这些实际数据源。

每次恢复演练后，记录发现的问题并调整流程，例如补入漏掉的上传目录、缩短数据库备份间隔，或修改保留周期。与其只问“今天有没有生成备份”，不如定期验证另一台可用环境能否读出数据库、还原文件并正确展示页面：下一次计划的恢复演练，准备什么时候进行？