在数据迁移、跨云同步与对象存储备份等场景中juicefs sync常用于执行大规模数据同步任务。当数据规模达到 TB 到 PB 级、对象数量达到数百万甚至数十亿级时单次任务执行周期通常会延长到数小时甚至数天。在这个过程中系统运行过程中通常会逐步暴露出以下几类问题任务在网络抖动、进程异常退出或节点重启后难以从一致状态继续执行往往需要重新扫描或重复处理数据备份场景可能存在明文暴露风险并可能面临合规与安全要求多个同步任务并发运行时带宽资源竞争明显整体传输过程缺乏有效的全局控制手段。围绕这些场景JuiceFS 1.4 在sync中提供了三项能力增强断点续传、数据加解密以及全局流量控制。本文将围绕这三项能力介绍其适用场景、实现机制和使用方式。01 断点续传在早期版本中用户同步过程中遇到错误或者中断重新执行任务时juicefs sync需要重新扫描源端和目标端再判断哪些对象已经完成、哪些对象仍需复制。对于上亿级对象或大量大文件场景仅重新扫描本身就可能带来显著的时间成本和对象存储请求开销。为了解决这一问题我们在 JuiceFS 1.4 中为sync引入了 断点续传机制。启用后sync会将任务进度保存到目标端。当任务中断后用户只需重新执行相同命令sync就会自动查找并加载与当前源端、目标端及关键参数匹配的 checkpoint从上次未完成的位置继续执行避免从头重新处理。工作原理启用 断点续传 后sync会在目标端保存一个 JSON 格式的状态文件文件名格式如下.juicefs-sync-checkpoint.hash.json其中hash由源端、目标端和关键同步参数计算得到用于确保当前任务只加载与自身匹配的 checkpoint避免不同同步任务之间误用状态文件。断点续传的运行流程如下图所示sync启动后首先在目标端查找与当前任务匹配的 checkpoint。如果找到匹配项则从上次保存的状态恢复执行如果未找到则按正常流程扫描并开始同步。sync 会并发遍历多个前缀每个前缀都有独立状态包括是否已完成遍历、上次遍历到的位置、待同步对象以及同步失败的对象。从 checkpoint 恢复时sync 会先从每个前缀中记录的待同步对象和失败对象重新加入任务队列对于上次尚未遍历完成的前缀则从记录的位置继续扫描并同步已经完成遍历的前缀只会继续处理 checkpoint 中尚未完成的对象。任务运行过程中sync会按设定间隔异步保存当前进度默认每 10 秒保存一次。任务正常完成后checkpoint 文件会被自动删除如果任务中断或失败则会保留下来供下次执行相同命令时继续恢复。在集群模式下checkpoint 只有一份由 Manager 统一维护。Worker 不直接读写目标端的 checkpoint 文件而是负责从 Manager 拉取任务、执行同步并回传结果。Manager 会将 Worker 回传的完成对象、失败对象、统计信息和 multipart 状态合并到全局 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 DST02 数据加解密在跨云备份和归档场景中客户端加密是常见的合规要求例如数据主权、静态数据保护、敏感数据迁移等。此前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 MiBoverhead取决于所使用的加密算法和密钥类型。这种设计的好处是随机读取时只需要根据偏移定位到对应的加密块并下载相关块数据不必读取整个文件。相应地加密后的对象会包含额外头部、填充和加密元数据因此目标端对象通常会比原始明文文件更大。支持的算法参数值对称算法密钥封装适用场景aes256gcm-rsa默认AES-256-GCMRSA通用场景chacha20-rsaChaCha20-Poly1305RSA对 AES 硬