在新的 Ubuntu 18.04 系统上，我决定尝试一下 Deja-Dup。它只是 Duplicity 的 GUI（使用 rsync）。需要备份大约850GB的数据。源 SSD 是 NVMe。目标 SSD 是 SATA。初始（完整）备份大约需要 7 小时。
第二天，我什么也没做，只是检查邮件并安装一个应用程序（增加了约 230MB），然后再次运行 Deja-Dup。
Deja-Dup 在整个持续时间内以 35-70% 的负载运行约 39 分钟。
口是心非被调用了三次：
- 扫描阶段将核心固定在 100%，持续 18 分钟。
- 备份阶段将核心固定在 100%，持续 16 分钟。
- 验证阶段将核心固定在 100%，持续 5 分钟。
这是在一台具有充足 RAM 的新计算机上进行的。备份是不是加密的。
现在，我预计初始（完整）备份需要一段时间，这很好。我什么不预期约 230MB 的新数据需要约 39 分钟的时间来备份（并消耗超过一个集体核心小时的 CPU 时间）。
是不是出了什么问题？几百兆的增量备份需要花那么多时间吗？ 我原本预计时间不会超过 5 分钟，而不是 39 分钟。 为什么要花这么长时间？
（如果我有一个备用的 1TB SATA SSD，我会将其连接起来并直接 rsync 数据，看看是否明显更快 - 但不幸的是我没有。）
更新 1：我在进行了可忽略不计的更改（几 KB 的新邮件）后运行了手动备份，并且所花费的时间是相同的（约 39 分钟）。因此，所花费的时间似乎与需要备份的新数据量关系不大。
更新 2：使用 iotop 进行监控显示扫描阶段从驱动器读取了 7.36GB。现在这显然不是整个 850GB...但如果将源驱动器上的文件数量 (1174000) 乘以块/簇大小 (4096)，即 4.81GB，则与所得数字相去不远。如果是这样的话，不知道如何计算剩余的 2.5GB。
答案1
我可以确认 Deja-Dup/Duplicity 组合只会使备份过程变得非常缓慢（实际上慢了约 156 倍）。
我最终擦除了 Deja-Dup/Duplicity 备份，只使用纯 rsync。现在备份仅需 15 秒。
$ rsync -a --delete /home/tim /media/tim/BackupDrive/
除非你真的真的真的如果您需要 Deja-Dup 提供的简单性或 Duplicity 提供的功能，那么根本不用担心 — 您只是在浪费 CPU 周期、时间、电力，对驱动器造成不必要的磨损，最终会得到一个脆弱的备份。 Deja-Dup/口是心非是可怕地简单地将文件从一个本地驱动器备份到另一个本地驱动器的效率低下。
对于简单、自动化、未加密的本地备份，您所需要做的就是向 crontab 添加一个 rsync 条目。