これは、rsync がすでに最新のファイルをコピーしようとするのはなぜですか?
--copy-devicesパッチを使用してrsyncディスク ドライブ全体をコピーし、別のマシンにイメージとして保存しようとしています。
コピーは正しく実行されたように見えますが、rsync同じ値で再度実行すると、毎回一部のデータが再度コピーされるようです。
rsync冗長性を高めて実行すると、次のようになりました。
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
rsync は時間によって変更を判断することは承知していますが、ディスクは rsync 間で変更されていません (そもそも、ディスクの変更時刻をどのように判断するのでしょうか?) ただし、リモート イメージの時刻は毎回更新されます。これが問題である可能性があります。
もう 1 つの可能性は、ディスクに不良セクタがあり、毎回異なる値が返され、使用されているチェックサムが無効になっていることです。
私の質問は2つあります:
イメージは正常に転送されましたか? 正常に転送された場合、再度実行するとディスクの大部分が再転送されるように見えるのはなぜですか? （これは私の付随的な質問の一部として部分的に答えられるかもしれないrsync 出力の「matches」、「hash_hits」、「false_alarms」とは何ですか? また、「data=0」は成功を意味しますか?）
これを適切に動作させるためのスイッチが欠けているのでしょうか? (多分
--checksum?) rsync アルゴリズムで使用されるブロックレベルの障害を一覧表示することは可能ですか?
答え1
デフォルトではrsyncはファイルをサイズとタイムスタンプで比較しますが、デバイスにはサイズがないので、ここで説明されているデルタアルゴリズムを使用して差異を計算する必要があります。技術レポート大まかに言うと、リモート ファイルは選択されたサイズのブロックに分割され、それらのチェックサムが送り返されます。ローカル ファイルも同様にブロック単位でチェックサムが計算され、リストと比較されます。次に、リモートに、ファイルを再作成するために必要なブロックを再構成する方法が伝えられ、一致しないブロックのデータが送信されます。
これは、オプション を使ってデルタサムアルゴリズムのレベル3のデバッグ出力を要求すればわかります--debug=deltasum3。ブロックサイズを指定して-B数値を簡略化できます。たとえば、すでに1回コピーされたファイルの場合、2回目の実行では
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
各ブロックのチェックサムを示す次のような出力を生成します。
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
違いがないので、他のデバイスのチェックサムと一致することが簡単にわかります。
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
最後にdata=フィールドは 0 になり、新しいデータが送信されなかったことを示します。
total: matches=164 hash_hits=164 false_alarms=0 data=0
ファイルの中央を上書きしてコピーを破損した場合:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
すると、rsync デバッグでブロック 80 の新しいチェックサムが表示されますが、一致するものはありません。一致 79 から一致 81 に進みます。
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
最後に、data=100000まったく新しいデータ ブロックを送信する必要があったことを示しています。
total: matches=163 hash_hits=385 false_alarms=0 data=100000
一致に失敗した破損ブロック チェックサムのため、一致数が 1 減少しました。連続一致が失われたため、ハッシュ ヒット数が増加した可能性があります。
見てみるとさらに遠く同じ技術レポートでは、いくつかのテスト結果が示されており、誤報 は、「32 ビットのローリング チェックサムが一致したが、強力なチェックサムが一致しなかった回数」として説明されます。各ブロックには、単純なチェックサムと md5 チェックサム (古いバージョンでは md4) が作成されます。単純なチェックサムは 32 ビットの整数であるため、ハッシュ テーブルを使用して簡単に検索できます。エントリが一致すると、より長い 16 バイトの md5 チェックサムも比較され、一致しない場合は誤報となり、検索が続行されます。
私の例では、16 MB の非常に小さい (古い) USB キー デバイスを使用しており、最小ハッシュ テーブル サイズは 2**16、つまり 65536 エントリなので、164 個のチャンク エントリを保持するとかなり空になります。多数の誤報は正常であり、他の何よりも効率の指標となります。
答え2
rsync --partial --inplace他のオプションと同様に の使用も検討してください。そうしないと、作業中に宛先側でディスク イメージの完全なコピーが作成されます。-B 4096これはデバイスの自然なセクター サイズであり、rsync のデフォルトのブロック サイズはこの種の操作には小さすぎるため、私も を使用しています。
イメージがすべて正しくコピーされたことを再確認するには、sha1sumソース側と宛先側の両方で個別に実行することをお勧めします。これは必須ではありませんが、確実にしたい場合は、簡単で信頼できます。ソース ディスクがライブ マウントなどではないと想定していますが、そうでない場合はすべてが台無しになり、送信する信頼できる方法はありません。