问题说明

本文用于排查 Veeam 备份在一次 disable CBT 超时后，后续任务持续失败的场景。

现象

• 第一次备份在 disable CBT 阶段等待约 30 分钟后失败。
• ZSphere 中旧 CBT 任务仍显示 Running。
• 下一次备份先找到旧任务，再因找不到旧 CBT 卷而失败；同一虚拟机反复重试仍失败。
• api-proxy 日志还可能出现 enable CBT 或 export NBD 超时。

适用环境

• 产品：ZVF ZSphere
• 版本：5.1.0
• 组件：ZSphere、api-proxy、Veeam CBT 与临时 CBT 卷
• 部署形态：ZSphere 5.1.0、api-proxy 1.0.4，由 Veeam 调用 CBT 备份

可能原因

• 控制面删除临时卷超时，实际数据面可能已删除，但任务或引用记录没有完成清理（当前待客户环境复现确认）。
• 备份任务并发过高，放大 CBT 创建、导出和清理的时序窗口。
• 外部 CBT 与平台备份同时运行，形成独立的互斥问题。

排查步骤

1. 还原第一次超时到后续失败的任务链

• 检查对象：同一虚拟机最近一次成功备份、第一次失败和下一次失败的 Veeam/CBT 任务。
• 操作位置：记录 虚拟机 UUID、Veeam job、CBT task UUID 和准确时间，并按以下步骤查询：

1. 在 ZSphere UI 打开第一次失败任务的详情，记录 apiId。SSH 登录管理节点后执行：

     KB_API_UUID='将任务详情中的apiId粘贴到这里'
     cd /usr/local/zstack/apache-tomcat/logs || exit 1
     ls -lh management-server.log*
     zgrep -a -n -C 3 "$KB_API_UUID" management-server.log*
     zgrep -a -n "$KB_API_UUID" management-server.log* | grep -iE 'json POST|http response|cbt|nbd|delete|timeout'

从请求和响应中记录目标 Agent IP、URI、taskuuid/taskUuid 和时间。若第一次超时与后续失败具有不同 apiId，必须分别查询，不能只保留后一轮错误。

2. SSH 登录请求对应的 ZSphere 主机，用 taskuuid 查询当前与轮转日志：

     KB_TASK_UUID='将management-server日志中的taskuuid粘贴到这里'
     cd /var/log/zstack || exit 1
     ls -lh zstack-kvmagent.log*
     zgrep -a -n -C 5 "$KB_TASK_UUID" zstack-kvmagent.log*
     zgrep -a -n "$KB_TASK_UUID" zstack-kvmagent.log* | grep -iE 'cbt|nbd|volume|delete|not found|error|fail|timeout'

3. 日志采集范围至少覆盖 disable CBT 开始前 5 分钟到超时后 5 分钟；本场景单次等待约 30 分钟，因此只截取报错瞬间会漏掉创建、删除和超时之间的因果链。需要上下翻看当前日志时使用 vim -R 日志文件，输入 / 后粘贴 UUID 并按 Enter，按 n 看下一处，输入 :q! 退出。

• 预期结果：每次失败都能对应到明确阶段，例如 enable CBT、export NBD、disable CBT 或 stop 虚拟机，而不是只保留 Veeam 最终错误。
• 异常处理：日志不覆盖故障时间或资源 UUID 不完整时，不能清理旧任务；先补采下一次可复现窗口。

2. 对比控制面 CBT 任务与数据面临时卷

• 检查对象：旧 CBT task 的状态/更新时间、关联临时卷引用，以及主机上该卷的实际存在状态。
• 操作位置：在 UI/CLI 查询旧任务；在日志检索 disable cbt、cbt volume、delete、not found。由支持人员在目标主机执行只读卷检查，确认临时卷是否存在。
• 预期结果：Running 任务仍有对应临时卷，或已完成任务及其引用都已清理。
• 异常处理：任务长期 Running、临时卷已经删除但引用仍在，即命中控制面/数据面不一致分支；禁止直接删除数据库记录或猜测 LV 名称清盘。

3. 排除端口占用和并发放大因素

• 检查对象：api-proxy 日志中的 16443 端口错误、enable CBT task timeout after 10800 seconds、export NBD timeout 和同一时间的备份并发数。
• 操作位置：api-proxy 日志目录可能随部署方式变化，先只读查找实际文件，再检索当前与归档日志：

  find /var/log/zstack /usr/local/zstack -type f \( -iname '*api-proxy*.log*' -o -iname '*apiproxy*.log*' \) -print 2>/dev/null
  find /var/log/zstack /usr/local/zstack -type f \( -iname '*api-proxy*.log*' -o -iname '*apiproxy*.log*' \) -print0 2>/dev/null | xargs -0 -r zgrep -a -n -iE '16443|enable CBT task timeout|export.*nbd|disable.*cbt'

如果第一条命令没有找到文件，从 Veeam/api-proxy 部署节点的日志采集包中确认路径，不要假定日志一定在管理节点。然后按分钟统计同一 job 的虚拟机数量及不同 job 是否重叠，并确认平台备份是否同时操作同一虚拟机。

• 预期结果：api-proxy 端口正常，Veeam 与平台备份不并发操作同一虚拟机，低并发窗口不再大量出现 CBT/NBD 超时。
• 异常处理：端口被占用时先处理 api-proxy 监听冲突；只有低并发下仍稳定出现旧任务/卷缺失时，才把主要问题收敛到残留状态。

4. 先错峰止损，再由支持人员修复残留状态

临时方案（Workaround）

• 已验证自助方案：已记录现场建议每个 Veeam backup job 暂时不超过 5 台虚拟机，并将不同 job 错开执行。该数值仅是本案例的临时止损值，不是产品通用上限；先暂停问题虚拟机的自动重试，观察一轮低并发任务。
• 支持协助方案：低并发不能修复已经形成的旧 CBT 状态。由 ZStack 技术支持在确认任务 UUID、临时卷实际状态、数据库引用和维护窗口后提供准确版本的清理方案；本文不提供直接改库或删除 LV 的通用命令。
• 预期结果：旧 CBT task 不再长期 Running，任务引用与临时卷一致；在无并发窗口完成一次完整的 enable、export、disable 流程，后续备份不再报“找不到旧 CBT 卷”。
• 异常处理：低并发仍出现大量 10800 seconds 或 export NBD timeout 时，保留 api-proxy 与主机日志并转入性能/链路专项，不继续清理状态。

补充信息

• 提交支持信息时，应包含准确时间窗、资源和任务 UUID、完整错误文本及相关组件日志。
• 不能从单个现场结果外推所有版本；根因未闭合或操作可能影响业务、数据时，应停止自助处理并提交本文列出的证据。