RSP 升级翻车实录：版本号显示 PL20，服务却起不来

给 SAP Business One 的 RSP（Remote Support Platform）做版本升级，PL18 → PL20。升级器跑完，版本号乖乖显示 PL20——然后服务起不来了。反复重启服务、停服后重跑安装器尝试更新 schema，都救不回来。

恢复路径：数据库在，一切都在

RSP 的所有配置、备份历史、连接信息都在它的 MSSQL 数据库里。只要库在，软件本体随便折腾：

恢复路径全图——右侧虚线框是升级成功之后差点埋雷的部分

1. 卸载 RSP。关键的一步在卸载器里：它会问要不要删除数据库——选保留。这一下点错，恢复难度直接翻倍；
2. SSMS 恢复数据库备份（.bak）：Options 里勾上 Overwrite the existing database (WITH REPLACE) 和 Close existing connections to destination database，否则恢复会被活连接卡住；
3. 重装 PL20，以管理员运行 setup，填入数据库服务器信息——安装器会识别出已存在的旧版本库，主动提示 Upgrade；
4. 接受升级，安装器完成 schema 迁移——服务正常启动，所有历史记录和配置原样回来。

我们同时把 PL18 的旧安装包找了出来作为 Plan B：如果重装 PL20 依然失败，就恢复数据库后装回 PL18，整体回退。最终没用上，但它的存在让整个恢复过程心里有底。

升级成功 ≠ 收工：两个静默陷阱

服务起来之后按 checklist 复查，抓到两个升级过程悄悄改掉的配置：

1. 数据库备份开关被重置为 Off——第二天凌晨的定时备份没有生成。如果没复查，这就是又一次静默失败的开局；
2. SMTP 告警配置被清空——需要重跑初始化向导重新填。告警通道无声消失，和上次备份事故里「邮件告警没配通」是同一种病。

对照升级前的配置快照截图逐项恢复，才算真正收工。

教训

1. 升级前三件套：数据库 .bak 备份、旧版本安装包留档、配置快照截图——这三样让”翻车”从灾难降级成流程；
2. 卸载器问「是否删除数据库」的那一秒，是整个恢复流程的生死线。慢一点，读清楚再点；
3. 升级后 checklist 不能只看版本号和服务状态：备份任务开关、告警通道、计划任务——凡是「应该没变」的配置，都要亲眼确认一遍。升级器改掉什么是不会通知你的。