服务商说网站有备份，怎样确认出问题后真的能恢复？

先问能恢复什么，再问有没有备份

验收网站备份，不能只看一张“任务成功”的截图。要确认备份包含哪些内容、对应哪个时间点、保存在哪里、谁能发起恢复，以及是否做过实际恢复检查。一个压缩包能下载，不代表换个环境就能恢复出可用的网站。

假设官网周一新增了产品，周二收到询盘，周三发生故障。服务商说可以恢复到周日，接下来就要问：新增产品会不会丢，询盘是否单独保存，恢复后谁来补回差异？业务上的损失范围，藏在备份时间和数据边界里。

让服务商把备份对象逐项写明

例如 WordPress 官方备份文档区分数据库和文件；只备份数据库不能替代文件备份。托管建站平台可能采用不同机制，因此这里的表是核对问题，不是让所有系统照搬同一种备份操作。

用一个隔离副本验证，不要直接覆盖正式站

请负责维护的人在与生产隔离、限制访问的环境中恢复一个副本。提前确认演练不会向真实客户发邮件、写回正式询盘或触发付款等业务动作。备份可能包含客户资料，不能为了方便演示把副本站点公开给所有人。

恢复后至少抽查一篇文章、一件产品、一张图片和一个附件；再按备份范围检查必要的业务记录。确认内容对应的时间点，记录缺少的项目和修复步骤。不同网站还有自己的重点，例如多语言内容或下载资料，应当列入抽查范围。

我们在介绍 NeoGress 发布流程时，会展示上线状态和最近发布记录。需要把发布记录与备份范围分开确认。具体保存范围、恢复方式与责任，需要另外核实，不能从“发布成功”推导出“任何内容都能找回”。

让演练回答：会丢多少数据，要多久恢复

先由业务负责人写出两个可接受范围：最多能损失多长时间内的新数据，以及发生故障后最多能中断多久。它们常被称作RPO与RTO，可对照AWS对恢复目标的说明理解。不要先照抄服务商的数字，再发现公司业务承受不了。范围应覆盖完整业务恢复，而不只是服务器启动。

失败示例：网站能打开，但图片全丢了

假设演练后首页文字正常，产品图片却无法加载，原因是只恢复了数据库，没有恢复上传文件。这次结论应为“未通过”，不能因为首页返回正常就结束验收。修复文件恢复步骤后，再检查图片、附件与它们在页面中的关联。

另一个假设：双方约定最多损失一天内的数据，但实际只能恢复三天前的询盘。即使页面完整，也没有达到原定的数据目标。要么补足备份方案，要么由业务负责人重新评估能否接受；不能由执行人员擅自把目标改成实测结果。

如果备份演练是为了网站改版，还要单独检查旧网址到新网址的映射与跳转。恢复成功不自动证明旧链接已经处理妥当。