重複はバックアップ時に変更されますか？
私のデータはSSDにあり、—リライトと ライトアンプリフィケーション のおかげで— atimeを変更すると、iノードだけでなく、それが存在するブロック全体が消去され、書き直しました。つまり、ドライブに大量の不要な摩耗が発生するため、明らかに望ましくありません。
Duplicityがファイルをバックアップするとき、ソースファイルのatime属性を変更しますか？ -） 過程の中で？
それがatimeを変更する場合、初期（完全）バックアップ、増分バックアップ、またはその両方で変更しますか？
答えはyesになりました。重複は、最初のバックアッププロセス中にすべてのファイルのiノードの時間を変更します。これにより、大量のSSDの再書き込みと書き込みの増幅がトリガーされます。
後続の（増分）バックアップでは、はるかに少ない（ただし、かなりの数の）iノード（およびもちろん変更されたファイル）が再書き込みされます。
重複は、ファイルの時間を保持しようとはしません。
公平を期すために、Duplicityがこの問題に取り組む方法は非常に一般的であり、HDDに特に大きな負担をかけることはありません。リライトとライトアンプリフィケーションの問題は、具体的にはSSDの問題です。つまり、Duplicityについて言えることは、SSD向けに最適化されていないことと、Duplicityを使用すると（他のすべての条件が同じであれば）HDDよりもSSDが早く消耗することです。
コメントでfrostschutzが指摘しているように、この問題は、ファイルシステムをnoatime設定でマウントすることで解決できるため、比較的簡単に軽減できます。
HDDが消滅し、SSDが引き継ぐにつれて、ファイルシステムはSSD向けにますます最適化され、時間の変更、再書き込み、および書き込み増幅によって引き起こされる摩耗/パフォーマンスの問題に対処することが期待できます。 F2FS のような新しいファイルシステムが例を挙げています。
いいえ、ソフトウェアアプリケーションがファイルのatimeを変更すると言うのは誤りです。ユーザーモードプログラムには、atimeが更新されるかどうかを制御する方法がほとんどありません。これは、オペレーティングシステム、より具体的には filesystem ドライバーの責任です。さらに、Linuxの現在のデフォルトのマウントオプションはタイムスタンプの更新を最小限に抑えるため、パフォーマンスや寿命にほとんど影響を与えません ssd 。
最新の linux ディストリビューションの現在の状況は次のとおりです。
- マウントオプション
noatimeを使用すると、atimeメタデータを維持することで提供されるユーティリティを犠牲にして、atimeの更新が完全に排除されます。 - デフォルトの
relatimeオプションは、問題を最小限に抑えます - 最近導入されたオプションである
lazytimeは、タイムスタンプの更新によるSSDの寿命への残りの影響を完全に排除するはずです。