定时备份任务跑了三个月，才发现计划任务默认不重试失败那一步

先说结论：Windows 计划任务里那个「如果任务失败，按以下频率重新启动」的选项，默认是关的，而且它跟「重试」不是一码事。

事情是这样，我给家里那台老笔记本配了个每天凌晨三点自动备份的活，用命令行调 7z 打包指定目录，再拷到移动硬盘。跑了三个月一直以为稳得很。上周硬盘掉线了一次，我第二天看日志发现备份根本没生成——任务计划程序里显示「操作已完成」，但返回码不是 0。

我一开始以为是硬盘的问题，拆下来挂到主力机上跑了 SMART 短测，健康度 98%，没坏道。又换了一根 USB 线，照样。折腾到晚上才反应过来，去翻计划任务的设置页，在「设置」标签里找到那个复选框——「如果任务失败，按以下频率重新启动」，默认没勾。也就是说打包那一步如果中途报错，整个任务就直接结束，连个重试都没有。

这里有个坑得说清楚：计划任务里有两套重试机制，容易搞混。

• 一套在「设置」标签，叫「如果任务失败，按以下频率重新启动」，针对的是整个任务失败后的重试；
• 另一套在「操作」里，命令行程序自身返回非零码时，计划任务默认是不管的，得靠上面那个选项兜底。

我测试的方式是拿三台样机（一台 Win10 22H2、一台 Win11 23H2、一台 Server 2019）都建了同一个任务，然后故意把移动硬盘拔掉再插上，模拟路径不可达。

• 不勾重试：三台全部直接结束，日志里「上次运行结果」显示 0x1，但任务状态是「就绪」，很容易被忽略；
• 勾上重试、间隔 5 分钟、尝试 3 次：Win10 和 Win11 都能在硬盘恢复后自动补跑一次，Server 2019 上则需要额外确认「只有在用户登录时运行」这个选项没勾，否则重试逻辑有时不触发。

另外发现个细节：「如果任务失败」的判定，跟脚本自己的 exit code 强相关。我的批处理最后一行是 7z 的命令，它返回 0 才算成功。但中间如果用了管道或者多行命令，最后一条命令的返回码才是整个脚本的返回码，前面哪一步挂了都可能被吞掉。所以我在脚本里加了一行显式的 if errorlevel 1 exit /b 1，把这层兜住。

还有个容易漏的点：任务计划程序里那个「如果错过计划开始时间，则尽快启动任务」的选项，跟失败重试是两回事。前者管的是机器关机错过时间点，后者管的是执行中途失败。我一开始把俩搞混了，以为勾了前者就万事大吉，结果硬盘掉线那晚根本没触发。

现在我的做法是：重试勾上、间隔 10 分钟、尝试 2 次，脚本里加显式返回码，日志单独重定向到文件，每天晚上扫一眼日志末尾有没有 ERROR。

问一句：你们在计划任务里跑备份或者自动化，是更依赖任务自带的重试，还是干脆在脚本里自己写循环重试？我倾向于后者，可控一点，但脚本会变长，想听听大伙怎么权衡的。