予想よりもはるかに長い時間がかかるローカルSSDへのバックアップ
新しいUbuntu18.04システムで、Deja-Dupを試してみることにしました。これは、Duplicity（rsyncを使用）の単なるGUIです。約850GBのデータをバックアップする必要がありました。ソースSSDはNVMeでした。宛先SSDはSATAでした。最初の（完全な）バックアップには約7時間かかりました。
翌日、Deja-Dupを再度実行する前に、メールをチェックしてアプリケーションをインストールするだけで、最大230MBが追加されました。
Deja-Dupは約39分間実行され、全期間にわたって35〜70％で単一のコアをロードしました。
重複は3回呼び出されました。
- スキャンフェーズでは、コアを100％で18分間ペグしました。
- バックアップフェーズでは、コアを100％で16分間ペッグしました。
- 検証フェーズでは、コアを100％で5分間ペグしました。
これは、十分なRAMを搭載した新しいコンピューター上にあります。バックアップは暗号化されていません。
さて、最初の（完全な）バックアップにはしばらく時間がかかると思いますが、それで問題ありません。私が期待していないことは、約230MBの新しいデータがバックアップされるのに約39分かかることです（そして、合計コア時間でCPU時間）。
何かが間違っているか壊れていますか？数百メガバイトの増分バックアップの実行にそれだけの時間がかかる必要がありますか？私は〜39ではなく5分未満の何かを期待していました。 なぜそんなに時間がかかるのですか？
（予備の1TB SATA SSDがある場合は、それを接続し、データを直接rsyncして、それが著しく高速かどうかを確認しますが、残念ながらそうではありません。）
更新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は、あるローカルドライブから別のローカルドライブにファイルをバックアップするだけの恐ろしく非効率的な方法です。
単純で自動化された暗号化されていないローカルバックアップの場合、必要なのはcrontabにrsyncエントリを追加することだけです。