当备份软件开始“挑文件”：Backblaze 悄悄改规则，真正受伤的是用户的信任

一家“省心备份”公司，先让老用户不省心了

如果你问一个资深电脑用户，什么软件最不能偷偷改规则，答案大概率不是浏览器，不是输入法，而是备份软件。

最近，开发者 Robert Reese 发文吐槽老牌云备份服务 Backblaze，说自己用了近十年，直到今年才猛然发现：Backblaze 已经不再备份 OneDrive、Dropbox 等云同步目录，连 .git 文件夹这样的开发者常用目录，也可能被静默排除。更让人上火的是，这不是一次醒目的公告，也不是弹窗提醒，而是被藏在版本更新说明里的一句轻描淡写的“改进”。

这事之所以刺耳，是因为 Backblaze 曾经恰恰靠“别折腾、我全给你备份”赢得市场。很多人记得它，不是因为界面有多漂亮，而是因为它足够朴素：你装上客户端，电脑里能塞进去的东西，它基本都给你往云上搬。对普通用户来说，这种产品哲学非常迷人——你不用想那么多，不用做文件管理员，也不用先修一门“数据治理入门课”。

Robert 的愤怒并不难理解。他曾经真的依赖过这个服务：硬盘损坏后，他还用过 Backblaze 的“邮寄恢复硬盘”服务，把数据完整拿回来。正因为系统曾经兑现承诺，他才会在后来长期推荐这家公司。背叛感往往就来自这里：不是产品一开始做不到，而是它原本做得到，后来却悄悄不做了。

这不是小功能变化，而是备份逻辑变了

Backblaze 在更新说明中的说法是，新的客户端会排除“流行云存储服务”的挂载点和缓存目录，包括 OneDrive、Google Drive、Dropbox、Box、iDrive 等，以避免性能问题、过度流量消耗和“意外上传”，并强调这符合其“只备份本地和直接连接存储”的政策。

单看这段话，你甚至会觉得它有几分道理。今天的云盘客户端确实越来越复杂。所谓 OneDrive 文件夹、Dropbox 文件夹，里面有些文件可能只是占位符，并不真正落地在本地磁盘；有些目录是缓存，有些是按需下载；备份软件如果一股脑儿扫描，确实可能带来重复上传、性能开销，甚至把某些临时文件也一并打包。站在工程师视角，这是个能写进 release note 的“优化项”。

但站在用户视角，这就是另一个故事了。多数人不会去研究“挂载点”“缓存目录”“按需同步”这些概念，他们只会看见一个事实：这个文件夹明明就在我的电脑里，我也一直以为它在备份范围内，为什么真出事时才发现它没被备份？

问题的关键，恰恰不在于 Backblaze 有没有技术理由，而在于它改变了“默认保护边界”。一旦备份服务开始自行判断哪些目录“其实不值得备份”，它卖的就不再是完整兜底，而是一种带条件、带例外、需要用户自己读规则的兜底。这种变化对工程团队是策略调整，对普通用户却是安全感塌方。

更微妙的一点是 .git 文件夹。对很多非开发者来说，这只是个点开头的隐藏目录；但对程序员、研究人员、写作者来说，它可能装着数年的变更历史、分支记录和未推送的提交。你平时感觉不到它的重要，真丢一次就会知道什么叫“数据没丢，历史丢了”。在某种意义上，这比丢一个 Word 文档还更让人窒息。

“同步不是备份”，这句老话为什么又应验了

这场风波里最值得反复强调的一句，其实是老生常谈：同步不是备份。

很多云盘产品这些年把自己包装得太像“保险箱”了。文件放进 OneDrive、Dropbox、Google Drive，用户心理上就会默认它已经很安全。但同步服务的核心目标，是让多设备看到同一份最新状态；备份服务的核心目标，则是在你误删、覆盖、勒索软件攻击、账号异常甚至设备损坏后，仍然能把旧版本捞回来。这两件事表面上像亲戚，实际上不是一个工种。

举个很生活化的例子：你不小心把一个重要项目文件夹删了，Dropbox 可能帮你保留 30 天；OneDrive 也有回收站和版本历史。但如果你一个月后才发现，或者账号因为某种风控、纠纷、误判被封禁，那么“云上还有一份”这件事很可能并不等于“你还能拿回来一份”。同步服务在很多情况下更像镜子，文件删了，它也跟着删；备份服务则应该像档案馆，哪怕你把原件烧了，它还留着旧档。

也正因如此，Backblaze 过去主打“无限备份一切”的叙事才如此打动人。它补的就是同步服务留下来的那个洞。现在它开始把主流云同步文件夹排除在外，某种程度上等于把这个洞重新还给了用户。用户最初买单，是为了少操一份心；结果兜了一圈，还是得自己理解 OneDrive 的保留周期、Dropbox 的版本策略、哪些目录是真本地、哪些只是云端占位。这个体验，怎么想都很难叫“简化”。

真正危险的，不是漏备份，而是“你不知道自己没被备份”

如果 Backblaze 一开始就公开写明：我们不备份云同步目录，不备份 Git 元数据，用户当然可以自由选择接受或离开。商业服务有边界很正常，谁都不可能承诺宇宙万物都备份。

但这次最让人警惕的是“静默修改”。作者提到，自己的 OneDrive 文件夹体量高达 383GB，这并不是角落里一份无关紧要的缓存，而是一大块实实在在的重要数据。服务规则变了，用户没有收到明确通知，没有在控制台里看到醒目的风险提示，官网排除列表也没有足够清晰地反映这些变化。你可以说它写进了 release notes，可问题在于，普通用户有几个人会把备份客户端更新日志当睡前读物？

这也是为什么我认为，这件事的行业意义其实大于 Backblaze 本身。今天的软件行业越来越习惯“持续更新、渐进变更、灰度发布”，很多功能改动都通过 release note 一笔带过。但备份、密码管理、支付、医疗、企业协作这些基础型服务，不适合用互联网产品那套“先改了再说”的节奏。这里涉及的不是转化率或留存曲线，而是用户对系统边界的认知。一旦边界不清晰，灾难发生时，用户承受的是不可逆损失。

过去几年，类似问题并不罕见。苹果的 iCloud 曾因照片同步和本地优化存储机制，让不少用户误以为“设备上没了，云里总会有”；Google Photos 在免费时代结束后，也逼着用户重新理解“云相册”和“真正长期归档”的区别。云服务厂商都喜欢把体验做得像魔法，但凡是魔法，代价通常就是边界模糊。等出事那天，解释权往往还在平台手里。

备份这门生意，最终卖的是信任，不是“无限”两个字

Backblaze 的尴尬之处在于，它曾长期以“无限、简单、安全”的形象示人。这个定位本身没问题，甚至很聪明，因为大多数个人用户购买备份服务，买的不是技术细节，而是一句朴素承诺：你别管那么多，我帮你兜底。

可一旦服务开始出现越来越多“默认排除项”，而且这些排除项不透明、不显眼、不可轻易重开，那“无限”两个字就会变得有点像商场海报上的大号字体。它当然不一定是谎言，但至少已经不是用户脑海里理解的那个意思了。

从商业角度看，我也能猜到厂商为什么会这么做。备份云同步目录，可能会增加存储成本、扫描复杂度、客户支持压力，还会碰到占位文件、重复数据、第三方 API 行为不一致等麻烦。尤其在云存储价格战降温、SaaS 公司越来越强调利润和效率的当下，削减“高成本低感知”的功能，很可能是管理层眼中的理性决策。

但理性不等于体面。你可以限制，可以涨价，可以改套餐，甚至可以说“这部分我们不做了”。唯独不该让用户在真需要恢复文件的那一刻，才第一次知道规则早就变了。那一刻失去的，不只是某个目录的数据，而是用户以后再也不会轻易相信“默认全备份”这种承诺。

对于今天的普通用户和创作者，我的建议反而很传统：别把任何单一云服务当成终极保险箱。重要资料最好同时满足“本地一份、异地一份、独立备份一份”的 3-2-1 原则。项目代码别只信托管平台，照片别只躺在同步盘，写作资料也别只存在一个生态里。技术越进步，人越容易误以为什么都自动搞定了；可数据安全这件事，最终仍然讨厌侥幸，奖励冗余。

Backblaze 这次风波提醒我们的，不只是某家公司可能偷偷缩了服务范围，而是一个更扎心的现实：在云时代，“看起来在那儿”和“真的能找回来”，从来不是一回事。