云备份巨头偷偷删规则：你的文件真的安全吗？

一家承诺"无限备份"的公司，用了10年才让用户发现——有些文件夹早就不在保护范围内了。

10年老用户的信任崩塌

2015年，我（原文作者）把备份方案从两块轮换外置硬盘，换成了Backblaze。原因很简单：不像Crashplan那样臃肿的Java应用，它承诺"无限存储"——只要你能塞进电脑，它就帮你备份。

那年硬盘评测报告帮他们赚足了口碑，朋友同事都在推荐。我装了软件，跑了几个星期，数据确实安全上云。

几年后一块硬盘报废，我试了他们的"寄硬盘恢复"服务。装满数据的硬盘送到手上时，我觉得这系统确实靠谱。此后多年，但凡有人问备份方案，我都推荐Backblaze。

当然有些小毛病：导入大量照片后内存占用飙升，网站恢复单文件时慢得卡顿，Windows客户端像2000年代的复古界面。还有那次把用户文件名泄露给Facebook的事——但应该修好了吧？

这些都能忍。毕竟备份软件的核心承诺是：保护你的文件。

第一个漏洞：消失的Git历史

2025年初，我在GitHub上误操作用了push -f，把用了五年的代码仓库历史抹掉了。数据没丢，但变更记录全没了。

不慌，Backblaze有备份——这是我当时的想法。

结果找不到。某个时间点开始，Backblaze不再备份.git文件夹。更气人的是，设置里的排除列表根本找不到.git的踪影。

我懵了。9年前装软件时明明检查过排除项，当时没这条啊？那我还漏掉了什么？

算了，吃一堑长一智。直到一周前，我在Reddit刷到一条帖子："Doesn't back up Dropbox or OneDrive folders anymore"。

我的Dropbox文件夹里有近1TB数据。赶紧检查——果然，最后备份日期停在2025年1月。

沉默的规则变更

Backblaze的官方文档现在写着：默认排除iCloud Drive、Dropbox、Google Drive、OneDrive等同步文件夹。

但文档没说的是：这个变更什么时候发生的？有没有通知用户？

我翻遍了邮件记录，没找到任何关于"我们将停止备份你的云同步文件夹"的提醒。软件界面里，这些排除项同样隐身——你只能在高级设置里手动展开层层菜单，才能发现某些路径被打了叉。

更隐蔽的是.git排除。它不在任何可见列表里，却从某个版本开始默默生效。开发者依赖的版本控制历史，就这样从备份中蒸发。

Backblaze的商业模式建立在"无限备份"承诺上。但"无限"的定义权，显然在公司手里。

为什么这很阴险

云同步文件夹被排除，表面逻辑说得通：这些文件已经在云端了，何必重复备份？

但用户场景比这个假设复杂得多。

我的Dropbox里有本地-only的文件，有版本冲突时的临时副本，有不小心删除后靠Backblaze找回的旧版本。云同步和云备份是两层保险，不是替代关系。

更关键的是信任契约。用户装备份软件时，默认状态是"保护我的一切"。Backblaze把这个默认改成了"保护我们认为值得保护的"——却不告诉你。

Reddit帖子下的回复揭示了规模：有人发现整个Documents文件夹被跳过，因为里面有个Google Drive快捷方式；有人3年没完整备份却毫不知情；有人直到硬盘崩溃准备恢复时，才发现关键数据从未上云。

备份软件最可怕的不是失败，是沉默的失败。你以为有保险，实际没有。

技术债务还是商业算计？

Backblaze面临的真实压力不难推测。无限存储承诺遇到现实：用户数据量爆炸，云存储成本刚性上涨。

同步文件夹成了明显的成本靶子——1TB Dropbox用户可能给Backblaze贡献1TB重复数据。排除它们能显著降低存储压力。

但执行方式暴露了优先级：省钱 > 透明 > 用户知情权。

对比竞争对手的诚实：iDrive明确列出排除项，Crashplan允许精细控制包含/排除规则。Backblaze的选择是隐藏变更，让老用户在不知情中"自然流失"高成本数据。

更深层的问题是产品哲学漂移。早期Backblaze的卖点是"无脑备份"——装了就忘，它在工作。现在这个"无脑"变成了双向：用户不知道它在不工作。

我的补救与行业启示

发现真相后，我做了三件事：

第一，手动把Dropbox、OneDrive路径加回备份列表。设置藏得深，但至少还能操作。

第二，导出完整文件列表，交叉核对本地与云端。耗时3小时，找出另外两处"沉默排除"：一个虚拟机镜像文件夹，一个Node_modules目录。

第三，开始评估替代方案。Arq Backup、BorgBase、甚至回归本地NAS+异地冷备的组合。

这件事给整个云备份行业敲了钟。当"无限"承诺变成动态定义，当默认设置悄悄转向成本优化，用户需要的新能力不是信任，是审计。

检查你的备份。不是看"最后备份时间"，是抽样恢复文件核对内容。不是看设置界面，是导出实际排除清单。

Backblaze至今没有就这次规则变更发表公开说明。他们的论坛里，相关帖子被标记为"已回答"——回答内容是文档链接，解释"为什么排除同步文件夹是合理的"。

合理与否，该由用户判断。但判断的前提是知情。

备份行业的信任重构

这件事暴露了一个结构性矛盾：云备份服务商的商业模式，与用户数据增长的曲线正在脱钩。

Backblaze 2024年财报显示，个人备份业务毛利率承压，B2云存储才是增长引擎。个人用户的"无限"承诺，从现金牛变成了成本中心。

排除策略是温和的收缩：不涨价，不限制容量，只是重新定义"什么算你的数据"。对大多数用户，这个变更永远不会被发现——直到灾难发生。

更聪明的竞争对手已经开始差异化。Wasabi主打"无出口费+无API调用费"的透明定价，Storj用去中心化架构把成本结构摊给用户选择，甚至Dropbox自己推出的备份服务都在强调"备份一切，包括其他云"。

Backblaze的困境在于品牌定位卡住了。他们靠"简单无限"起家，现在既不能放弃这个标签，又无法承担真实成本。沉默的排除规则，成了技术债与商业现实之间的灰色地带。

对科技从业者的直接启示：任何"无限"承诺都值得拆解。看服务条款的变更历史，看社区论坛的异常投诉，看恢复流程的实际测试。

你的备份策略，不该建立在"他们应该不会"的假设上。

数据主权的新命题

更深一层，这件事触到了云时代的核心焦虑：当你把数据交给第三方，实际控制权边界在哪里？

Backblaze的用户协议允许"为服务运营需要修改备份范围"。这个条款的存在本身不意外，意外的是执行方式——没有版本通知，没有设置界面提示，没有恢复前的完整性校验。

对比欧盟《数字服务法》对平台变更的通知义务，云备份行业基本处于自律真空。用户唯一的防护是定期检查，但备份软件的设计初衷就是"装了就忘"。

一些技术社区开始涌现自救方案：开源工具rclone+加密存储的DIY组合，本地Borg备份+rsync.net的混合架构，甚至回归磁带冷备的极端方案。

这些方案的共同点是把控制权拉回用户侧，代价是复杂度上升。Backblaze的价值主张——"为不懂技术的人做备份"——在这个维度上出现了裂痕。当你需要懂技术才能确认备份真的在工作，产品承诺已经部分失效。

我的最终方案是分层：Backblaze保留，但降级为"灾难恢复的最后一层"；主力改用Arq Backup+Wasabi，加密密钥自持；关键数据额外走Synology NAS的异地同步。

成本从每年$70涨到$200，但睡眠质量的提升无法量化。

当"无限"成为历史

回溯Backblaze的产品演进，能画出一条清晰的收缩轨迹。

2015年的无限是真的无限：外接硬盘、网络存储、系统镜像，统统打包。2018年开始排除部分虚拟磁盘格式，2021年限制外接硬盘的备份频率，2024年轮到云同步文件夹和开发环境目录。

每次变更都有技术理由：虚拟磁盘一致性难保证，外接硬盘频繁插拔浪费带宽，云同步文件夹重复存储不经济。但累积效应是"无限"的语义持续窄化，而品牌沟通始终停留在早期承诺。

这不是Backblaze独有的问题。整个"无限存储"赛道都在经历类似调整：Google Photos结束免费无限存储，Amazon Drive直接关停，iCloud的