備份到本地 SSD 花費的時間比預期的要長
在一個全新的 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 秒。
$ rsync -a --delete /home/tim /media/tim/BackupDrive/除非你真的、真的、真的需要 Deja-Dup 提供的簡單性或 Duplicity 提供的功能，否則你甚至都不會打擾——你只是在浪費 CPU 週期、時間、電力，導致驅動器不必要的磨損，然後你就結束了加上脆弱的備份。Deja-Dup/Duplicity 是一種將文件從一個本地驅動器簡單地備份到另一個驅動器的極其低效的方法。
對於簡單的、自動化的、未加密的本地備份，您只需將 rsync 條目添加到您的 crontab。