无闲置主机、无公网 IP 的多网点归集方案

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

摘要：最近在帮几个连锁门店客户做多网点数据归集，发现传统内网备份方案在"没有闲置中转机、没有固定公网IP"的环境下很难落地，折腾了一圈试了网盘、NAS、VPN各种组合，最后整理出一套轻量方案，记录一下思路和踩坑过程。

背景：一个很常见的小困境

前阵子帮客户处理备份需求，客户情况大概是这样：

• 十几家门店，每家门店一台收银/业务电脑
• 总部在写字楼，门店都是普通宽带，没有固定公网IP
• 拿不出一台闲置电脑当备份服务器
• IT就一个人，不可能去每个门店搞VPN、配域名穿透

客户的诉求很简单：门店每天的营业数据、账套文件，能自动汇总到总部，别靠人工U盘拷来拷去，也怕勒索病毒把本地文件加密了找不回来。

听起来简单，但真落地的时候才发现，常见的几条路都走得不太顺。

先试了几种方案，都有硬伤

1. 网盘同步

第一个想到的就是网盘，直接装个客户端把门店文件夹同步上去。 实际用下来几个问题：

• 企业网盘按人数收费，门店多了成本不低
• 上传下载都限速，几个G的账套备份传半天
• 数据全在网盘厂商那边，真要导出或者停服，迁移很麻烦
• 没办法做细粒度的病毒文件拦截

2. NAS集中存储

总部放一台NAS，门店通过VPN连上去备份。 问题是：

• NAS本身要花钱买，还要做RAID、做硬盘冗余
• 每个门店都要配VPN，普通门店员工根本搞不定
• 宽带上传带宽有限，十几家门店同时往总部传，总部宽带扛不住

3. 传统内网备份软件

之前用过的几款内网备份软件，架构是"备份服务器主动拉取"模式，要求所有节点在同一个内网里，或者通过VPN打通。 对客户这个场景来说，最大的门槛就是：

• 必须有一台机器当备份服务器（客户没有闲置机）
• 跨地域必须组网（VPN/域名/内网穿透）
• 门店数量多了之后，每加一台就要重新配一遍

折腾了一圈，发现客户这个需求的本质不是"做一份备份"，而是把分散在各个网络节点的文件，低成本地汇集到一个集中存储里。这个场景和传统的机房灾备还不太一样。

最后用的方案：客户端直连对象存储

后来调整思路，既然不需要"服务器主动拉"，那不如让每个终端自己"往外推"。 整体思路很简单：

为什么选对象存储当存储后端

几个原因：

• 按量计费，前期没多少数据的时候成本很低
• 下载不限速，真要恢复的时候速度有保障
• 数据存在客户自己的云账号里，权限自己掌控
• S3协议通用，以后想换存储后端也方便，不被绑死

几个实际用下来比较实用的细节

静默运行和自愈 客户端装完就藏在后台，不弹窗口不打扰门店员工。之前担心门店电脑经常重启、断网，实际测试下来，网络恢复之后客户端会自动重新连接，不需要人工干预，省了很多远程运维的麻烦。

防勒索的处理 这个是财务类客户特别在意的。做法是两层：

• 一层是后缀名监控，把常见的勒索病毒加密后缀加进黑名单，遇到这类文件直接跳过不上传
• 另一层是白名单机制，只允许特定后缀的文件（比如账套、Excel、Word）上传，其他类型的文件默认不传 这样即使本地中了招，备份集里也不会被污染。

状态可视化 客户端做了一个简单的监控面板，能看到：今天传了多少文件、成功多少、失败多少。失败的点进去能看到具体是哪个文件出了问题，不用去翻日志猜。 对代维的人来说这个很重要——不用等客户打电话说"备份没成功"，自己打开面板就能发现异常。

和传统内网备份方案的边界在哪

用下来最大的体会是：没有万能的备份方案，关键看场景匹配。

如果是机房服务器、核心业务系统，能拿出一台机器专门做备份服务器，那传统的内网备份方案依然是最稳的，数据走内网速度快、可控性强。

但如果是下面这些情况：

• 节点分散在不同城市、不同网络
• 没有公网IP，也不想搞复杂组网
• 拿不出一台专门的备份中转机
• 终端数量多，不想按台数付授权费

那"客户端直连对象存储"这种轻量推送模式，反而更合适。本质上它不是在做"机房级灾备"，而是在做数据归集——把散落在各处的文件，低成本地收到一个集中存储里，沉淀成企业自己的数据资产。

几个踩过的坑

最后记录几个实际部署时遇到的问题，给后面做类似方案的人参考：

小结

做多网点数据归集这件事，核心其实不是选哪个工具，而是先想清楚两个问题：

• 你的节点在什么网络环境下？有没有条件做内网/公网互通？
• 你有没有一台专门的机器当中转？

把这两个问题想清楚，方案自然就出来了。节点集中、有内网、有中转机 → 传统备份方案；节点分散、跨公网、没中转机 → 客户端直连对象存储的轻量归集方案。

后面如果有更多实际部署的细节（比如OSS生命周期怎么配、防勒索规则怎么写），再单独写文章记录。