這是一個擴展為什麼 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 之間沒有更改（它如何確定磁碟的修改時間？）但是，遠端映像上的時間每次都會更新。所以這可能是問題所在。
另一種可能性是磁碟有一個壞磁區，每次傳回不同的值並否定正在使用的任何校驗和。
我的問題有兩個：
我的映像是否已成功傳輸？ （這也可以作為我的推論問題的一部分得到部分回答rsync 輸出中的「matches」、「hash_hits」和「false_alarms」是什麼，「data=0」是否意味著成功？）
我是否缺少一個開關來使其正常工作？ （也許
--checksum？）是否可以列出 rsync 演算法使用的區塊級故障？
答案1
預設情況下，rsync 按大小和時間戳來比較文件，但設備沒有大小，因此必須使用 delta 演算法來計算差異，這在本節中進行了描述。技術報告。鬆散地，遠端檔案被分成選定大小的區塊，並且這些區塊的校驗和被發回。本機檔案同樣以區塊為單位進行校驗和，並與清單進行比較。然後，遠端設備被告知如何重新組裝它必須重新製作文件的區塊，並且發送不匹配的區塊的資料。
您可以透過僅針對帶有選項的 deltasum 演算法在等級 3 中請求偵錯輸出來看到這一點--debug=deltasum3。您可以指定區塊大小以-B簡化數字。例如，對於已經複製過一次的文件，第二次運行
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 校驗和，如果不符合則誤報，繼續搜尋。
我的範例使用一個非常小的（且舊的）16MB 的USB 金鑰設備，最小雜湊表大小為2**16，即65536 個條目，因此當保存我擁有的164 個區塊條目時，它非常空。如此多的誤報是正常的，而且比其他任何事情都更能表明效率。
答案2
您需要考慮使用rsync --partial --inplace以及其他選項，因為否則它將在工作時在目標端製作光碟映像的完整副本。我也一直在使用，-B 4096因為它是設備的自然扇區大小，而 rsync 預設區塊大小對於此類操作來說太小了。
為了再次檢查影像是否全部正確複製，我建議sha1sum在來源端和目標端都進行獨立的操作。這應該不是必需的，但如果您想確定的話，這很簡單並且您可以信任它。我假設您的來源磁碟不是即時安裝或類似的東西，否則所有的賭注都會被取消，並且沒有可靠的方法來發送它。