在一个全新的 Ubuntu 18.04 系统上，我决定试一试 Deja-Dup。它只是 Duplicity 的 GUI（使用 rsync）。大约需要备份 850GB 的数据。源 SSD 是 NVMe。目标 SSD 是 SATA。初始（完整）备份大约需要 7 个小时。
第二天，在再次运行 Deja-Dup 之前，我只检查了邮件并安装了一个应用程序（增加了大约 230MB）。
Deja-Dup 运行了约 39 分钟，在整个持续时间内以 35–70% 的速度加载单个内核。
Duplicity 被调用了 3 次：
- 扫描阶段将核心以 100% 的速度固定 18 分钟。
- 备份阶段将核心以 100% 的速度固定 16 分钟。
- 验证阶段将核心以 100% 的速度固定 5 分钟。
这是在具有大量 RAM 的新计算机上。备份未加密。
现在，我预计初始（完整）备份需要一段时间，这很好。我没想到的是，大约 230MB 的新数据需要大约 39 分钟的时间来备份（并消耗超过一个核心小时的 CPU 时间）。
有什么问题或损坏了吗？几百兆字节的增量备份是否应该花费那么多时间来执行？ 我期待不到 5 分钟，而不是 39 分钟。 为什么需要这么长时间？
（如果我有一个备用的 1TB SATA SSD，我会把它连接起来，然后直接同步数据，看看是否明显更快——但不幸的是我没有。）
更新 1：在微不足道的更改（几 KB 的新邮件）之后，我运行了手动备份，所用时间相同（约 39 分钟）。因此，所花费的时间似乎与需要备份的新数据量无关。
更新 2：使用 iotop 监控显示扫描阶段从驱动器读取 7.36GB。现在这显然不是整个 850GB……但是如果将源驱动器上的文件数 (1174000) 乘以块/集群大小 (4096) 即 4.81GB，它与您得到的数字相差不远。如果是这种情况，不确定如何计算剩余的 2.5GB。
我可以确认 Deja-Dup/Duplicity 组合只会使备份过程非常缓慢（实际上慢了约 156 倍）。
我最终擦除了 Deja-Dup/Duplicity 备份，只使用了纯 rsync。备份现在只需 15 秒。
除非你真的、真的、真的需要 Deja-Dup 提供的简单性或 Duplicity 提供的功能，否则你甚至都不会打扰——你只是在浪费 CPU 周期、时间、电力，导致驱动器不必要的磨损，然后你就结束了加上脆弱的备份。Deja-Dup/Duplicity 是一种将文件从一个本地驱动器简单地备份到另一个驱动器的极其低效的方法。
对于简单的、自动化的、未加密的本地备份，您只需将 rsync 条目添加到您的 crontab。