更新 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 还原正式环境。应先由人核准对象、还原点、差异与确认方法，再继续进行。
备份管理表
| 日期与时间 | 原因 | 文件 | DB | 分开保存 | 验证 | 还原测试 | 负责人 |
|---|---|---|---|---|---|---|---|
| 更新前 |
请勿直接在表中写入密码或加密密钥，而应使用安全的密码管理方式。
总结
- 将文件与数据库成组管理为同一还原点
- 分别确认外部预订、付款与邮件
- 至少将一份备份保存在正式服务器外
- 不只依靠完成通知，也要确认容量、时间、对象与读取
- 在与正式环境分离的位置进行还原测试
- 还原正式环境前，另存备份后的预订与询问
- 还原后，不只确认显示，也要确认预订、表单与邮件
请搭配在虚拟主机上安全更新 WordPress 的方法，将备份、更新、确认与还原整理为同一份操作手册。
参考资料
※备份范围、保存期间、还原费用与操作画面，会因服务与合约方案而异。请务必确认服务商的最新手册。
