Duplicity：加密、带宽高效的备份

对 Duplicity 的总体看法

• 被视为一个扎实、长期存在的加密备份工具；有些人多年使用都没有问题。
• 主要技术批评：全量 + 增量模式会导致备份链很长、存储占用更大，并且需要定期重新做全量备份。
• 有些人觉得它 CPU 开销较大（例如 macOS 风扇狂转），效率也不如更新的方案。
• 还有人抱怨 cron 输出里 Python 警告很多；也有人提到较旧的安装可能仍在使用 Python 2。
• 报告的问题：当某个后端失败时（例如 SFTP 的 IPv6 路由问题），即使设置了“出错继续”，Duplicity 也可能直接中止。
• 关于恢复语义的提醒：如果目标目录指定不当，可能会直接覆盖它，而不是恢复到其中。
• 提到的前端：Duply 和 DejaDup（带实验性的 Restic 后端）。

与其他备份工具的比较

• 许多评论者已经从 Duplicity 迁移到 Borg、Restic、Kopia 或 Duplicacy。
• Borg：因去重、快速频繁快照、便于恢复的 FUSE 挂载、清理策略以及小型仓库而受到称赞；批评点包括多个主机同时使用同一仓库比较困难。
• Restic：因单一可执行文件带来的简洁性、FUSE 挂载、支持“朴素”的远程后端（S3、SFTP）以及对加密数据进行去重+压缩而受欢迎。有些人报告内存占用更高、性能问题，以及如秒级时间戳粒度等怪癖。
• Kopia：基于内容寻址，支持去重、zstd 压缩和复杂的忽略规则；有人早先担心仓库大小会“膨胀”，但也有人认为它与 Borg 不相上下。
• Duplicacy：被认为适合多机器、单仓库设置，并且便于复制到云端，表现可靠。
• Duplicati：有多条反馈称其在中等规模仓库上的恢复极其缓慢，甚至实际上失败。

云存储与 S3 策略

• 有人提议用简单的 aws s3 sync shell 脚本作为替代，但其他人指出：
  • 它只是镜像，而不是维护结构化的备份历史，除非启用了 S3 版本控制。
  • 没有块级差异或去重；大文件的重命名/移动代价很高。
  • 服务端加密不是端到端；Borg/Restic/duplicity 提供的客户端加密和去重被认为更强。

基于内容寻址与去重的设计

• 基于内容的 ID 和滚动哈希（如 Kopia、Borg、Restic 所采用）能够实现：
  • 跨主机去重。
  • “完整”的逻辑快照，而无需定期全量备份，因为数据块是共享的并会被垃圾回收。
• 提出的担忧：
  • 数据块共享意味着某个数据块损坏会影响所有引用它的快照；建议通过冗余（RAID、纠删码）和定期校验来缓解。
  • 这类设计可能泄露元数据以及部分文件相似性信息，因此极度谨慎的用户可能更偏好简单的 tar/zip 加整档加密。

易用性、GUI 与编排

• Borg 拥有成熟的 GUI 和编排工具（例如 Vorta、Pika Backup、borgmatic）。
• Restic 的生态更为碎片化：存在多个包装器（autorestic、resticprofile、Backrest、npbackup、Prestic），成熟度不一，因此更难选择，尤其对非技术用户和 macOS 支持而言。

数据完整性与备份测试

• 强调不仅要创建备份，还要 नियमित地测试备份。
• 对 Borg，建议通过 cron 运行 borg check --verify-data，并偶尔手动恢复（例如恢复到 VM 中）以确认端到端恢复。
• 一些工具提供仓库检查和随机子集验证；检测损坏、加上冗余和异地副本，被认为是最佳实践。

其他警告与建议

• 明确警告不要使用 rdiff-backup，原因是有人报告其在 ENOSPC 处理、复杂的“regress”操作，以及涉及大量反向差异的低效恢复方面存在问题。
• 多位评论者推荐 restic + rclone 或 Kopia，作为现代、稳定、加密、去重的方案，适合云后端和大数据集。