VPN 恢复后，你的 NAS 备份仍然失败了

VPN 在 06:10 重新连接，仪表板显示隧道为绿色，而夜间备份依然没有新的恢复点。这不是矛盾；这是两个从未协调过的时刻表。隧道恢复是网络事件。备份完成是带有自身状态机的应用事件，而一次被中断的运行可能被挂起、取消，或者被完全排到别的东西后面。

围绕已完成的恢复点来规划时间窗口，而不是围绕隧道的指示灯。

从恢复点开始，而不是从起始时间开始

把需求写成一个已接受版本的截止时间：一个新的恢复点在指定时间之前通过任务自身的完整性检查。然后倒推预期时长、正常波动和一次被中断的尝试。启动时间不是承诺；它只是调度器尝试的那一刻。把截止时间放进备份策略，而不是聊天消息里。只存在于某个人记忆中的数字不是监控阈值。

用任务的历史来估算时长。分块处理、去重和索引工作都是运行的一部分，所以用链路速度去除以变更字节会低估窗口，这种低估之后看起来像网络问题。

Hyper Backup 区分可以恢复的工作和不能恢复的工作：有文档记载的行为是，连接中断时可恢复的任务会变为挂起，不可恢复的任务会变为取消。这两种状态都无法从 VPN 客户端看到，也都不能通过重新连接隧道来修复。在假定下一次计划运行会从上次停止的地方继续之前，请先读取任务状态及其记录的原因。

手动挂起和网络中断可能遵循不同的生命周期。如果操作员暂停了任务，重新连接网络完全不会改变任何东西。

恢复的隧道并不会挂载加密共享文件夹、不会续期过期的备份凭据，也不会完成目标端的维护。这些是各自独立的就绪检查，其中任何一项都可能把绿色隧道变成失败的作业。在把责任推给恢复计划之前，先确认目标可访问且可写入。

如果目标 NAS 本身重启过，备份任务触发时它的服务可能仍在启动。一次简短的就绪检查比一次失败的运行加一次重试更便宜。

完整性检查可以在完全没有网络故障的情况下占用窗口。DSM 记载每个任务只有一个活动进程，而一次计划备份可能排在该任务的完整性检查后面等待，并在大约三小时的最长等待之后被跳过。按观察到的时长把两个时刻表错开，并把被跳过的运行视为调度发现，而不是 VPN 再次失败的证据。

用真正的投递方式启用通知，然后指派一个人去阅读它们。从未启动的作业和半途失败的作业可能不会产生同样的警报。

早晨的问题是是否存在当前可恢复的副本，而不是隧道是否在线。把最后一个被接受版本的时间与截止时间对照，然后从该版本中用一个小文件做一次安全的恢复测试。在排查任何看起来不对的地方时，保留之前良好的版本。

在一个时区里记录时间戳，包括调度器所在时区、目标所在时区以及阅读仪表板的人所在时区。这些排查中不止一次是以时钟差异而不是网络故障结束的，而那条笔记正是让这一点下次可见的东西。