Papa Labs

Synology Active Backup 备份某台机器一直失败:又是防火墙策略

Synology Active Backup for Business 跑全公司 PC 的定时备份,一切安好,唯独 R&D 的一台机器永远失败

排查思路:先问网络,再问软件

这台机器的特殊之处不在硬件也不在系统——在它接的网络。R&D 设备接在实验室专用的 SSID/子网里(和办公 LAN 隔离,这本身是对的:实验室设备不该和生产网混在一起)。

在 NAS 和目标机器之间做最基本的连通性测试:ping 不通。不用再看 agent 日志了,答案已经出来了——

备份流量从 LAN(NAS 所在网段)到实验室子网,防火墙上根本没有放行的 policy。

NAS 到实验室子网的备份流量被防火墙挡住的示意图

十分钟的故事:一条缺失的 policy,一条补上的 policy

修复

在防火墙上加一条 policy:允许 LAN → 实验室子网 的备份相关流量(源:NAS 地址,目标:实验室网段,端口按 Active Backup 的需求放行)。

改完立刻验证:

  1. NAS ping 目标机器——通了
  2. Active Backup 手动触发一次备份——成功

前后十分钟。

为什么值得写下来

因为这类问题的症状表现在应用层,根因却在网络层,排查顺序错了就会浪费大量时间:重装 agent、重建备份任务、查 NAS 日志……都没用。

网段隔离的环境里,任何「只有某台/某组机器异常」的问题,第一反应都应该是:

这台机器在哪个网段?到服务端的路是通的吗?

一条 ping(不通再补一条 Test-NetConnection -Port <端口>)就能把问题定位在网络层还是应用层,这永远是最便宜的第一步。

教训

  1. 备份系统的覆盖检查要按网段过一遍:新划分的子网、新加的 SSID,默认是到不了备份服务器的,防火墙策略要跟着补;
  2. 网络隔离做得越好,这类问题越常见——这是隔离的代价,值得付,但要把「新网段上线 checklist」里加上备份连通性这条;
  3. 「只有一台机器失败」是网络问题的经典指纹,别急着动软件。
← 全部文章