同一服务器网站：改动前怎样保存原始状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /765bde088335.html
📄
同一服务器网站：改动前怎样保存原始状态
改动同一服务器上的网站之前，保存原始状态的核心是：把“可回滚的文件、可还原的数据库、可对照的线上表现”三样东西同时固定下来，并记录保存时间与版本。只复制文件不导出数据库，或只截图页面不留配置，都不算完整备份。判断标准很简单——如果改动失败，你能否在不依赖记忆的情况下，把站点恢复到改动前那一刻的状态。
从“能回滚”倒推：必须保存哪四类资料
不要按“我有什么工具”来准备，而按“恢复时需要什么”倒推。一次可用的原始状态保存，至少覆盖以下四类：
- 文件层：网站根目录、主题、插件或模块、上传的静态资源，以及服务器上的配置文件（如 Web 服务器配置、重写规则）。
- 数据层：数据库完整导出，包含表结构、数据、字符集与排序规则信息。内容型站点尤其不能只备份文件。
- 配置与凭据：环境变量、密钥文件、定时任务、CDN 或缓存规则、DNS 记录当前值。这些改动后往往最难凭记忆复原。
- 线上表现基线：改动前的关键页面 HTML 源码、HTTP 响应头、状态码、跳转链路。这是事后判断“是否被改坏”的对照物。
如果服务器上跑着多个站点，要明确本次保存的范围是整台服务器还是单个站点目录。范围不同，回滚的粒度和风险差别很大。
两种保存方案：快照与手动导出怎么选
同一服务器上常见的做法有两类，适用条件不同，不能互相替代。
方案一：整机或磁盘快照。由主机商或虚拟化层提供，保存的是某一时刻的整盘状态。优点是恢复快、覆盖全，包含系统层改动；缺点是粒度粗、通常需要停机或重启、占用额外存储，且快照本身可能不包含数据库写入的实时一致性。适用条件：即将做系统级、Web 服务器级或大版本升级，且能接受短暂停服。
方案二：站点级手动导出。分别打包网站目录、导出数据库、另存配置文件。优点是粒度细、可单独恢复某个站点、便于异地存放；缺点是步骤多、容易漏项，恢复耗时更长。适用条件：只改主题、插件、模板或内容，不触碰系统层。
判断依据可以归结为三点：改动是否触及操作系统或 Web 服务器；能否接受停机；恢复时是整站还原还是只回退某一部分。触及系统层优先快照，纯应用层改动用站点级导出即可，两者都做则更稳妥。
执行清单：改动前按顺序完成
- 记录当前时间与将要改动的具体内容，写进一个文本文件，和备份放在一起。
- 停止写入或进入维护模式，避免备份过程中数据库仍在变化。
- 导出数据库，确认导出文件大小合理、结尾完整，而不是中途截断。
- 打包网站目录，排除缓存和日志等可再生成的内容，但保留配置与上传资源。
- 单独复制 Web 服务器配置、重写规则和环境变量文件。
- 抓取关键页面的 HTML 源码与响应头，存为基线文件。
- 把以上内容复制到服务器之外的存储位置，不要只留在同一块磁盘上。
- 记录恢复步骤：用哪条命令、哪个文件、恢复到哪个路径。
第 7 步常被跳过。备份与源站在同一块磁盘上，磁盘故障时两者一起丢失，等于没有备份。
验收：怎样确认原始状态真的可还原
保存完成不等于可恢复。至少做一次验证：
- 数据库导出文件能否在测试库中完整导入，表和行数是否与导出前一致。
- 压缩包能否正常解压，目录结构是否与线上一致。
- 基线 HTML 与当前线上页面是否一致，若不一致说明抓取时机或范围有问题。
- 恢复步骤是否由他人按文档执行过一次，而不是只有本人看得懂。
验收的判断结果是二元的：能完整还原到基线状态，才算保存成功；任何一项缺失，都应视为原始状态未保存完整，先补齐再动手改动。
容易忽略的边界
保存原始状态时，有几处限制需要提前知道。robots.txt 的抓取限制不等于可靠的索引移除，它管的是抓取，不是删除已收录页面；如果改动涉及屏蔽规则，别把“加了限制”当成“已从搜索结果移除”。站点地图不保证收录，改动前后提交它只影响发现效率，不影响是否被索引。HTTPS 不保证安全无漏洞或排名，证书配置属于原始状态的一部分，应一并记录当前证书与跳转规则。不同搜索引擎对同一规则的响应并不一致，涉及索引或抓取策略的改动，需要分别核查各家的实际表现，而不是假定一处生效处处生效。
下一步：在真正改动前，先按上面的清单做一次完整保存，并实际执行一次恢复演练。只有演练通过，再开始修改同一服务器上的网站。
