第 16 章 · 升级与回退
适用对象：交付工程师、备份管理员 · 阅读约 14 分钟 · 对应产品界面版本 v1.2.0
升级要动的是两个对象：管理平台和被保护主机上的 Agent。两者有先后顺序，也有各自的回退路径。升级本身通常不难，难的是升级前有没有留下一份能回得去的数据副本，以及升级后有没有真的验证过「旧还原点还能恢复」。
读完这一章你会做：
- 判断当前版本能不能直接升到 v1.2.0，需要准备哪些材料
- 按「检查 → 备份 → 升级 → 验证 → 失败回退」的顺序完成一次管理平台升级
- 分批升级 Agent，并在每批之间用受控备份和恢复确认这一批没问题
- 判断什么时候该触发回退，以及超过回退窗口后为什么不能简单换回旧软件包
升级的对象与顺序
| 对象 | 说明 | 顺序 |
|---|---|---|
| 管理平台 | 主节点先升，子节点后升。升级期间子节点服务停止或重启属正常现象 | 1 |
| 数据获取器 / 存储库 | 随平台升级，逐节点滚动 | 2 |
| Agent | 平台用升级包升级后，Agent 需要同步升级后再使用 | 3 |
核查环境的产品版本为 SupDRC v1.2.0，管理镜像包含 supdrc:1.0 与 supmirror-backupserver:2.0。产品版本号、镜像标签、Agent 版本是三套编号，规划升级时要分别核对，不要因为标签数字不一样就判断不兼容，也不要因为数字一样就判断兼容。
升级路径
下表是行业通用结论，不是 SupDRC 的正式兼容矩阵。规划升级时以产品侧提供的矩阵为准。
| 路径类型 | 示例 | 通用结论 | 说明 |
|---|---|---|---|
| 小版本就地升级 | v1.2.0 → v1.2.x | 通常支持，待矩阵确认 | 保留配置与还原点 |
| 跨小版本升级 | v1.1.x → v1.2.0 | 通常支持，需先核对兼容矩阵 | 升级前必须备份 |
| 跨大版本升级 | v1.x → v2.x | 待确认 | 可能要求先升到中间版本 |
| 离线包升级 | 上传升级包后本地升级 | 通常支持，待确认 | 适用于无外网环境 |
| 重新部署 | 重装平台后重新接入 | 不保留平台数据 | 需先备份配置与元数据 |
| 组件单独升级 | 仅升级 Agent | 需平台版本兼容 | 平台先行 |
开始之前
升级前的检查清单一项不通过就不进入升级窗口。
| 序号 | 检查项 | 判定标准 |
|---|---|---|
| 1 | 变更已审批 | 变更单号可查，审批人与执行人不是同一人 |
| 2 | 版本兼容与升级路径已确认 | 来源版本与目标版本在兼容矩阵内，升级路径唯一且明确 |
| 3 | 升级包已校验 | 校验值与官方值一致，签名校验通过 |
| 4 | 备份任务已安排 | 窗口内无计划备份与升级冲突，或已临时暂停并记录 |
| 5 | 配置、数据库、元数据及密钥已有可恢复副本 | 备份文件已生成、校验通过，并存放在被升级主机之外 |
| 6 | 空间与依赖满足要求 | 系统盘与数据盘剩余空间 ≥ 升级包体积 5 倍，依赖组件版本符合要求 |
| 7 | 业务窗口 | 与业务方书面确认维护窗口，并已通知相关方 |
| 8 | 停止条件已明确 | 超时、版本异常、服务不可用等停止条件及触发后的动作已写明 |
| 9 | 人员和回退方案齐备 | 值班人员到位，回退步骤、回退窗口与决策人已书面确认 |
| 10 | 基线已留存 | 升级前的版本、配置、任务与还原点基线截图已归档 |
升级前要保护的是管理平台自身的数据库、配置、元数据、授权资料和恢复所需密钥，不是被保护主机的业务数据。副本必须另存到独立位置，并记录备份时间、版本、校验值、负责人和恢复依赖。在拿到产品侧正式的备份方法之前，不要用「复制运行中的数据库目录」代替一致性备份。
升级管理平台
五个阶段
| 阶段 | 操作 | 入口或命令 | 预期输出 | 失败判据 |
|---|---|---|---|---|
| 1 升级前检查 | 核对版本、兼容路径、空间、依赖、许可与窗口 | 关于页面；df -h；许可页面 | 全部检查项符合 | 任一项不符合则暂停 |
| 2 备份 | 备份数据库、配置、元数据与密钥并另存 | 随产品提供的备份入口/命令 | 生成可恢复副本与校验值 | 无法验证可恢复性则暂停 |
| 3 升级 | 上传升级包 → 校验 → 升级主节点 → 升级子节点 | 系统升级页面 | 版本号更新、服务自动恢复 | 超窗口未恢复，或版本不符 |
| 4 验证 | 核对版本、许可、资源、还原点；执行备份与恢复回归 | 关于页面、任务列表与恢复向导 | 回归项全部通过 | 关键项失败即触发停止条件 |
| 5 失败回退 | 按批准方案回退软件包并还原升级前数据副本 | 见本章「回退」一节 | 服务恢复、旧还原点可检索 | 回退后仍不可用则升级为事件 |
升级包需要先上传到平台再核对 MD5，核对无误后才执行。先升级主节点，再升级子节点。
升级期间怎么观察
# 查看服务端进程
ps aux | grep server
# 查看已安装包的版本（包名关键字待产品侧确认）
rpm -qa | grep <包名关键字>
升级完成后的版本号看系统升级页面显示的版本。安装包版本只能说明你手里的包是哪一个，不能说明平台已经升到了那个版本。
什么算失败
满足下列任一条即停止扩大范围，保留证据，由变更负责人决定是修复还是执行已批准的回退：
- 超过批准窗口仍未恢复服务，或关键服务无法启动
- 组件版本不符合目标基线，且重试无法修正
- 配置、元数据或存量还原点无法检索
- 代表性备份或恢复回归失败
- 出现不可接受的业务影响，或出现数据一致性风险与安全问题
升级 Agent
自动升级与手动升级
主机保护组 → 发现计划里有「自动升级已发现计算机上的 SupDRC Agent」。同一分节里还有发现时间、分发服务器、自动安装、CBT 和自动重启。
勾选了「自动升级」不等于同时授权了自动安装和自动重启。启用任何升级自动化之前，先确认受保护计算机是否允许被重启。
| 项目 | 自动升级 | 手动升级 |
|---|---|---|
| 入口 | 主机保护组 → 发现计划 → 自动升级选项 | 客户端列表勾选主机后点【升级】，或下载安装包本地安装 |
| 适用规模 | 大批量、同构环境 | 少量、异构或问题主机 |
| 前置条件 | 分发服务器可达、无运行任务、允许重启 | 管理员权限、可停机 |
| 风险 | 影响面大，失败会批量扩散 | 耗时，但可逐台控制 |
执行顺序
- 确认管理平台已升级完成且运行正常，记录管理平台版本号。
- 选取同版本、同操作系统的少量样本主机做试点。
- 停止样本主机上的运行任务，避免升级与备份互相干扰。
- 执行升级：在线升级，或用本地安装包覆盖安装。
- 检查 Agent 服务状态与进程，确认服务已启动；在平台中确认主机状态为在线。
- 核对 Agent 版本号与管理平台登记的版本一致。
- 执行一次受控备份与文件级恢复，确认功能正常后再放开下一批。
| 检查项 | 方法 | 预期输出 | 异常处置 |
|---|---|---|---|
| Agent 服务状态 | Windows 服务管理器；Linux ps aux | grep agent | 服务／进程均在运行 | 手动启动并收集日志 |
| Agent 版本 | 平台客户端列表的版本列 / 本地包版本 | 与目标版本一致 | 重装或重新升级 |
| 在线状态 | 平台主机列表 | 在线／已注册 | 检查网络与端口，见附录 B |
| 功能验证 | 执行受控备份 + 抽检恢复 | 任务成功、可恢复 | 暂停批次并处置 |
重复安装插件时会先自动删除旧插件，正在运行的备份任务会因此失败。升级前必须确认这台主机上没有正在运行的备份任务。
Windows 与 Linux 的差异
| 项目 | Windows | Linux |
|---|---|---|
| 升级包形式 | 安装程序（.exe / .msi） | 压缩包（.tar.gz） |
| 执行身份 | 管理员 | root |
| 安装／升级方式 | 运行安装程序覆盖安装 | 解压后运行安装脚本 ./agent_install |
| 卸载方式 | 控制面板 →「程序和功能」 | 进入安装目录运行 ./agent_uninstall |
| 服务检查 | 服务管理器 / services.msc | systemctl 或 ps aux |
| 日志位置 | 安装目录下的 log 子目录 | 安装目录下，或 /var/log 下 |
| 重启要求 | 驱动／服务更新后可能需重启 | 内核模块更新后可能需重启 |
| 应用一致性 | 常用 VSS | 常用前置／后置脚本 |
| 在线升级 | 提供在线升级入口，未实测 | 提供在线升级入口，未实测 |
重启要求
| 组件 | 是否需要重启 | 说明 |
|---|---|---|
| 管理平台 | 需要重启服务，可能需要重启主机 | 数据库迁移后通常需重启 |
| 存储 / 代理节点 | 服务重启，通常不需重启主机 | 滚动升级，逐个恢复 |
| Windows Agent | 驱动／服务更新后可能需重启 | VSS 等组件更新时更常见 |
| Linux Agent | 内核模块更新后需重启或重载 | 未重载时部分特性可能不生效 |
升级主节点时会重启子节点上的服务，页面报出「子节点上的服务停止运行或重启」属于正常现象，不要据此判断升级失败。
批量升级
先做同版本、同系统的小样本验证，再按业务分组和窗口逐批执行。每批登记版本、在线状态、是否重启、耗时、备份与恢复验证结果。出现重复失败或明显资源争用就暂停下一批。
升级失败怎么办
先保留安装日志、任务日志、错误时间和前后版本，再核对包完整性、兼容路径、磁盘空间、权限和依赖。
失败后重复覆盖安装或删除不确定用途的目录，会把「一个可定位的故障」变成「一个无法定位的故障」。暂停这一批及后续批次，在支持人员指导下处理；达到回退条件就执行事先验证过的回退方案，并重新验证存量还原点。
回退
回退是升级失败后的受控动作：先确认触发条件，再执行已批准的步骤，并且必须在时间窗口内完成。
触发条件
满足任一即可触发：
- 超过批准窗口仍未恢复服务，或关键服务无法启动
- 组件版本与目标基线不符，且重试无法修正
- 配置、元数据或存量还原点无法检索
- 代表性备份／恢复回归失败，或出现不可接受的业务影响
- 出现数据一致性风险或安全问题
管理平台回退步骤
- 确认回退触发条件已满足，并取得变更负责人批准。
- 停止全部备份／恢复作业，停止管理平台服务。
- 保留当前版本的日志、配置与数据库快照，作为问题取证材料。
- 卸载或替换为升级前的软件包版本。
- 还原升级前的数据库、配置与元数据，必须是同一时间点的一致性副本。
- 启动服务，核对版本号、许可、资源与还原点检索。
- 执行代表性备份与恢复回归，确认业务恢复正常后关闭变更。
Agent 回退步骤
- 确认这台主机上的备份／恢复作业已停止，记录当前 Agent 版本。
- 在平台侧保留该主机的配置与还原点信息，避免卸载后配置丢失。
- 卸载当前 Agent：Windows 走控制面板，Linux 运行安装目录下的卸载脚本。
- 安装升级前的 Agent 安装包。
- 按安装向导填写管理平台地址与端口，完成注册接入。
- 核对 Agent 版本号、服务状态与在线状态，执行一次受控备份验证。
- 如果 Agent 回退后与管理平台版本不匹配，需评估是否要同时回退管理平台。
Agent 回退宜与「最后一批 Agent 升级完成」同批次执行，尽量落在管理平台的回退窗口之内。
24 小时窗口
| 时间 | 可用的回退方式 |
|---|---|
| 升级完成后 24 小时内 | 若保留了升级前的一致性数据副本，且未产生不可逆的新增还原点，可原样回退到旧版本 |
| 超过 24 小时 | 新版本可能已产生新的还原点或元数据变更，原样替换软件包会造成数据不可读。应改为依赖数据库／元数据还原方案，把平台数据恢复到升级前副本 |
这个窗口不是产品实测出来的参数，而是行业通用建议。正式交付时应向产品侧索取回退窗口的正式定义。
存量还原点还能不能用
升级通常向前兼容，反向不成立。
| 场景 | 结论 | 说明 |
|---|---|---|
| 升级后读取旧还原点 | 通常兼容 | 需抽样实测验证 |
| 升级后用旧还原点恢复 | 通常兼容 | 抽取文件恢复并比对 |
| 回退后读取新版本产生的还原点 | 可能不兼容 | 这是 24 小时窗口的根本原因 |
| 回退后继续增量备份 | 可能需要重新建立全备 | 备份链可能断裂 |
| 备份链 | 升级不应破坏既有备份链 | 升级后先验证链的完整性 |
升级完成后到回退窗口结束之前，应避免产生大量「只有新版本能读」的关键还原点。一旦这些还原点承载了业务，回退就不再是一个可选项。
升级完成后立刻做三件事：抽取升级前的代表性还原点执行一次文件级恢复并比对内容、权限与时间属性；核对备份链是否仍可检索；确认调度任务能按原策略触发。任一项失败就触发回退评估。
升级后验收清单
| 序号 | 检查项 | 判定标准 |
|---|---|---|
| 1 | 版本与组件状态 | 管理平台、Agent、数据获取器与存储库版本均为目标版本且互相一致 |
| 2 | 登录与权限 | 登录成功，各角色权限与升级前一致，无越权或权限丢失 |
| 3 | 配置 | 逐项比对升级前后的配置导出，差异项均有说明与批准 |
| 4 | 许可 | 授权类别、功能模块、有效期与合同一致，无未授权告警 |
| 5 | 资源 | 全部被保护资源在线，代理状态正常，无离线主机 |
| 6 | 策略与还原点 | 全部策略可打开，历史还原点可按时间检索且可读 |
| 7 | 备份与恢复 | 代表性主机完成一次增量备份与一次文件级恢复，均成功 |
| 8 | 计划任务 | 调度在升级后按预期触发，无遗漏或重复触发 |
| 9 | 日志与通知 | 操作日志、登录日志正常记录，告警通知可送达 |
| 10 | 资源占用 | CPU、内存、磁盘 IO 与升级前基线相比无持续异常升高 |
源文档的升级回归表是空表：核查工作只读取了现有界面与历史任务，没有实际执行过一次升级。上表的判定标准可以直接用，但「实际结果」一列必须由现场按真实升级结果填写。
耗时与窗口规划
| 升级对象 | 耗时区间 | 是否含重启 | 说明 |
|---|---|---|---|
| 单台管理平台 | 约 20–60 分钟 | 通常需要 | 含数据库迁移，元数据量大时更长 |
| 单个存储／代理节点 | 约 10–30 分钟 | 通常需要 | 逐节点滚动升级 |
| 单台 Agent | 约 3–10 分钟 | 视系统而定 | 在线升级更快 |
| 100 台 Agent（分批） | 约 2–6 小时 | 视系统而定 | 需限制并发批次数 |
| 升级前备份 | 约 10–60 分钟 | 否 | 与数据量正相关 |
| 升级后回归验证 | 约 30–120 分钟 | 否 | 含代表性备份与恢复 |
维护窗口按「升级前备份 + 升级 + 回归验证 + 回退余量」之和计算，再额外预留 30%–50% 缓冲。批量 Agent 升级要与备份窗口错开，避免同一时间既有升级又有备份任务争抢资源。
这些耗时是规划维护窗口用的取值范围，受数据量、硬件性能、网络与批量规模影响很大，不是本环境的实测值，不能写进验收标准。
常见问题
升级主节点时页面报「子节点上的服务停止运行或重启」，是失败了吗？ 不是。升级主节点会重启子节点上的服务，这个提示属于正常现象。判断成败看系统升级页面的版本号和服务恢复情况。
进度显示升级完成，但安装包版本和页面版本对不上。 以系统升级页面显示的版本为准。安装包版本只说明手里的包是哪个版本，不代表平台已经升到该版本。
平台升完了，Agent 还没升，能先跑备份吗？ 平台用升级包升级后，Agent 需要同步升级后再使用。在升完之前先做小样本验证，不要在版本不匹配的状态下放开全量备份。
升级过了三天才发现问题，还能回退吗？ 不能简单回退。超过 24 小时后新版本可能已经产生了只有新版本能读的还原点，直接换回旧软件包会造成数据不可读。此时要走数据库／元数据还原方案，把平台数据恢复到升级前副本，并重新评估这三天产生的还原点。
升级后旧还原点读不出来了。 先不要动任何数据，也不要手工清理备份链。保留现场并立即触发回退评估，同时按第 21 章的口径报障。