新しい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をどのように計算するのかわかりません。
ベストアンサー1
Deja-Dup/Duplicityの組み合わせにより、バックアッププロセスが非常に遅くなることがわかります（実際には約156倍遅い）。
最終的にDeja-Dup / Duplicityバックアップを消去し、純粋なrsyncを使用しました。これでバックアップには15秒しかかかりません。
$ rsync -a --delete /home/tim /media/tim/BackupDrive/
あなたが本当に本当に本物Deja-Dupが提供する単純さやDuplicityが提供する機能が必要な場合は、まったく心配しないでください。 CPUサイクル、時間、電力を無駄にし、ドライブに不要な摩耗を加え、壊れやすい結果を生むだけです。サポート。デザダブ/二重性怖い単純に、あるローカルドライブから別のドライブにファイルをバックアップすることは非効率的です。
簡単で自動化された暗号化されていないローカルバックアップのために必要なのは、crontabにrsyncエントリを追加することだけです。