Azure Linux VM应用一致性备份后置脚本错误码1告警原因咨询

• 首先明确错误边界：当前场景中快照环节已正常执行完成，仅在后置脚本阶段返回错误码1，这类告警不属于Azure备份平台的服务侧故障。Linux环境下Azure备份插件的逻辑是：只要自定义脚本执行返回非0退出码，就会将整体备份任务标记为告警状态，错误码1就是通用的“脚本执行返回非零”标识，不存在特殊的平台侧定义。
• 第一步：核对备份窗口前后的系统变更
  • 检查VMSnapshotScriptPluginConfig.json中配置的后置脚本文件，是否出现权限调整：比如文件权限被修改为无执行权限、所有者从root改为普通用户，非root所有的脚本会直接执行失败（Azure备份插件仅以root身份执行自定义脚本）
  • 检查脚本内容是否被意外覆盖：比如运维自动任务、其他脚本在昨夜把原有的后置脚本替换成了空文件，或是追加了未做异常处理的执行逻辑
• 第二步：排查脚本运行的环境差异
  Azure备份插件执行自定义脚本时，使用的是无交互的非登录shell，不会加载用户目录下.bashrc/.profile中配置的环境变量。很多长期稳定运行的脚本突然失效，都是因为昨夜系统自动更新替换了脚本依赖的工具路径，脚本内硬编码的旧路径找不到对应可执行文件，直接抛出非零返回。
• 第三步：读取本地日志定位具体报错点
  • 直接打开Linux虚拟机上的快照插件日志：/var/log/azure/Microsoft.Azure.RecoveryServices.VMSnapshotLinux/extension.log，定位到后置脚本执行时间段的输出内容，就能看到脚本具体卡在哪一步抛出的错误
  • 顺着脚本自身逻辑排查：常见的后置脚本包含快照后应用状态恢复、备份文件校验、历史备份清理三类操作，任意一步执行失败都会触发错误码1——比如清理历史备份时遇到被进程占用的文件、校验文件时磁盘临时触发只读保护、恢复应用状态时配置文件被其他进程锁定
• 容易漏查的隐形异常项
  • 检查备份窗口期是否出现磁盘空间打满的情况，导致脚本写日志、写临时文件失败触发异常
  • 检查备份窗口的IO抢占情况，比如其他定时任务占满磁盘IO导致脚本执行超时，被系统强杀后返回非零退出码
  • 检查配置文件本身：如果VMSnapshotScriptPluginConfig.json里的后置脚本路径配置错误，指向了不存在的文件，部分旧版本快照插件会把这类“文件找不到”的错误统一透传为返回码1。

内容的提问来源于stack exchange，提问作者Eduardo Noyola