当备份服务悄悄决定不备份你的文件，信任就碎了

今天 HN 上最让人心里发毛的一条，是 Robert Reese 写的这篇：Backblaze 在没有任何通知的情况下，开始默认排除 OneDrive、Dropbox、.git 等文件夹。作者用 Backblaze 十年，一直以为它在"备份所有文件"，直到一次 GitHub 历史被误删，才想起从备份里恢复，结果发现 .git 早就不在备份范围内了。后来又发现 OneDrive 的 383GB 数据也消失了。

这件事最刺眼的地方，不是策略本身，而是整个过程里几乎没有任何通知。没有邮件，没有弹窗，没有警告，甚至连网站上的排除列表都没有更新。唯一能找到的记录，是埋在某个版本更新说明里的一行字，写的是"Improvements"，内容却是"不再备份云存储文件夹"。

嗯，这其实已经不只是"服务变更"的问题，而是"信任边界"的问题。因为备份这件事，本质上是一种长期契约：你付钱，它承诺在某个未来时刻帮你找回数据。这个契约成立的前提，是双方对"什么会被备份"有共同的理解。一旦服务方在背后悄悄改了这个理解，而用户完全不知情，那契约就只剩一半了。

Backblaze 在 2015 年的官网还写着"All user data included by default, No restrictions on file type or size"。这句话今天已经不再成立，但很多老用户仍然按当年的理解在使用。于是当问题真正发生时，才会发现信任已经碎了一地。

这件事更值得警惕的，是它暴露了一个结构性问题：备份服务的边界，正在变得越来越不透明。过去你可能只需要关心"哪些文件在本地"，现在你还得关心"哪些文件夹被云同步覆盖""哪些文件扩展名被平台排除""哪些目录被判定为缓存""哪些行为被判定为异常"。而这些边界，往往不在用户可见的文档里，而是在某个内部策略、某个自动检测、某个性能优化里。

作者还提到一个很关键的区别：同步不是备份。OneDrive 和 Dropbox 确实会把文件传到云端，但它们保留删除文件的时间通常只有一个月，版本历史也有限。而真正的备份服务，应该提供一年甚至更长的保留期。也就是说，把文件放在 OneDrive 里，并不等于你已经有备份。你只是多了一个同步副本，而这个副本一旦在源头被删、在云端被判定违规、在账户被冻结时，可能同样会消失。

对普通用户来说，这件事的直接启发其实很有限。你很难在事前知道某个服务悄悄改了策略，也很难在事后立刻发现哪些文件不再被备份。唯一相对可行的做法，是定期验证备份：随机挑几个文件，尝试从备份里恢复；或者定期导出备份清单，检查有没有不该排除的文件夹。但这些都不是根本解，因为它们都是事后补救。

对服务方来说，这件事暴露的问题则更清晰。一个健康的备份服务，至少需要几样东西：对策略变更的显式通知、对用户的变更确认、对排除列表的透明展示、对异常行为的可解释性、以及对历史承诺的可追溯性。没有这些，服务就只是在被动响应，而不是在主动维护信任。

从更大的角度看，我觉得这件事也在提醒我们，云时代的"备份"已经不再是一个简单动作，而是一种需要持续治理的长期关系。你付的不仅是存储费，还有对服务方判断的授权。而这种授权，一旦失去透明度，就会变成单方面的权力。

所以今天真正值得记住的，不是"Backblaze 做了什么"，而是另一句更不舒服的话：当备份服务开始悄悄决定哪些文件不值得备份时，它就不再是在帮你保管数据，而是在替你判断哪些数据重要。而这件事，目前几乎完全在用户视野之外。