2025 年中，Backblaze 在其 Mac 备份客户端的更新中悄然引入了一项重大变更：自动排除云存储同步文件夹（Cloud-Synced Folders），包括 Dropbox、OneDrive、Google Drive 等主流云服务的本地同步目录。这一变更导致大量用户发现其云端文件不再被 Backblaze 纳入备份范围，引发社区广泛讨论。从工程视角审视，这一决策折射出云备份服务商在第三方 API 依赖、供应商锁定风险与产品策略之间进行的多重权衡。
云同步文件夹的技术复杂性
理解 Backblaze 决策的第一步，是认识到云同步文件夹在备份场景中带来的独特技术挑战。当用户使用 OneDrive、Dropbox 等服务时，文件实际存在于云端，本地只是同步缓存。这种架构导致几个关键问题：首先是文件状态的不确定性，同步文件夹中的文件可能被标记为「仅在线可用」（Online-Only），数据并未真正落盘，Backblaze 若尝试备份可能读取到空文件或元数据而非实际内容；其次是版本冲突风险，云服务与本地备份服务可能同时修改同一文件，造成版本树混乱；再者是存储效率问题，对云同步文件夹进行全量备份意味着数据会被双重存储 —— 一次在云端，一次在 Backblaze 的存储池中，造成资源浪费。
Backblaze 在其官方文档中明确指出，备份云同步文件夹可能导致「恢复和同步复杂化」，这并非危言耸听。实际上，云服务的文件锁定机制、差异同步策略以及元数据变更频率，都可能与传统的增量备份算法产生冲突。当用户在多个设备上使用同一云同步文件夹时，备份软件需要准确判断哪个版本才是「真实」的最新状态，而这需要深度集成云服务的 API，而非简单地将本地目录纳入扫描范围。
第三方 API 依赖的技术债务
Backblaze 面临的核心问题是：支持云同步文件夹备份本质上意味着要与多家第三方云存储服务建立并维护深度 API 集成。每一个云服务都有其独特的认证机制、速率限制、文件列举方式和元数据格式。Microsoft OneDrive 使用 Microsoft Graph API，Dropbox 拥有自己的 Dropbox API，Google Drive 依赖 Google Drive API，这些 API 不仅在技术实现上各不相同，而且会频繁迭代 —— 认证流程可能变更、端点可能废弃、速率限制可能调整。对于 Backblaze 这样的独立备份服务商而言，为每一家云服务商维持兼容适配需要持续的开发投入，而这种投入的边际效益正在递减。
更深层的问题在于，这种依赖关系带来了无法忽视的技术债务。当某家云服务商更新其 API 版本或调整政策时，Backblaze 必须紧急响应，否则功能可能失效。这种被动状态在工程团队看来是典型的「运维负担」，而且随着支持的云服务数量增加，风险敞口也在扩大。从可持续维护的角度看，放弃对云同步文件夹的支持是一种合理的「做减法」策略 —— 将有限工程资源集中于核心备份功能的稳定性，而非分散在第三方集成的维护上。
供应商锁定的双重视角
这一决策还揭示了云生态系统中一个更广泛的矛盾：供应商锁定（Vendor Lock-in）的双重视角。一方面，用户可能担心 Backblaze 此举是在迫使他们将数据完全迁移到 Backblaze B2 或其自有存储体系，从而加深对单一备份供应商的依赖。另一方面，从 Backblaze 的视角看，支持云同步文件夹备份恰恰可能让自己被绑定到上游云服务的生态中 —— 当 Dropbox 或 OneDrive 调整 API 定价或政策时，Backblaze 的产品路线图将被迫随之调整。
事实上，Backblaze 的核心价值主张是「将本地数据备份到云端」，而非「作为云端数据的副本」。当用户的数据原本就存在于云端时，Backblaze 的角色本质上是一个冗余副本，而这种冗余对用户的实际价值有限 —— 云服务本身已经提供了多设备同步和版本历史等功能。对 Backblaze 而言，继续投入资源备份云同步文件夹，可能与其差异化定位存在冲突。简言之，Backblaze 选择专注于「本地优先」的数据保护场景，将云端数据的备份责任交还给用户或专门的云到云备份解决方案。
产品策略权衡与行业趋势
从产品策略层面分析，Backblaze 的这一决策体现了 SaaS 企业常见的「聚焦核心」思路。备份软件的商业逻辑建立在「数据量乘以单价」的模型上，而云同步文件夹的备份往往产生大量重复数据 —— 用户已经在云端存储了数据，再备份到 Backblaze 意味着 Backblaze 需要为同一份数据支付存储成本，但用户可能只愿为单一的备份服务付费。更关键的是，云同步文件夹的备份并非用户的核心痛点；真正需要备份的是那些本地独有的、无法从云端恢复的文件。
这一趋势并非 Backblaze 独有。观察整个在线备份行业，越来越多的服务商开始区分「本地备份」与「云到云备份」两条产品线，前者聚焦于保护本地文件，后者专门解决跨云服务商的数据冗余问题。Backblaze 的决策本质上是将自己定位为前者，而将后者留给了专门的云到云备份工具。从工程资源配置的角度看，这是一种理性的取舍 —— 与其在多个战场上分散投入，不如在核心领域建立不可替代的优势。
用户的应对策略与工程建议
对于受影响的用户而言，理解这一变更背后的逻辑有助于做出更明智的数据保护决策。如果用户的文件主要存储在云同步文件夹中，当前的最佳实践包括：其一，定期检查云服务本身的版本历史和回收站功能，因为主流云服务商通常提供 30 天以上的文件版本保留；其二，对于关键数据，考虑在本地保留一份独立副本（可使用外部硬盘或非同步的本地目录），这样既能享受 Backblaze 的备份服务，也能规避云同步文件夹的排除规则；其三，如果有跨云备份的刚需，可以评估专门的云到云备份工具，而非依赖传统的本地备份软件。
从系统设计的角度看，Backblaze 的案例为工程团队提供了一个关于「何时做减法」的范例。当第三方依赖带来的维护成本超过其用户价值时，果断放弃并清晰传达变更原因，往往比勉强维持一个低质量的集成更能赢得用户的长期信任。透明的产品策略变更配合完善的迁移指导，是 SaaS 服务商处理此类决策的最佳实践。
资料来源：本分析参考了 Backblaze 官方社区讨论、TidBITS 技术论坛用户报告、以及 Dropbox 官方支持论坛的用户反馈。
延伸阅读：Backblaze 在 2025 年 9 月发布的 Mac 客户端更新（版本 9.2.2.878）中首次引入了云同步文件夹的自动排除机制，后续版本延续并强化了这一行为。