数据迁移、跨云同步、对象存储备份——但凡跟大规模数据传输打过交道的人，大概都遇到过这类场景：TB到PB级的数据，几百万甚至上亿个对象，同步任务一跑就是几个小时甚至几天。运行过程中，各种问题也会陆续暴露出来——任务跑到一半，网络抖了一下、进程异常退出、节点重启，恢复起来简直要命，经常得重新扫描从头再来；数据备份的时候，明文状态下的暴露风险总是让人揪心，合规和安全的要求也越来越严；多个同步任务同时跑的时候，带宽互相抢，谁都没法好好干活。

这些问题其实并不新鲜。针对它们，JuiceFS 1.4 在 sync 中做了三项针对性的能力增强：断点续传、数据加解密，以及全局流量控制。下面就来逐一拆解，说说它们各自适用于什么场景、是怎么实现的、以及怎么用。

断点续传

早期版本的 juicefs sync 有一个比较让人头疼的问题：如果同步过程中间出了错、或者被人为中断，重新跑的时候它得从头扫描源端和目标端，把所有对象再过一遍，才能判断哪些已经完成、哪些还得再传。对上亿级别的对象或者大量大文件来说，光是重新扫描这一项，带来的时间成本和对象存储请求开销就已经相当可观。

其实解决思路并不复杂。JuiceFS 1.4 在 sync 里引入了断点续传机制：启用之后，sync 会把任务进度保存到目标端。哪天任务中断了，重新执行相同的命令，它会自动查找跟当前源端、目标端以及关键参数匹配的 checkpoint，从上一次没完成的地方继续往下走，不需要从头再来。

工作原理

启用断点续传后，sync 会在目标端保存一个 JSON 格式的状态文件，文件名长这样：

.juicefs-sync-checkpoint..json

这里的 hash 是根据源端、目标端以及关键同步参数算出来的，目的就是确保不同任务之间不会误用彼此的状态文件——相当于给每个任务配了一把专属钥匙。

整个流程大致如下：

• sync 启动后，先去目标端找匹配的 checkpoint。
• 找到就恢复执行，没找到就正常扫描、开始同步。注意，sync 会并发遍历多个前缀，每个前缀都有独立的状态记录：是否完成了遍历、上次遍历到哪了、哪些对象在等待同步、哪些同步失败了。
• 从 checkpoint 恢复的时候，sync 会先把每个前缀里记录的待同步对象和失败对象重新加入任务队列。对于上次还没遍历完成的前缀，从记录的位置接着扫；已经完成遍历的，就只处理 checkpoint 中没完成的对象。
• 运行过程中，sync 会按设定间隔异步保存当前进度，默认每 10 秒一次。
• 任务正常完成后，checkpoint 文件会被自动清理掉；如果中途中断或失败，文件保留下来，等下次执行时继续用。

在集群模式下，checkpoint 只有一份，由 Manager 统一维护。Worker 不直接读写目标端的 checkpoint 文件，而是从 Manager 拉取任务、执行同步并回传结果，Manager 再把这些信息合并到全局 checkpoint 中。

使用方式

# 启用断点续传
juicefs sync --enable-checkpoint SRC DST

# 自定义 checkpoint 保存间隔（默认 10s）
juicefs sync --enable-checkpoint --checkpoint-interval 30s SRC DST

# 忽略已有 checkpoint，强制从头同步
juicefs sync --enable-checkpoint --checkpoint-force-reset SRC DST

数据加解密

跨云备份和归档场景中，客户端加密越来越常见——数据主权、静态数据保护、敏感数据迁移，这些都是硬要求。以前 juicefs sync 没这个能力，用户想加密只能借助外部工具额外处理，流程上多了一层麻烦。

JuiceFS 1.4 把流式加解密能力直接集成到了 sync 流程里，数据同步的同时就能完成加密、解密或重新加密。主要支持三类场景：

• 加密写入：明文数据加密后写入目标端，适用于加密备份和归档。
• 解密恢复：从源端读加密数据，解密后写入目标端，适用于数据恢复或明文迁移。
• 重新加密：用旧密钥解密，再用新密钥加密后写入，适用于密钥轮换或加密算法迁移。

工作原理：分块流式加密

考虑到对象存储支持 Range GET，以及避免一次性加载大文件带来的高内存占用，sync 采用固定 1 MiB 分块的流式加密方案。每个文件先拆成多个明文块，再分别加密写入目标端。

原始文件结构大致是：

[chunk 1: 1 MiB] [chunk 2: 1 MiB] ... [chunk N: ≤1 MiB]

加密后，每个明文块对应一个加密块，由 4 字节头部和密文数据组成，其中的 4 字节头部用来记录该块的实际密文长度（ct_len）：

每个加密块： [4B ct_len][ciphertext + padding]

加密后的文件： [encrypted chunk 1] [encrypted chunk 2] ... [encrypted chunk N]

加密块的大小由明文块大小和加密开销共同决定，可以理解为 plainChunkSize + overhead。其中 plainChunkSize 固定为 1 MiB，overhead 取决于所使用的加密算法和密钥类型。

这种设计的好处是显而易见的：随机读取时只需要根据偏移定位到对应的加密块，下载相关块数据即可，不必读出整个文件。代价是加密后的对象会比原始明文文件略大一些，因为多了额外头部、填充和加密元数据。

支持的算法

使用方式

下面以 RSA 密钥为例，看看加密、解密和重新加密怎么用。

首先生成密钥对：

# 生成 RSA 私钥（公钥内嵌其中，JuiceFS 自动提取）
openssl genrsa -out private.pem 2048

# 带密码保护的私钥
openssl genrsa -aes256 -out private.pem 2048

场景一：加密写入目标端

juicefs sync /local/data s3://mybucket/backup --encrypt-rsa-key /path/to/private.pem

场景二：解密读取源端，用于数据恢复或明文迁移。

juicefs sync s3://mybucket/backup /local/data --decrypt-rsa-key /path/to/private.pem

场景三：重新加密，用于密钥轮换或算法迁移。

# 解密旧密钥加密的数据，用新密钥重新加密写入新存储
juicefs sync s3://old-bucket/encrypted s3://new-bucket/re-encrypted --decrypt-rsa-key /path/to/old-private.pem --encrypt-rsa-key /path/to/new-private.pem

如果私钥设置了密码，可以通过环境变量传入。

# 加密场景使用 JFS_ENCRYPT_RSA_PASSPHRASE
export JFS_ENCRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync /local/data s3://mybucket/backup --encrypt-rsa-key private.pem

# 解密场景使用 JFS_DECRYPT_RSA_PASSPHRASE
export JFS_DECRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync s3://mybucket/backup /local/data --decrypt-rsa-key private.pem

注意

• 加密后的数据采用 JuiceFS 私有格式存储，需通过 juicefs sync 并提供对应密钥进行解密读取。
• 加解密所用私钥请务必妥善备份——一旦丢失，已加密数据将无法解密访问。

全局流量控制

早期版本的 juicefs sync 已经支持通过 --bwlimit 对单个进程限速。但如果多个 sync 进程同时跑——比如分布式同步中的多个 Worker，或者几个独立同步任务共享同一条出口链路——单进程限速解决不了整体带宽的失控问题，出口带宽很容易被打满，其他业务流量跟着遭殃。

JuiceFS 1.4 新增了 --traffic-control-url 参数。简单来说，就是把多个 sync 进程接入同一个外部流量控制服务，由这个服务统一分配带宽配额，实现跨进程、跨任务的全局限速。

工作原理

全局流量控制采用的是令牌桶模型。多个 sync 进程在传输数据前，都向同一个流量控制服务申请字节配额：

每个 sync 进程在传输数据前，向控制服务申请一定数量的字节配额（credit）。控制服务根据当前总带宽使用情况，决定本次授予多少配额，以及配额的有效时间。配额用完后，sync 继续申请新的配额；如果配额即将过期但还有剩余，未使用的部分提前归还给服务。

控制服务通过 HTTP 接口提供配额申请和归还能力，接口需要用户自行实现或接入现有服务：

POST /traffic-control
Content-Type: application/json

请求：{"bytes": 1048576}
bytes > 0: 申请 bytes 字节的额度
bytes < 0: 归还 |bytes| 字节的未使用额度

响应：{"granted": 524288, "expired": 1000}
granted: 本次授予的字节数
expired: 额度有效期（毫秒）

同步过程中，sync 会在传输数据前向流量控制服务申请配额。如果当前没有可用配额，传输会阻塞等待，直到获得新的配额。这样一来，多个同步任务就可以共享同一个全局带宽上限，不会出现各自限速但总流量仍然失控的问题。

使用方式

# 先部署流量控制服务（示例：监听 8080 端口，限制总带宽 100 Mbps）
# （服务实现由用户自行决定，juicefs 只负责调用接口）

# 多个 sync 进程接入同一个控制服务
juicefs sync SRC1 DST1 --traffic-control-url https://127.0.0.1:8080/traffic-control &
juicefs sync SRC2 DST2 --traffic-control-url https://127.0.0.1:8080/traffic-control &

--traffic-control-url 和 --bwlimit 可以同时使用，两个限制独立生效：--bwlimit 控制单个进程的最大带宽，--traffic-control-url 控制所有进程的全局带宽。

# 单进程不超过 50 Mbps，同时所有进程合计不超过服务端配置的上限
juicefs sync SRC DST --bwlimit 50 --traffic-control-url https://controller:8080/traffic-control

小结

JuiceFS 1.4 对 sync 的这些增强，概括起来就三件事：断点续传让任务中断后的恢复成本大幅降低，数据加解密给备份安全加了把锁，全局流量控制让多个同步任务能更有序地共享带宽。对于数据迁移、跨云同步、对象存储备份和加密归档这些场景，用户完全可以根据自己的任务规模、网络环境和安全要求，灵活组合使用这些能力。没有银弹，但每个痛点都给出了实际的解法。