近期，Backblaze 在其计算机备份客户端的更新中悄然加入了对云同步文件夹的默认排除策略，导致 OneDrive、Dropbox 和 Google Drive 等主流云存储服务的数据不再被自动纳入备份范围。这一变化并非简单的功能删减，而是涉及文件系统的底层机制、云端数据一致性的工程挑战，以及备份服务在多云时代的定位重新审视。本文将从技术原理、用户影响和可操作的应对策略三个维度，对这一决策进行全面分析。

技术动因：重新理解点与云同步机制

Backblaze 做出这一决定的核心理由在于云同步服务所使用的特殊文件系统特性。以 Windows 平台的 OneDrive 和 Dropbox 为例，这两个服务广泛采用 reparse point（重新解析点） 技术来实现文件的在线与离线状态管理。Reparse point 是 Windows NTFS 文件系统的一种扩展属性，允许第三方应用在文件系统中嵌入自定义的元数据标记。OneDrive 的 “文件随选”（Files On-Dropbox）功能正是利用这一机制，在本地只保存文件的元数据和少量的元数据缓存，而将实际内容存储在云端；当用户访问文件时，系统才会触发重新解析点，从云端拉取数据。

这种设计带来了一个关键的技术矛盾：Backblaze 在执行备份时，需要读取文件的实际内容并上传到其云端存储。然而，当文件被标记为 reparse point 且处于 “仅在线” 状态时，Backblaze 只能读取到元数据而非真实的数据内容。这不仅导致备份任务无功而返，还可能因为反复尝试访问这些占位符文件而造成不必要的 I/O 开销和带宽消耗。更关键的是，在某些极端情况下，reparse point 的存在可能导致 Backblaze 的扫描器误判文件状态，甚至引发索引错误或备份任务异常终止。

在 macOS 平台，Apple 同样引入了类似的能力 ——iCloud 云盘（iCloud Drive）的文件同样可能处于 “仅云端” 状态，Backblaze 为了避免跨平台的一致性问题，选择了更为彻底的方案：默认排除所有被识别为云同步根目录的文件夹。macOS 客户端在近期的更新中增强了这一检测逻辑，一旦发现目标路径属于云存储服务的默认同步目录（如用户的 Dropbox 文件夹或 iCloud Drive 目录），客户端会自动将其加入排除列表，而无需用户手动配置。

备份逻辑的工程权衡：性能与可靠性

除了文件系统层面的技术障碍，Backblaze 做出这一决定的另一重要考量是 备份性能与恢复可靠性。云同步文件夹的独特之处在于，其内容处于持续变化状态 —— 当用户在多台设备上使用同一云服务时，文件的同步状态、版本历史和冲突处理完全由云服务提供商负责管理。如果 Backblaze 对这些文件夹进行备份，实际上是在复制一个 “流动中的” 数据状态，可能导致以下几个问题：

首先，版本冲突风险。当用户在本地修改了一个文件，同时该文件在云端也被其他设备修改，云同步服务会创建冲突副本并保留历史版本。然而，Backblaze 的备份逻辑并不理解这些冲突版本的存在，可能只备份了某一个时间点的状态，导致用户在恢复时丢失在云端已经解决的冲突信息。其次，重复数据传输。云同步文件夹中的文件往往已经在云端有了完整的冗余存储，Backblaze 对这些数据再进行一次备份，本质上是在浪费用户的带宽和 Backblaze 的存储资源，这与 Backblaze 长期宣称的 “高效、经济” 备份理念相悖。

从工程实践角度来看，Backblaze 的这一策略转变也反映了云备份服务商在多云环境下的定位调整。随着企业和个人用户越来越依赖多个云存储服务（Microsoft 365、Google Workspace、Dropbox 等），纯粹的 “本地文件镜像式” 备份已经无法满足复杂的数据保护需求。Backblaze 似乎在释放一个明确的信号：与其试图成为所有数据的唯一备份入口，不如专注于用户本地生成的原创数据，而将云端数据的保护责任交还给对应的云服务提供商。

用户影响：被忽视的备份缺口

对于普通用户而言，这一变化的直接影响往往在初期并不明显，因为云同步服务本身具备一定的数据保护能力。Dropbox 为所有付费用户提供了至少 30 天的版本历史和文件恢复功能，OneDrive 也提供了类似的能力（付费版支持文件恢复和法律保留）。然而，问题在于 云服务的版本历史与本地备份之间存在本质的功能差异：云服务的版本历史主要用于恢复误删或误修改的文件，但无法应对云服务账户被盗、订阅到期后数据被清除、或云服务本身出现大规模故障等极端场景。

更值得关注的是，许多用户将 Backblaze 视为 “最后的防线”—— 即在所有其他数据保护手段都失效的情况下，能够从 Backblaze 恢复一份完整的本地副本。当 Backblaze 停止备份云同步文件夹后，这些用户的核心数据实际上已经处于 “裸奔” 状态：如果云服务账户出现安全问题，或者用户因为订阅变更而丢失云端数据，将没有任何其他的备份副本可供恢复。这一风险在企业用户场景中尤为突出，因为企业往往同时使用多个云服务，并且依赖于多层数据保护策略来满足合规要求。

值得注意的是，Backblaze 的排除策略并非完全不可调整。在 Windows 平台，用户可以通过 Backblaze 控制面板的 “排除” 标签页查看当前的排除规则，并且可以手动添加或删除自定义排除项；在 macOS 平台，同样可以通过偏好设置中的 “排除” 面板进行配置。然而，需要指出的是，Backblaze 对于某些系统级别的排除规则（如云同步文件夹的检测）被标记为 强制排除项，用户无法通过常规界面将其移除。这意味着，如果用户确实需要 Backblaze 备份这些文件夹，可能需要通过直接编辑 Backblaze 的排除规则配置文件（bzexcluderules_mandatory.xml）来实现，但这一操作通常不被官方支持，且可能在下一次客户端更新后被重置。

可落地的应对策略：构建多层次数据保护体系

面对 Backblaze 的策略调整，用户需要重新评估自身的数据保护需求，并构建更为健壮的多层次备份体系。以下是针对不同用户群体的具体建议：

个人用户：利用云服务原生保护 + 本地冗余

对于仅使用单一云同步服务的个人用户，最经济有效的策略是充分利用云服务本身的版本历史功能。以 Dropbox 为例，其 “版本历史” 功能允许用户在 30 天内（付费版可延长至 1 年）恢复任意文件的旧版本；OneDrive 同样提供了类似的功能。如果用户对数据安全有更高要求，可以考虑在本地外接硬盘上使用 Time Machine（macOS）或 Windows 备份功能，定期对云同步文件夹进行镜像备份。这种方案的额外成本极低 —— 只需要一块外接硬盘即可实现，且不受云服务和 Backblaze 任何一方策略变更的影响。

专业用户与小型企业：多云备份与不可变存储

对于依赖多个云同步服务且对数据可用性有严格要求的用户，推荐采用 3-2-1 备份原则 的强化版本：至少保留三份数据副本，使用两种不同的存储介质，其中至少一份存储在异地且不可变。实践中，这意味着用户应当同时利用云服务自身的版本控制、Backblaze 对本地非云同步数据的备份，以及一个独立于前两者的冷备份目标（如 Backblaze B2 对象存储的归档层或 AWS Glacier）。在选择归档存储时，建议启用不可变（immutable）策略，以防止勒索软件或账户被盗导致的数据被恶意删除。

技术用户的进阶方案：绕过排除规则

对于具备一定技术背景且确实需要让 Backblaze 备份云同步文件夹的用户，可以尝试以下变通方案。第一种方法是将云同步文件夹迁移到非默认路径 —— 例如，将 Dropbox 的默认同步目录从 ~/Dropbox 移动到 ~/Documents/Work/Dropbox，因为 Backblaze 的强制排除规则通常只针对已知的默认云同步路径进行检测，改变路径后可能会绕过检测。但需要注意，这一操作可能影响云同步服务的某些高级功能（如 Selective Sync），且在迁移过程中务必确认所有文件已完全同步。

第二种方法是使用 符号链接（symbolic link） 或 目录联接（directory junction） 来间接包含云同步文件夹的内容。具体做法是：在 Backblaze 监控的目录下创建一个新的文件夹，然后将云同步文件夹通过符号链接的方式指向该位置。然而，这一方案的有效性取决于 Backblaze 对符号链接的处理逻辑 —— 在某些版本中，Backblaze 会自动跟踪符号链接，在另一些版本中则会将其视为普通文件或目录并可能产生意外行为。

写在最后

Backblaze 停止备份云同步文件夹的决定，本质上是在云存储日益普及的背景下，对备份服务的边界进行的一次重新划定。这一决策的技术动因是合理且充分的 ——reparse point 和云端文件随选机制确实为传统备份软件带来了不可忽视的技术挑战。然而，对于用户而言，这一变化也敲响了一个警钟：在多云时代，没有任何单一备份服务能够提供全方位的保护，将数据安全完全寄托于某一家服务提供商存在固有的风险。

构建真正可靠的数据保护体系，需要用户从被动的 “安装即忘” 思维转向主动的风险管理 —— 理解各云服务的保护能力与局限，识别自身的关键数据资产，并针对性地构建多层级的冗余方案。这或许才是 Backblaze 此次策略调整带给行业最值得深思的启示。

参考资料