我們使用 rsync 將主檔案伺服器的鏡像更新為異地託管備份伺服器。我們目前遇到的問題之一是，我們的檔案伺服器擁有> 1TB 的大部分較小檔案（在10-100kb 範圍內），當我們傳輸這麼多資料時，我們經常會在幾個小時後導致連接中斷。 Rsync 沒有恢復/重試功能，可以簡單地重新連接到伺服器以從上次中斷的位置繼續進行 - 您需要經歷文件比較過程，這最終會導致我們擁有的文件量變得非常長。
建議解決的解決方案是將大型 rsync 傳輸分成一系列較小的傳輸。我認為最好的方法是使用頂級目錄名稱的第一個字母，這並不能提供完全均勻的分佈，但已經足夠好了。
我想確認我的方法是否合理，或者是否有更簡單的方法來實現目標。
為此，我迭代 AZ、az、0-9 以選擇一個字元$prefix。最初我只想跑步
rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/
（--exclude“*.mp3”只是一個範例，因為我們有一個更長的排除清單來刪除臨時檔案等內容）
這樣做的問題是，dest/ 中不再存在於 src 上的任何頂級目錄將不會被 --delete 選取。為了解決這個問題，我嘗試以下方法：
rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/
我使用show和hide超過include和exclude，因為否則 --delete-excluded 將刪除與 $prefix 不匹配的任何內容。
這是將 rsync 分割成更小塊最有效的方法嗎？有沒有更有效的工具，或是我錯過的標誌，可以讓這件事變得更簡單？
答案1
我的解決方案是採用不同的兩遍方法，其中我犧牲了一些磁碟空間。我在伺服器上執行 rsync --only-write-batch ，然後將批次檔本身 rsync 到目標，循環直到 rsync 成功。一旦批次完全結束，目標上的 rsync --read-batch 就會重新建立所有變更。
這對我來說也有一些意想不到的好處：
因為我更關心備份“存在”而不是“可用”，所以我實際上並沒有每天在接收端執行批量讀取——大多數時候批量相對較小
我一直在嘗試使用 --checksum-seed=1 ...我可能會誤讀文檔，但我認為它使批處理文件更加可同步（即，當我不執行 --read-batch 任何操作時）給定的一天，第二天的批次同步速度更快，因為前一天的批次是一個很好的基礎）
如果批次太大而無法透過網路「及時」發送，我可以將其透過外部磁碟機進行網路傳輸。我所說的及時是指如果我無法在第二天的備份開始之前完成批次並進行讀取。
雖然我個人不這樣做，但我可以在不同的位置有兩個異地備份，並將批次發送給它們。
答案2
不完全回答你的問題，但我經常使用的另一個選項是以兩遍方法執行此操作：首先建立文件列表，然後拆分要傳輸的文件列表並將文件列表輸入 rsync/cpio/cp 等。
rsync --itemize-changes <rest of options>將列印要傳輸的文件清單以及一堆有用的元數據，從該輸出中可以輕鬆提取文件名，然後使用任一rsync --files-from工具或其他工具進行實際複製。
可能對您的情況有用 - 從中斷的傳輸中恢復會更快。
答案3
我建議您密切注意連接問題，而不是嘗試透過創建另一個“問題”來解決它。
這不是常見的行為。您是透過 SSH 還是 rsyncd 使用 rsync？
據我所知，大多數「關閉」連線發生在端點之間沒有資料傳輸時。