中断後にRsyncを再開すると、データが変更される可能性がある

中断後にRsyncを再開すると、データが変更される可能性がある

「Rsync」コマンドを使用して、ファイルシステムから nfs に大量のデータ (約 1Tera) を転送しました。

しばらくするとパソコンの電源が落ち、転送がキャンセルされました(600Gの転送に約10時間かかりました)。

アップロードされたファイルシステムの一部は、ユーザーによって変更/追加されています。部分的な転送を削除せずに Rsync を再度使用すると、転送されたファイルは無視され、変更された内容が再アップロードされるかどうかを知りたいです。

Ps Rsync を再開するオプションがある場合、転送されたファイルは最初にアップロードされたときよりもずっと早く無視されるのでしょうか? 600G を転送するのに 10 時間かかったので心配ですが、次の Rsync はもっと速くなることを願っています。

編集: どうやら回答にコメントできないようです...なので、@Kusalananda には を使用しましたrsync -rtzvx

答え1

オプションを使用しなかった-aため、ユーザーとグループの所有権も権限も保持されませんでした。ただし、 を使用したため、タイムスタンプは保持されました-t

ここで rsync を再起動すると、上記のメタデータを使用して、宛先のファイルがソースのファイルと同じかどうかを判断できなくなります。運が良ければ、 を使用できます。--size-onlyこれは、サイズが同じであればファイルが同一であると想定するように rsync に指示します。これは通常、ログファイルや写真などの場合にのみ正しく機能します。

しかし、状況はあなたが考えるほど悪くないかもしれません。rsync はソースと宛先の両方で各ファイルのチェックサムを計算し、チェックサムに違いが見られる場合にのみ、異なるブロックが転送されます。つまり、ファイル全体が再度転送されるのではなく、変更されたブロックのみが転送されます。これが rsync の強みです。つまり、ディスク IO の増加を犠牲にしてネットワーク帯域幅の使用を最適化します。

もちろん、これは rsync がネットワーク経由で別のホストに転送していることを前提としています。おっしゃる NFS ファイルシステムがローカルにマウントされている場合、rsync はファイルをチェックする際に実際にははるかに多くのネットワーク帯域幅を使用するため、おそらくこのためのツールではありません。また、rsync は--whole-fileローカル転送を行うときに モードに切り替わります。最初にソース ファイルと宛先ファイル全体をチェックしてから、ソースを宛先にコピーするのは無意味だからです。

一般的に、-a可能であれば を使用することをお勧めします。--numeric-idsソースと宛先に異なるユーザーがいる場合は と組み合わせる必要があるかもしれません。同じユーザーがいるが ID が異なる可能性がある場合は を使用しないでください--numeric-ids。rsync は名前に従って ID をマップします。

関連情報