云存储的文件去重策略

文件去重可根据负载类型将云存储减少20-90%，使用三种技术之一：文件级去重（按 SHA-256 哈希存储相同文件的单一副本）、块级去重（将文件切分为4-128KB的块并按块去重），或通过 Rabin 指纹实现的内容定义分块（CDC）可变长度分块。虚拟机备份可实现10:1的缩减；普通办公文件约2:1；媒体库几乎没有收益。选择与你数据匹配的技术——对已经全部唯一的 .mp4 文件库运行块去重，浪费 CPU 而毫无收益。

文件级去重：最简单的收益

文件级去重比较整文件哈希。两个 SHA-256 相同的文件是完全一致的；保留一份，将另一个指向它。实现只需一个周末：

1. 清点存储桶内容（S3 Inventory、Azure Inventory、GCS 存储桶列表）
2. 计算每个对象的 SHA-256（或使用服务商提供的 ETag，但有注意事项）
3. 按哈希分组，每组选定一个规范键，更新引用，删除重复项

注意事项：S3 ETag 只对5GB以内的单段上传匹配 SHA-256。多段上传使用不同公式（哈希的哈希）。对于可靠的去重，用 aws s3 cp s3://bucket/key - | sha256sum 自行计算哈希，或在上传时计算并存入元数据。

文件级去重适合用户频繁上传相同文件的场景——厂商 PDF、公司模板、共享图片。典型办公工作负载预期节省10-30%。

块级去重：大倍数压缩

块级去重将每个文件分割成固定大小的块（4KB、16KB、64KB）并对每个块哈希。两个共享80%块的文件只存储唯一的20%加一份共享块。备份产品（Veeam、Rubrik、Commvault）、文件系统（ZFS 的 dedup=on、Btrfs）以及部分备份云（Backblaze B2 客户端侧去重）都使用这种方式。

优势：对 VM 镜像、数据库备份和大范围共享的日志归档有巨大压缩效果。劣势：内存占用高（去重索引驻留在 RAM 中）、写入时 CPU 开销大，索引损坏会造成灾难性的数据放大。

对于云对象存储，块去重通常在备份产品内部完成，而非原生功能。S3 本身不去重；Backblaze B2 在客户端预先发送块哈希时进行上传时去重（b2_start_large_file 加预哈希段）。

内容定义分块（CDC）

固定大小分块在文件开头插入一个字节时就会失效——后续每个块的哈希都不同。内容定义分块使用滚动哈希（Rabin-Karp 指纹）根据内容模式定义块边界。插入一个字节只改变当前块的哈希。

CDC 是 restic、BorgBackup、Duplicacy 和 Kopia 的基础。这些开源工具使用平均1-4MB的可变块在客户端进行去重。对于每天增量变化的500GB文件进行备份，基于 CDC 的备份通常只需不到50GB的唯一存储。

如果你在构建备份或同步系统，通过 fastcdc-rs 或 chunky 等库使用 CDC 是现代的选择。不要自己实现滚动哈希——边界情况很微妙。

内联去重与后处理去重

内联去重在写入时运行——数据上磁盘之前，系统检查块是否已存在。存在则写入引用；不存在则写入块。ZFS、大多数备份设备和部分云存储层使用内联方式。

后处理去重先写入，再运行后台任务查找重复项并回收空间。Windows Server 的数据重复删除、NetApp SnapVault 和大多数用户空间工具使用后处理方式。后处理写入延迟更低，但需要更多峰值存储（重复项在回收前短暂存在）。

对于云工作负载，内联去重通常不可用——S3 不提供。使用计划任务（每日清单、每日去重运行）的后处理是实用模式。

去重无效的场景

已压缩或已加密的数据去重效果极差。两个不同的 .mp4 文件，即便内容相似，几乎不共享任何字节。相同明文的两个加密 .zip 文件，加密后共享零字节——这正是加密的目的。

这意味着端到端加密的文件存储无法跨用户去重。收敛加密（哈希明文，将哈希用作密钥）曾试图在 E2EE 中实现去重，但存在安全问题——它使文件确认攻击成为可能。对于 E2EE 文件服务，接受去重仅在用户自身文件内进行，而不跨用户。

去重的安全问题

非 E2EE 系统中的跨用户去重会产生旁路：如果你上传的文件与现有块去重匹配，服务器就知道其他人已经有了这个文件。Dropbox 在2011年曾暴露此问题，其他一些服务也有类似情况。对于共享企业账户这没问题，但对于声称具有隐私性的服务，这是信息泄露。

如果保密性重要，只在用户自身数据内去重（用用户特定密钥加盐），而不跨整个系统。或接受 E2EE 意味着没有去重，相应地规划存储容量。优先考虑隐私的工具——例如 HexaTransfer 用于加密的临时传输——以去重效率换取没有人（包括服务本身）能判断两个用户是否拥有相同文件的保证。

衡量去重效果

不要只是启用去重然后寄希望于它有效。测量去重比率：

dedup_ratio = logical_bytes / physical_bytes

比率2:1意味着每1字节物理存储对应2字节逻辑数据。报告工具：ZFS 上的 zpool get dedupratio，Windows Server 上的 Get-DedupStatus，restic/Borg 的每仓库统计。

各负载健康比率：

• VM 镜像：8-20:1
• 数据库备份：10-30:1
• 文件服务器（办公文档）：1.5-3:1
• 邮件归档：2-5:1
• 媒体库：1.0-1.1:1（不值得去重）
• 加密归档：1.0:1（不可能去重）

如果某负载比率低于1.5:1，关掉去重——CPU 和内存的成本得不偿失。

备份产品集成

大多数企业不会从头实现去重——他们使用内置去重功能的备份产品。选型时的比较维度：

• Veeam：内联块去重，默认512KB块，去重后压缩
• Rubrik：内容定义可变块，子块去重
• Commvault：客户端去重，含每客户端和全局池
• restic/Borg/Kopia：开源 CDC，客户端侧，支持 S3/B2/Azure 后端
• BackupPC：基于硬链接的文件级，简单但较旧

对于小企业将2TB备份至 S3 Glacier，使用 restic 备份至 Glacier Instant Retrieval，5:1去重比率下约每月105元。对于500TB企业数据资产，具备去重功能的正规备份平台的存储节省在第一年就能收回成本。

在去重之上叠加压缩

去重消除重复字节；压缩消除唯一字节内部的冗余。两者可叠加。去重后，对文本密集型数据应用 zstd 压缩，额外再减少1.5-2倍。BorgBackup 支持 --compression zstd；restic 有 --compression max；AWS EFS 对 OneZone-IA 提供透明压缩。

顺序很重要：先去重（以暴露重复块），再压缩唯一块。先压缩通常会使去重失效，因为微小的输入变化会在压缩输出中扩散。所有正规备份产品都能正确处理这一点——你只需选择合适的参数。

去重枯燥、不光鲜，却是混合工作负载中降低存储成本的最大杠杆。清点数据，选择匹配内容的技术，测量比率，把省下来的预算用在刀刃上。

免费试用 hexatransfer.com——无需注册，单次最大10GB。