备份这件事，做过的人都懂——数据量越来越大，备份窗口越来越紧，存储成本越来越高。一次全量备份动辄几百GB，如果每天跑一次，磁盘很快就被撑爆。更头疼的是，备份过程中大量重复数据被反复传输和存储，浪费了带宽、磁盘和时间。

解决这个问题的核心思路只有两个：去重和压缩。前者消除冗余，后者缩小体积。两者结合，能让备份效率提升数倍。

数据去重：只存变化的部分

去重的逻辑很简单：同一份数据，无论出现多少次，只存一份。但在实现层面，它分为两个层级。

文件级去重是最基础的形态。如果两个文件的哈希值完全相同，就只保留一个副本。这种方式实现简单，但对“文件内部有微小改动”的场景无能为力——改一个字符，整个文件就会被当作新文件重新存储。

块级去重才是真正高效的方式。它把文件切分成固定大小或可变大小的数据块，以块为单位计算哈希。只有内容发生变化的块才会被重新存储，其余块直接引用已有副本。Restic、Borg 这类现代备份工具都采用块级去重，备份一个 10GB 的虚拟机镜像，如果只改了 100MB 的内容，实际新增存储可能不到 100MB。

块级去重的另一个优势是跨文件去重。多个虚拟机镜像、多个数据库导出文件之间如果有相同的系统文件或公共数据，这些块只会在第一次出现时被存储。对于运行多台相似服务器的场景，去重率可以达到 5:1 甚至 10:1。

数据压缩：用 CPU 换空间和带宽

去重解决了“重复存”的问题，压缩解决的是“存得小”的问题。两者叠加，效果是乘法关系。

选择压缩算法时，需要在压缩比、压缩速度和 CPU 消耗之间找平衡。Gzip 是通用选择，兼容性好，压缩比中规中矩。Bzip2 压缩比更高，但速度慢得让人着急，不适合高频备份。Lz4 速度极快，但压缩比一般，适合对备份窗口要求苛刻的场景。

Zstandard（zstd）是当前最值得推荐的方案。它的压缩速度是 gzip 的 3-5 倍，解压速度更是 gzip 的 10 倍以上，同时压缩比还略优于 gzip。更关键的是，zstd 支持多级压缩比调节——`-3` 档速度优先，`-19` 档压缩比优先，可以根据备份窗口灵活选择。

在备份工具中启用压缩通常只需要一个参数。Restic 默认使用 zstd 压缩，Borg 也支持 lz4、zstd、zlib 等多种算法。如果使用 tar 手动打包，可以这样组合：

tar -cf - /data | zstd -T4 -3 > backup.tar.zst

`-T4` 启用 4 个线程并行压缩，`-3` 选择速度优先档位。这个组合在多数场景下能在几分钟内完成几十 GB 数据的压缩，同时将体积缩小到原来的 30%-50%。

实战：去重 + 压缩的备份组合

以 Restic 为例，一条命令同时完成去重和压缩：

restic -r sftp:user@backup-server:/backup backup /data --compression max

Restic 会自动将数据切块、去重、压缩，然后传输到远端仓库。第二次备份时，只有新增或变化的块会被上传，其余块直接从本地缓存引用。增量备份的速度极快，对带宽的消耗也极小。

如果使用 Borg，命令同样简洁：

borg create --compression zstd,10 /backup::archive-{now} /data

`--compression zstd,10` 指定使用 zstd 算法，压缩级别 10。Borg 的块级去重机制会自动处理重复数据，备份仓库的体积通常只有原始数据的几分之一。

硬件基础：为什么服务器性能决定了备份上限

去重和压缩都是 CPU 密集型操作，同时对磁盘 I/O 有较高要求。块级去重需要频繁读取数据块并计算哈希，压缩需要大量 CPU 周期。如果服务器 CPU 性能不足，压缩过程会拖慢整个备份流程；如果磁盘 IOPS 不够，读取数据块就会成为瓶颈。

Jtti 的云服务器方案在备份场景下提供了匹配的硬件基础。全系标配企业级 NVMe SSD，4K 随机读写 IOPS 远超普通 SATA SSD，块级去重时读取和哈希计算的响应速度更快。高性能 CPU 让 zstd 多线程压缩能充分并行，缩短备份窗口。独享带宽确保备份数据上传到远端存储时不会因为“邻居抢带宽”而超时中断。对于需要跨地域备份的场景，Jtti 香港及美国节点接入 CN2 GIA 精品线路，从国内管理备份任务、传输备份数据的体验流畅稳定。

续费同价政策确保首购价格就是续费价格，对于需要长期运行备份任务的业务，成本可预期。

去重和压缩不是“锦上添花”，而是备份方案能否长期运行的关键。 没有去重，备份存储会线性膨胀；没有压缩，备份窗口会被无限拉长。两者结合，再加上一台底子扎实的服务器，才能让备份这件事真正“跑得动、存得下、恢复得了”。