一个常见场景：站点从旧服务器迁到新机器，文件搬过去了，数据库导入了，页面能正常打开，事情看起来就结束了。过一段时间安全检查才发现，之前配好的防注入规则、目录访问限制、上传目录禁止执行脚本的设置全都不在，新的环境用的是默认配置。功能没问题，安全配置却丢了一路。
原因不难理解：业务功能有测试会暴露问题，安全配置丢了却没人察觉，因为它不影响页面打开。迁移过程里被漏掉的往往是这些不显眼的东西——webserver 的配置文件、定时任务、文件的属主和权限、防火墙规则、证书与密钥。所以迁移要有清单，不能靠记忆。
把现有环境按层列一遍。系统层包括账号、密钥、提权授权、计划任务、开机自启的服务、内核参数和连接数限制。服务层包括 webserver 的虚拟主机与全局配置、数据库的账号与授权、缓存和消息队列的参数。应用层包括代码、依赖版本、环境变量、上传目录、日志目录。外围还有解析记录、证书、安全组与防火墙策略、备份任务。
这些东西里，配置文件与目录权限最容易在搬迁时被改掉。拷贝时如果用统一的属主和权限覆盖，原本目录的写权限、脚本的执行限制就都没了。建议迁移前把每个关键目录的权限记录下来，之后逐项比对，而不是搬完就算完。
备份不等于复制一份文件放着。首先要有版本，改了什么、什么时候改的要能查；其次要能快速恢复，恢复流程得实际演练过，而不是纸上写着一句还原即可；再者备份本身要安全，里面往往含数据库口令、证书私钥、密钥文件，落到可公开读取的目录就等于把整套凭据泄出去。
存储位置尽量和业务机分开，本地留一份用于快速回滚，异地留一份防止整机故障。备份介质要限制访问权限并加密，传输过程也别用明文通道。保留周期按变更频率来定，配置变更频繁的阶段多留几个版本。
迁移完成后不该只看首页能不能打开。按清单逐项核对更有意义：把新旧环境的 webserver 配置做对比，找出缺失的访问限制规则；确认目录权限与原来一致，上传目录依然不可执行；检查证书是否正确部署且没有用旧环境的测试证书；验证防护规则是否生效；确认定时任务和日志采集正常运行。
更稳的做法是把配置纳入版本管理，配合自动化部署工具执行，新环境按同一套模板生成，人只需要确认变量。这样配置漂移会被及时发现，也不至于出现某台机器和别的机器不一样、却没人在意的情况。
回过头看，配置丢失的原因往往不是粗心，而是缺少一条固定路径。文件可以通过压缩包整体搬迁，数据库可以导出导入，这两件事都有现成的工具和方法，做起来顺手；而安全配置散落在多个位置，一半在服务端的配置文件里，一半在云平台的控制台上，还有一部分是文件属性，没有统一的导出方式，只能靠人去记。哪一步依赖记忆，哪一步就容易漏。
解决办法是把能脚本化的部分尽量脚本化。目录权限、防火墙规则、定时任务这些都可以写成脚本，迁移时在新机器上跑一遍，比手动配置可靠得多；云平台上的安全组、证书、解析记录，整理成一份清单逐项确认。剩下确实无法自动化的部分，也至少要有明确的负责人和确认动作。
配置备份和核对不该只在迁移时做。每次上线、每次改动防护策略、每次调整权限之后，都顺手更新一次备份并记录变更内容。定期做一次恢复演练，确认备份真的能用。安全配置的价值平时看不出来，只有在被绕过或者出故障时才能体现，而那时候最需要的就是一份准确、可用的备份。
售后客服
企业微信
