实现去重压缩的服务器端备份

数据去重只会将重复的数据片段存储一次，而压缩则会进一步缩小剩余唯一数据的体积。这两种技术之所以对服务器端备份至关重要，是因为它们能够降低数据存储成本、缩短备份窗口，并支持更长的保留周期。本文聚焦于服务器端（即目标端）去重。你将了解分块、哈希、流水线设计以及生产环境调优如何协同工作。本文目标是帮助你构建一条可落地的处理流水线，并提供切实可行的性能与可靠性指导。去重会先于压缩执行，以先减少数据占用。这个顺序对效率至关重要。经过良好调优的去重流水线，能够显著降低数据存储需求，并缩短备份时间。你还将学会如何监控去重效果，并避开常见陷阱。

数据去重与压缩基础

要实现高效存储，你需要掌握两项核心技术。数据去重会仅保留每个唯一数据块的一份副本；压缩则进一步缩小这些唯一数据块的体积。应先执行前者，再执行后者。这样的顺序能最大化节省空间，避免将重复内容重复存储。

Windows Server 数据重复删除功能可以优化任意卷上的可用空间。你可以安装该功能，并根据需求设置自定义计划。此功能能够很好地处理多种服务器工作负载，包括文件服务器和备份目标。

源端去重与目标端去重

处理位置的不同会改变你的整体工作流。源端处理会在数据穿过网络之前先移除重复块，从而减少带宽占用，而且无需额外硬件。目标端处理则是在完整数据流到达存储设备之后再进行处理，这种方式会将工作负载转移到备份目标端。

你的网络基础设施会影响这一选择。目标端处理适合具备高速网络和专用设备的环境；而当带宽有限时，源端处理更为合适。在做决定之前，请先明确你的备份去重策略。正确的选择取决于你的具体环境。

在线去重与后处理去重

处理时机同样会影响系统性能。在线处理会在数据到达目标端时立即进行；后处理则会先完整存储备份数据，再在后续阶段消除冗余。两种方式各有优势。

当你需要保持性能稳定，同时又不确定容量优化会带来多大影响时，后处理通常是更优的选择。由于优化发生在数据写入之后，因此在写入阶段几乎不会带来性能影响。

下表展示了两种方法在吞吐量上的差异：

备份窗口大小决定了哪种方式更适合你。在线方式能够立即节省存储空间，但可能拖慢处理速度；后处理能更快完成备份，但会暂时占用更多磁盘空间。理解压缩与去重的处理时机，有助于你设计更优的系统。

用于备份的分块与哈希

分块会先将数据流拆分为更小的片段，随后去重系统才能对这些片段进行比较。哈希则会为每个片段生成一个简短的“指纹”。这两个步骤共同决定了你的备份流水线能否高效发现并消除冗余。

固定长度分块与可变长度分块

固定长度分块会把数据流切分成大小一致的数据块。你只需设定块大小，之后每个分块都保持一致。这种方法简单、可预测，而且处理速度快，因为系统无需搜索边界。其弱点在于数据一旦发生偏移，效果就会变差。比如在文件开头附近插入一个字节，后续所有块边界都会随之移动。虽然内容本身几乎未变，但哈希指纹会全部改变。结果就是，本该跳过的重复数据也会被重新存储。

可变长度分块则依据内容而非位置来确定边界。系统会扫描数据流，在检测到某种模式时进行切分。这样，微小修改通常只会影响包含该修改的那个分块，其他分块仍能保持原有边界和哈希值。这种方式在处理发生偏移的数据时能获得更高的去重率，尤其适用于数据库和虚拟机镜像。代价是每个字节需要更多计算。选择哪种方式取决于你的数据特征。稳定的归档数据适合固定块；频繁变化的文件则更适合可变块。

哈希算法与碰撞

哈希函数会将每个分块转换为一个固定长度的值。SHA-256 是常见选择，研究充分、应用广泛且值得信赖。BLAKE3 在现代硬件上运行更快，更适合高吞吐量流水线。这两种算法都能产生足够长的值，因此意外碰撞极为罕见。

所谓碰撞，是指两个不同分块得到了相同的哈希值。你不能仅凭哈希相同就认定内容一致。安全的做法是执行字节级验证。当索引报告命中时，将新分块与已存储分块逐字节比较；只有在字节内容确实不同的情况下，才存储新分块。这个检查会增加一次读取开销，但能防止静默数据损坏。许多生产系统为了追求速度而跳过验证，并接受相应风险。对于备份数据而言，验证成本是值得承担的。

构建服务器端备份流水线

构建服务器端备份流水线需要精心设计。其工作流程本质上并不复杂，但每一步都必须能够高效处理大规模内容。你需要理解分块、哈希和索引查找如何彼此配合。一个具体的代码示例将帮助你更直观地把握这一过程。

流水线工作流程

流水线从备份源发来的字节流开始。系统读取该数据流并将其拆分为多个分块；随后为每个分块计算加密哈希指纹；接着将该哈希与去重索引进行比对。若命中，则说明该分块已存在，可以跳过存储；若未命中，则说明该分块是唯一的，需要写入存储池。最后一步是写入清单（manifest），用于将原始文件映射回其对应的唯一分块。

分块大小会直接影响整体效率。更小的分块通常能带来更高的去重率，因为数据变化往往不会覆盖整个分块，文件中的偏移也通常只会影响包含改动的那一块。但与此同时，每个小分块都需要额外元数据，包括哈希、长度和位置等信息。当分块小到 256 字节 时，哈希和管理元数据就会在存储中占据显著比例，开销不容忽视。更大的分块能够减少这类开销，但会降低粒度，从而错失在更小范围内识别重复内容的机会。最佳设置取决于你的工作负载，平均文件大小和变更率都很关键。像 SeqCDC 这样的算法在 8 KB 到 16 KB 的较大分块范围内，吞吐量可提升 15 倍。这种去重权衡会直接影响你的流水线设计。

索引查找还面临另一项挑战：生产服务器可能包含数十亿个唯一分块，你不可能将整个索引都放入内存。一种做法是让哈希仅用于定位而非身份确认。每个分块先生成一个 128 位的 BLAKE2b 指纹，再用其中一个字节决定分片。该指纹本身无需写入磁盘，这样可以将工作集控制在可管理范围内。真正的等值判断仍然依赖完整的规范化内容，并在必要时执行逐字节比对。通过这种设计，索引可以持续扩展，而无需让内存占用按相同比例增长。

这里还适用若干最佳实践。首先，分析你的数据，以评估其去重潜力；其次，在具有代表性的数据集上进行试验，测量去重率、写入吞吐量和索引增长；然后，根据性能需求选择在线或后处理去重；同时确保有足够的处理器性能和内存资源。索引一旦得不到足够资源支持，性能就会急剧下滑。还要持续监控并按需调整。应将元数据视作关键数据库来管理，并为其设置恢复点。

Veeam Backup & Replication 提供了数据去重与压缩机制，可减少备份文件和虚拟机副本文件的网络流量与磁盘空间占用。Veeam 能够识别同一虚拟机磁盘内部的重复块，也能够识别同一作业中多个虚拟机之间的重复块。这在虚拟机由同一模板部署时尤其有帮助。对于典型虚拟机工作负载，其去重比通常在 10:1 到 50:1 之间。

代码示例：分块、哈希、索引

下面的 Python 代码片段展示了流水线的核心步骤。它会读取文件，将文件按固定大小分块，使用 SHA-256 对每个数据块进行哈希，并检查索引是否已存在。

import hashlib

CHUNK_SIZE = 65536  # 64 KB
index = {}  # 哈希 -> 存储位置

def process_backup(file_path):
    with open(file_path, 'rb') as f:
        chunk_num = 0
        while True:
            data = f.read(CHUNK_SIZE)
            if not data:
                break
            h = hashlib.sha256(data).hexdigest()
            if h in index:
                print(f"数据块 {chunk_num} 重复，跳过")
            else:
                loc = write_chunk(data)
                index[h] = loc
                print(f"数据块 {chunk_num} 为新块，已存储")
            chunk_num += 1

这个示例为了简洁起见使用了固定长度分块。生产系统通常会采用可变长度分块和持久化索引。哈希检查发生在任何写入操作之前，因此能够避免存储已经存在的内容。write_chunk 函数负责存储数据内容，并返回其存储位置。索引会在多次备份操作之间持续保留。

备份去重性能与生产环境实践

生产系统需要的不只是“能跑起来”的流水线。你还需要调优性能、管理规模，并为长期可靠性做好规划。你在这些方面做出的选择，将决定备份窗口能否保持足够短，存储成本能否维持在可控范围内。

索引缓存、Bloom 过滤器与并行处理

去重索引是整个系统的性能瓶颈。决定去重性能的往往不是 CPU，而是元数据访问延迟。应将去重表放在镜像 NVMe 或 Optane 存储上，并使用去重配额来避免当表溢出到更慢设备时出现性能断崖。哈希计算本身在现代系统中已不再是主要难题。现代 CPU 普遍支持 SHA-NI 硬件加速，使得块哈希相对于流水线其他环节而言开销很低。

Bloom 过滤器可以帮助你跳过不必要的索引查找。它是一种紧凑的概率型数据结构，可以告诉你某个分块“可能存在”还是“一定不存在”于索引中。如果结果为否，则该分块必然是新的，可以直接写入而无需访问索引；如果结果为是，则再去检查完整索引。对于大量唯一数据，这种方法能显著减少索引读取次数。

并行处理能够提升吞吐量，但也伴随着权衡。应用于带处理（band processing）和候选集求交的 SIMD 加速可以提高去重速度，但这种基于批次的方法仅在批次相对于语料库规模较小时效果理想。另一方面，MinHash 签名的 Jaccard 相似度难以通过并行化技术有效加速，还可能导致签名拥挤（signature crowding）问题。分区锁（zone-based locking）则提供了另一条路径。每个分区对自身结构拥有隐式锁，从而保证其他线程不会修改它们。不过，每次 VDO 目标启动时，都需要重新配置分区数量和线程数量。

高强度去重会导致块碎片化。顺序读取会逐渐表现得更像随机 I/O，从而增加读取延迟。缓存和智能分配策略可以缓解这一影响。虚拟机和数据库这类随机访问工作负载受影响较小，而媒体流和大文件传输等顺序型工作负载受影响更明显。下表总结了在生产环境中启用去重后的性能影响。

全局去重与本地去重、垃圾回收、压缩顺序

全局去重会在整个数据集范围内，跨所有节点和磁盘设备查找并移除重复数据；本地去重则仅限于单个节点或单个磁盘设备。去重覆盖的数据范围越大，效果通常越好。因此，在多节点环境中，如果每个节点都只执行本地去重，其效率通常低于整个集群范围的全局去重。Cohesity 指出，跨集群所有节点的全局去重，相比若干其他备份与恢复方案所采用的节点级去重，能够占用更少的存储空间。

对于生产级备份去重而言，可扩展性同样关键。ExaGrid 采用 GRID 架构，通过随着数据增长增加完整服务器来扩展能力。这种方式会同步增加内存、处理器、磁盘和带宽资源。而一些竞争对手采用前端服务器架构，只能通过增加磁盘柜来扩容，最终会导致备份窗口不断拉长，直到不得不进行成本高昂的整机替换升级。ExaGrid 的 GRID 方法能够随着数据增长维持固定长度的备份窗口，无需整机替换，也不会导致产品过时。ExaGrid 的分区级去重（zone-level deduplication）曾帮助 Concur 用 177 TB 磁盘空间存储近 3 PB 数据，展示了通过模块化容量增长与按需扩展实现的高性价比可扩展性。

垃圾回收（GC）用于回收孤立分块。当你删除某个备份，或者某个分块不再被任何对象引用时，这部分空间并不会立刻释放，只有在 GC 运行后才会真正回收。如果垃圾回收成功删除未使用分块，块存储的占用就会减少，卷上的可用空间也会增加。完整垃圾回收开销较大，通常以周期性任务运行。当发生了大量删除操作但空间仍未回收时，手动执行完整 GC 是合理的。在 Windows Server 中，去重过程中由完整 GC 引起的抖动可能带来性能问题。

垃圾回收与去重之间存在复杂互动。GC 有助于降低碎片，但如果某个原本“死亡”的区域中还保留了哪怕一个存活分块，区域级清理就无法释放整个区域。也就是说，去重引发的碎片化会阻碍回收。若仅依据指纹去重而缺乏时间局部性，文件数据就可能分散到大量数据块中，从而拖慢读取和恢复性能。启用字符串去重后，垃圾回收器的停顿时间也会更长。更高的 CPU 利用率，则是启用去重时垃圾回收周期中的主要代价。

压缩应在去重之后执行。在线去重完成后，可将压缩作为可选步骤进一步缩小已去重数据块的大小。这样的顺序能够最大化整体存储效率。下表展示了“去重后再压缩”与“不执行该顺序”之间的数据缩减比差异。

该表说明，当关闭备份软件自身压缩、转而让 VAST 对去重后的数据执行自身压缩时，缩减比可从 6:1 提升到 22:1。这进一步证明：先去重后压缩，能够带来显著额外收益。

加密兼容性同样值得关注。只要共享相同的加密上下文，ZFS 原生加密仍可与去重兼容。而上游应用层加密会将数据块随机化，使去重比接近 1:1。你的加密策略应与去重目标协同规划。

在备份中实施去重，能够降低存储成本并缩短备份窗口。本节介绍的这些技术，能够帮助你在生产规模下实现这些目标。建议先从试点数据集开始，测量结果后再迭代优化，最后再推广到更大规模。

监控压缩与去重效果

无法度量，就无法调优。对每个备份作业，你都应跟踪四项指标：去重比、压缩比、吞吐量以及索引命中率。去重比反映流水线移除了多少冗余数据；压缩比反映剩余唯一数据块被缩小了多少；吞吐量决定备份窗口是否仍在可接受范围内；索引命中率则显示查找已有分块的成功频率。若命中率持续下降，通常意味着数据发生了偏移，或分块策略出现问题。不要只看单次结果，而应持续观察这些指标的趋势。

测量去重比与吞吐量

去重比的计算方式是：逻辑字节数除以实际存储字节数。比如 10:1 表示你只存储了原始数据量的十分之一。吞吐量应在写入入口处以 MB/s 进行测量，而不是直接在磁盘层测量，这样能够将流水线本身的代价与存储延迟区分开来。应按作业和数据集分别采样这两项指标，单一的汇总数字往往会掩盖某一类工作负载中的问题。将结果与试点阶段建立的基线进行比较。如果吞吐量下降而去重比保持稳定，那么瓶颈通常位于索引或元数据层。

你的最终流水线应具备清晰的处理流程：先对数据流进行分块，再为每一块计算哈希，随后检查索引，只存储唯一数据，最后再对这些分块执行压缩。影响设计的关键权衡包括：

• 在线去重能够节省存储，但会拖慢数据写入；后处理写入更快，并在之后再进行去重，不影响写入速度。

• 固定分块实现简单；可变分块更能适应发生偏移的数据，从而获得更高的去重率。

• 全局去重覆盖所有节点，能带来更高的数据缩减率；本地去重范围更小，但索引开销也更低。

可先在试点数据集上测试 Windows Server 数据重复删除和 Veeam Backup & Replication，测量备份缩减比与吞吐量，并在全面部署服务器备份之前持续迭代。这样才能让备份去重真正适用于你的备份数据。

常见问题

在线去重和后处理去重有什么区别？

在线去重会在数据到达时立即处理，能够立刻节省存储空间，但可能降低写入速度。后处理去重则会先将完整备份写入服务器，再在后续阶段移除冗余。这样可以保持较高的备份速度，但会暂时额外占用磁盘空间。

为什么可变长度分块能改善去重效果？

可变长度分块根据内容模式而非固定位置来确定边界。一次小改动通常只会影响包含该改动的那个分块，其他分块仍能保留原有边界与哈希值。因此，这种方式在处理发生偏移的数据时，通常能获得更好的去重效果。

为什么压缩应该在去重之后执行？

对唯一数据块在去重后再执行压缩，能够最大化存储效率。每个唯一数据块都可以被单独压缩，而不会把算力浪费在最终会被丢弃的重复数据上。这个顺序能够避免无效压缩，并直接影响整体缩减比。

应跟踪哪些去重性能指标？

对每个服务器作业，应跟踪四项关键指标：去重比、压缩比、吞吐量和索引命中率。去重比显示流水线移除了多少冗余数据；吞吐量反映备份窗口是否仍然可接受。建议按作业分别监控这些指标。

加密会如何影响去重效果？

加密会使数据呈现随机化特征，从而让原本相同的数据块看起来彼此不同。应用层加密会破坏去重效果，因为即使来自相同源数据，加密后的密文通常也会表现为唯一内容。为了避免失去存储节省效果，你需要围绕备份数据合理规划加密策略。