[Feature] 传统打包上传备份方式已经落后

[lirko]

看得出作者很用心,但现代就需要适合现代技术,打包上传属于落后技术

请参考下kopia底层原理的现代化CDC备份方案:
文件分块扔进全局分块池,避免重复无效上传,去重增量
目前AI时代早就不需要这样传统方案了

[Awuqing]

Great idea! I’ll try to do it in the future!

[Awuqing]

感谢 @lirko 的建议 👍 这个方向我认同，下面把它从"想法"落成一份可执行的技术方案，既讲清 kopia/restic 的底层原理，也结合 BackupX 现状给出分阶段路线图和真实代价——避免把去重说成"银弹"。

一、先盘点 BackupX 现状（要改的是什么）

当前文件备份是**"打包 + 整体上传"**模型（server/internal/backup/）：

• FileRunner.Run() 遍历源路径 → 写出单个 tar 归档（archive.go，可选 gzip/zstd 整体压缩）→ 经 storage 层（rclone，70+ 后端）整体上传为一个对象。
• 加密是对整包 AES‑256‑GCM（storage/codec）。
• 所谓"差异备份"（feat(backup): 新增差异备份（differential）模式 #88）是基于 manifest.go 的 文件级 比对：用 {path, size, mtime} 清单判断"自上次全量以来谁变了"，只打包变更项 + 记录删除列表。它不是块级去重。

这套方案的局限正是 @lirko 指出的：

1. 同一文件改一个字节 → 整文件（甚至整包）重传；
2. 跨文件、跨快照没有去重（两个任务备份了同一份大文件 = 存两份）；
3. 差异链依赖 mtime/size 启发式，且差异恢复要"全量铺底 + 差异覆盖"，链路越长越脆。

二、CDC + 全局分块池到底是怎么工作的

把 kopia/restic 的核心机制讲准（我对照了两者的源码与设计文档）：

1) 内容定义分块（Content‑Defined Chunking）
滑动窗口 + 滚动哈希逐字节扫描，当 hash & mask == 0 时切一刀。切点只取决于局部窗口内容，所以边界"跟着内容走"而非跟着文件偏移走。

	restic	kopia（默认）
算法	Rabin 指纹（多项式，开库时随机选 degree‑53 多项式防指纹攻击）	DYNAMIC-4M-BUZHASH（buzhash32）
窗口	64 B	64 B
块大小	min 512 KiB / avg ~1 MiB（20‑bit mask）/ max 8 MiB	min 2 MiB / avg 4 MiB / max 8 MiB

还有更现代的 FastCDC（USENIX ATC'16）：Gear‑hash + cut‑point skipping + normalized chunking，比开源 Rabin 快约一个数量级，去重率几乎不变。Go 生态有成熟库，新项目我更倾向它。

2) 内容寻址 = 天然去重
每个块的 ID = 其内容的密码学哈希（restic：明文 SHA‑256；kopia：BLAKE2b‑256 keyed/HMAC，用库密钥加盐，16 B）。相同内容 → 相同 ID → 只存一份。这就是"全局分块池"：跨文件、跨快照、跨主机自动去重。

3) 为什么它碾压定长块和"tar+上传"——插入问题
在文件头部插入 1 个字节：定长分块会让其后所有块边界整体平移 → 每个块哈希都变 → 去重率归零；CDC 会在下一个内容边界处"重新同步"，改动点之后的块仍然字节相同 → 照常命中。这是 CDC 的全部价值所在。

4) 必须打包（packing）
~1 MiB 的块在对象存储上会变成海量小对象（S3/OSS 按请求计费、有限流）。所以两者都把许多块打包成大 blob 再上传：restic 16 MiB/pack，kopia 20–40 MB/pack，另配独立索引（blobID → pack/offset/len）。

5) 快照即增量（这正好回应"不要传统全量/差异"）
快照是一棵 Merkle/DAG：snapshot → root tree → 子树/文件 → 数据块，全部按内容哈希寻址。未变的子树 ID 不变 → 自动复用、零重传。restic 因此根本没有 full/incremental/differential 之分——每次备份天然就是增量，parent 快照只是"跳过重新分块"的性能提示，不影响正确性。

6) 加密与去重的顺序
先按明文哈希去重，再压缩、再加密（encrypt‑after‑dedup）。restic 单 master key、库内去重；kopia 用 HMAC(contentID) 派生每块密钥 + 随机 nonce。代价：去重只在同一仓库/同一密钥内有效，跨库 copy 要解密重传。

三、落到 BackupX 的具体设计

不推翻现有架构，新增一种**"仓库模式（repository / chunk‑store）"** 的备份类型，与现有 tar 模式并存：

<storage-target>/                # 落在任意现有 rclone 后端
  config                         # 仓库参数（splitter/hash/加密算法、版本）
  keys/                          # 口令包裹的 master key（scrypt）
  data/<aa>/<pack>               # 打包后的块（两位哈希前缀分片，避免巨型目录）
  index/                         # blobID -> {pack, offset, len}
  snapshots/                     # 每次备份一个 snapshot（指向 root tree）

关键复用点（都已存在于本仓库）：

• 存储抽象：仓库格式只依赖 Put/Get/List/Delete + Range 读，正好套用现有 storage.Registry + rclone provider → 一次实现，70+ 后端通吃（但要逐后端验证 Range 读 / List 成本差异）。
• 去重索引：用项目已内嵌的 GORM + SQLite 维护 blobID → 位置，兼顾去重查询与恢复定位，契合"单二进制 + 内嵌 SQLite"理念。
• 压缩/加密：per‑chunk 复用现有 zstd（feat(backup): 新增 zstd 压缩选项 #89）；per‑pack/per‑chunk 复用 codec 的 AES‑256‑GCM。
• 内容浏览 / 选择性恢复：feat(backup): 新增备份内容浏览 #90 的内容浏览、feat(backup): 新增按需（选择性）文件恢复 #91 的按需恢复 UI 可直接对接快照树。

四、必须正视的代价（去重不是免费的）

1. GC/prune 很贵：块被多个快照共享，不能再用对象存储 lifecycle 直接删。只能 forget（解除快照引用）+ prune（可达性分析 + 把"半空" pack 下载→重打包→上传）。大库很慢，且对象存储要付出出口流量。这会与现有"按天/数量 + 空目录清理"的 retention 冲突，需要重新设计。
2. 索引随唯一块数增长：内存/体积都涨，备份和 prune 时都要可快速查询。
3. 恢复 = 多 pack 随机读（vs 现在顺序解 tar）→ 需本地 cache 缓解读放大。
4. 多节点一致性：Master‑Agent 直传模式下，每个仓库的去重索引需单写者或汇总机制，初期建议限定单写者。
5. 安全权衡：内容寻址会泄露"块是否相同"的结构信息（参见 2025 年 Breaking and Fixing Content‑Defined Chunking，我尚未细读，先标注）。

五、分阶段路线图

• P0 设计 + 选型：定 splitter（建议 FastCDC，avg 1 MiB 起步）、hash、加密、仓库格式版本号；写设计文档。
• P1 写路径 PoC：chunk → 去重 → zstd → AES‑GCM → pack → SQLite 索引，先打通 local 后端 + 一个对象存储，验证**"二次备份近乎零上传"**。
• P2 快照 + 恢复：tree DAG、Range 读拼装、本地 cache；对接 feat(backup): 新增备份内容浏览 #90/feat(backup): 新增按需（选择性）文件恢复 #91 的浏览与按需恢复。
• P3 forget + prune：mark‑sweep + repack，并入 retention。
• P4 工程化：多节点一致性、并发、逐后端验证、Prometheus 指标（去重率 / pack 数 / prune 时长）。

六、几点技术上的诚实补充

• 这套思路（内容寻址去重）其实源自 2000 年代的 LBFS，被 restic/kopia/borg 工程化多年，和 AI 无关——但它确实比"打包上传"更现代、收益明确，值得做。
• 建议两种模式并存、灰度切换：大量小改动/频繁备份 → CDC 去重收益巨大；一次性归档/冷备 → tar 更简单可靠。让用户按场景选，风险可控。

这块工作量不小（尤其 prune 与多节点一致性），会作为中长期 roadmap 推进。欢迎 @lirko 和各位继续就选型（FastCDC vs Rabin）、索引存储、prune 策略拍砖。🙏