ローカルSSDへのバックアップに予想以上に時間がかかる

新しいUbuntu 18.04システムでDeja-Dupを試すことにしました。これはDuplicity（rsyncを使用）のためのGUIです。約850 GBのデータをバックアップする必要があります。ソースSSDはNVMeです。ターゲットSSDはSATAです。初期（フル）バックアップには約7時間かかります。

翌日、私はメールを確認し、アプリ（約230MBを追加）をインストールしてからDeja-Dupを再実行する以外は何もしませんでした。

Deja-Dupは、全期間にわたって35〜70％の負荷で約39分間実行されました。

二重性は3回呼び出されます。

• スキャンステップはコアを100％に固定し、18分間持続します。
• バックアップフェーズでは、コアを16分間100％に固定します。
• 確認ステップでは、コアを5分間100％に変更します。

これは十分なRAMを持つ新しいコンピュータで行われました。バックアップはいいえ暗号化されました。

これで、初期（フル）バックアップには時間がかかると予想されます。私は何ですか？いいえ約230MBの新しいデータをバックアップするのに約39分かかります（そして合計1時間以上のCPU時間を費やします）。

何かが間違っていますか？何百メガバイトの増分バックアップにはそれほど時間がかかりますか？ 39分ではなく5分を超えないと予想しました。 なぜこれほど時間がかかるのですか？

（余分な1TB SATA SSDがある場合は、それを接続してデータを直接再同期してはるかに高速であることを確認しますが、残念ながらそうではありません。）

アップデート1：無視できる変更（数KBの新しいメール）を実行した後に手動バックアップを実行しましたが、費やされた時間は同じでした（〜39分）。したがって、かかる時間は、バックアップする必要がある新しいデータの量とほとんど関係がないようです。

アップデート2：iotopで監視すると、スキャンステップ中にドライブから7.36 GBを読み取ったように見えます。これで、850 GB というわけではありませんが、ソース・ドライブのファイル数 (1174000) にブロック/クラスター・サイズ (4096)、つまり 4.81 GB を掛けても、結果の数値とは大きく変わりません。それでは、残りの2.5GBをどのように計算するのかわかりません。