WordPress更新前的备份与还原｜让旅宿网站处于可恢复状态

更新 WordPress 前，即使有人说「已取得备份」，也不代表安全。如果只有文件、数据库过旧、保存位置与正式服务器相同，或没有人知道如何还原，发生故障时可能无法恢复。

旅宿网站需要的是以下状态。

将同一时间点的文件与数据库成组保存，知道要在哪里、如何还原，并已决定还原后的确认项目。

本文不限定单一备份方法，而是介绍虚拟主机、备份插件与网站制作公司运营都适用的确认方式。

备份有两个主要部分

1. WordPress 文件

主题
插件
上传的图片与 PDF
wp-config.php
.htaccess 等设置档
WordPress 核心文件

2. 数据库

文章、固定页面、留言
WordPress 设置
使用者信息
菜单与小工具设置
许多插件储存的设置与资料

WordPress 官方数据库备份文件也说明，汇出的数据库不包含主题、插件、上传内容、wp-config.php 等文件。

有时会只保存文件或数据库，但为了能在更新前备份中还原整个 WordPress，原则上应保存两者。

外部服务不包含在 WordPress 中

以下资料可能位于 WordPress 外部。

OTA 预订
外部预订系统的库存与住宿旅客信息
Stripe、Square 等付款资料
Google Analytics、Search Console
外部邮件服务的信箱
DNS 与域名合约
社交媒体与地图信息

即使还原 WordPress，也不一定会让这些资料回到过去。反过来，只让 WordPress 回到过去，可能造成它与外部预订、付款的状态不一致。

将「还原点」成组管理

请为备份附上以下信息。

项目	记录范例
取得日期与时间	2026年8月16日 10:00 JST
目标网站	官方网站的域名
目标文件夹	WordPress 安装位置
数据库	将目标名称记录在安全的管理表中
文件	完成状态与容量
数据库	完成状态与容量
取得原因	插件更新前
保存位置	服务器外的储存位置
验证	读取、校验码与还原测试
负责人	取得者与确认者

如果文件与数据库的时间相差很大，可能出现图片存在却无法在文章显示，或设置与插件版本不相容等不一致的情况。

三种常见的取得方式

虚拟主机的备份

透过管理面板保存与还原文件、数据库。操作较容易理解，但保留期间、还原费用、涵盖对象，以及能否另行保存，会因方案而异。

ロリポップ官方手册也将网站与数据库分开还原。请避免选错还原对象或时间。

WordPress 备份插件

可以透过管理面板设置定期备份与外部保存。不过，网站无法开启的故障也可能让人无法登录 WordPress 管理面板，只靠同一个插件未必能还原。

请确认以下事项。

无法登录 WordPress 时，是否仍可还原
谁负责管理保存位置的认证信息
大型网站的处理是否会中途停止
备份本身是否能透过公开 URL 读取
插件合约结束后，是否仍可取出备份

网站制作或维护公司的备份

不要只确认「包含在维护服务中」，也要确认取得频率、保留期间、还原目标时间、额外费用与合约结束时的交接。旅宿方面也应掌握紧急联络窗口及最近成功的日期与时间。

不要只保存在服务器内

只复制到同一台服务器的另一个文件夹，仍会同时受到服务器故障、合约停止、入侵或容量不足的影响。

至少将一份备份放在正式服务器以外、值得信任的位置。

不同于服务器公司的云端储存服务
限制存取权限的商用储存空间
加密的外部储存媒体
维护公司分离的备份基础设施

WordPress 官方信息安全文件也提出定期将 WordPress 全站与数据库快照保存在可靠位置的做法。

防止备份意外公开

将 SQL、ZIP、tar 等备份放在网站公开文件夹，可能让知道 URL 的人取得文件。备份可能包含个人信息、电子邮件地址、密码哈希、设置与秘密信息。

不放在能从网站直接取得的位置
限制保存位置的分享范围
视需要加密
不将解密密钥与备份放在同一位置
确保能确认下载记录与操作记录
安全删除已不需要的旧备份

请勿将备份 URL、密码或解密密钥贴到 AI 聊天中。

如何确认备份成功

不要只依靠「完成」的电子邮件，也要确认以下事项。

没有因错误而结束
文件容量不是0，也没有异常小
数据库文件确实存在
备份是在紧接更新作业开始前取得
目标域名与文件夹正确
确实能从保存位置读取
若有哈希值或校验码，确认一致

定期备份应每月确认最近成功的日期与时间。容量不足或认证失效，可能导致备份已连续失败数个月。

进行还原测试

最可靠的备份可用性确认方法，是在与正式环境分离的测试环境中还原。

准备测试用域名、文件夹与数据库
阻挡搜索引擎与一般使用者存取
还原文件
还原数据库
安全变更为测试用 URL
登录管理面板
确认首页、文章、图片与菜单
使用不会将预订或询问送往正式环境的设置进行确认
确认个人信息受到保护
记录结果与所需时间

请避免从测试环境寄送邮件给住宿旅客，或操作外部预订库存与正式付款。

如果没有技术负责人，请询问服务器公司或网站制作公司：「能否在不覆写正式环境的情况下，于另一个位置确认还原？」

还原正式环境前，先停下来

还原正式环境是一项重要操作，可能用过去的状态覆写现有资料。请勿急着执行，先判断以下事项。

是否只是公开页面的问题
能否登录管理面板
能否只还原最近变更的插件
是否只还原文件就能修复
是否必须连数据库一起还原
备份后，是否有新的预订、询问或文章
是否会与外部付款或 OTA 状态不一致

还原数据库可能删除备份后新增的信息。还原前，也要紧急保存目前的资料，并记录差异。

还原的基本顺序

实际操作应优先遵循服务器公司的步骤。一般的判断顺序如下。

暂停新的更新、发文与预订受理
记录故障时间与症状
紧急备份目前状态
由两人确认还原对象与还原点
另行记录备份后的预订与询问
还原文件、数据库中必要的范围
清除缓存
确认管理面板与公开页面
确认预订、表单与邮件
安全重新输入差异资料并核对
恢复销售与更新

有时可以只安全还原造成问题的部分，而不是「全部还原」。如果无法判断，请勿执行完整还原，而应联络维护负责人。

还原后的确认表

WordPress

[ ] 首页、客房、价格与交通页面能显示
[ ] 图片与 PDF 能显示
[ ] 菜单与内部链接正常运作
[ ] 可以登录管理面板
[ ] 可以将文章保存为草稿
[ ] 没有 SSL 警告、404 或 PHP 错误

预订与联络

[ ] 预订按钮前往正确的外部页面
[ ] WordPress 内的预订库存与外部一致
[ ] 联络表单正常运作
[ ] 旅宿通知与自动回复可以收到
[ ] 已反映还原期间收到的预订、取消与变更

安全性

[ ] 测试环境没有公开给搜索引擎
[ ] 备份文件没有透过网站公开
[ ] 已停用还原用的临时账号
[ ] 已确认缓存与临时文件
[ ] 已记录还原时间、负责人与结果

依更新频率决定保留期间

如果只持续覆写唯一的最新版，察觉入侵或问题时，可能已没有正常版本可用。

小型旅宿也应区分用途保留备份。

更新前的手动备份
每日自动备份
每周、每月的长期备份
大幅变更设计前保存的版本

所需保留期间，应依文章更新、预订资料的保存位置、维护合约及个人信息方针决定。避免无限期保留不必要的个人信息，也很重要。

请 AI 协助确认的提示词

请确认旅宿在更新 WordPress 前的备份。
先不要执行取得备份、还原、删除或正式环境变更。

只透过只读调查，整理以下事项。
- WordPress 安装位置
- 目标数据库
- 文件与数据库的取得方式
- 不包含在备份内的外部预订、付款、邮件等资料
- 目前保存位置、保留期间与最近成功时间
- 是否有与正式环境分开的保存位置
- 还原方法与所需时间
- 还原可能遗失的新资料
- 不覆写正式环境的还原测试方案

请勿显示秘密信息、顾客信息或备份内容。
遇到不明事项，请勿推测，而应整理成询问服务器公司的问题。

不要一开始就允许 AI 还原正式环境。应先由人核准对象、还原点、差异与确认方法，再继续进行。