Rsync 跨 WAN 很慢？先找瓶頸的調校指南
拆解掃描、變更判斷、SSH、壓縮、磁碟與小檔案瓶頸，建立可重現的 rsync WAN 測試。
Rsync 跨站複製很慢，可能在資料開始傳送前就已花掉大部分時間。大量目錄掃描與檔案比對，和網路傳送不足，需要不同的調整方式。
先記錄多久才開始傳送內容，再比較一個大檔與一份真實資料夾的完整耗時。搭配兩端 CPU、磁碟與網路紀錄，便能逐步確認時間花在掃描、差異計算、SSH 傳輸還是目的端寫入。
先建立基準
先預覽 rsync 認為會變更的項目：
rsync -a --dry-run --itemize-changes source/ user@example.com:/data/destination/再跑正式測試：
rsync -a --info=progress2 --stats source/ user@example.com:/data/destination/記錄「多久才開始送有效資料」、檢查與實際傳送的檔案數、實際傳送／比對相符資料、兩端 CPU、來源讀取、目的寫入，以及端到端總耗時。Rsync 預設以大小與修改時間做快速檢查，現代版本還會增量遞迴；但百萬檔案仍需大量檔案系統工作。官方行為以 rsync man page為準。
1. 不要把 --checksum 當成通用加速或安全開關
--checksum 會在判斷變更時讀取兩端檔案內容，可能在傳輸前就造成大量磁碟 I/O。它與接收端對已傳輸內容的重建驗證不同。只有檔案內容可能改變、但大小與修改時間仍相同時才使用，並先獨立量測掃描時間。
2. 用一個工作階段與範圍明確的清單
不要用 Shell 迴圈每個檔案啟動一次 rsync，否則會重複 SSH、程序、清單交換與 WAN 延遲。若上游已知精確變更路徑，可測試排序後的 --files-from：
rsync -a -r --files-from=changed-files.txt source/ user@example.com:/data/destination/使用 --files-from 時，-a 不會自動包含 recursion，所以需要時加 -r。先用 --dry-run 驗證；若清單不完整，就不能拿它做完整變更發現。
--delete-before、--delete-after、--prune-empty-dirs、--delay-updates 等選項可能要求完整檔案清單並停用增量遞迴。若語意必要就保留，但要把額外預掃描算進時間。
3. 只對可壓縮資料測 -z
rsync -a --stats source/ user@example.com:/data/destination/
rsync -az --stats source/ user@example.com:/data/destination/文字可能受益，JPEG、MP4、ZIP 通常不會。兩端版本也會影響 zstd、lz4、zlib 等協商。只在 CPU 沒飽和且完整時間改善時保留壓縮。
4. 為中斷保留未完成的資料
rsync -a --partial --partial-dir=.rsync-partial source/ user@example.com:/data/destination/把未完成的目錄放在只有可信使用者可寫的位置，並測試空間與清理。這對中斷的大檔很有用，但無法消除數萬小檔案的中繼資料成本；也要確認它與 --whole-file、--inplace、延後更新的互動。
5. 把 --whole-file 當成實驗
--whole-file 會停用差分演算法，直接傳完整的已選檔案。若目的端既有檔案讀取很慢、檔案幾乎全部變更、WAN 尚有餘裕，可能更快；若計量頻寬有限，或大型檔案只改少量區塊，反而浪費。用 --stats 比較實際傳送位元組與完整時間。
6. 分開測大檔與小檔
| 結果 | 可能瓶頸 | 下一步 |
|---|---|---|
| 大檔與資料夾都慢 | WAN、SSH CPU、磁碟、流量整形 | 比較 iperf3、CPU 與本機磁碟 |
| 大檔快、資料夾慢 | 列舉與逐檔中繼資料 | 量開始傳送內容前的等待時間與檔案/s |
| 本機資料夾也慢 | 來源／目的檔案系統 | 查中繼資料 IOPS 與背景索引 |
| 壓縮只改善文字 | 頻寬與資料型態 | 依工作負載建設定組合 |
| 第二次明顯變快 | 快取或目的端既有資料 | 分別報告冷快取／暖快取測試 |
50,000 個檔案若序列化地多一次 80ms 等待，延遲預算就是 4,000 秒。Rsync 會處理流程，所以這不是預測值，但說明檔案數與 RTT 必須一起看。延伸閱讀：大量小檔案為何很慢。
何時保留 rsync，何時比較其他流程
需要 POSIX 中繼資料、檔案選擇規則、差異更新、自動化與標準 SSH 時，rsync 仍是好工具。若需求是大型首批複製、小檔案占多數、外部瀏覽器交付、集中管理或不想維護兩端 SSH／rsync，才比較其他方式。
WarpSend 不是 rsync 選項、擁有者、硬連結或刪除語意的可直接替換的工具；它是支援端點間的另一種檔案交付流程。用相同來源、目的、路由與資料集比較，才有意義。
本文選項已依 2026-08-06 的官方 rsync 3.4.4 文件核對。正式變更前，仍需測試刪除、權限、連結、稀疏檔案、延伸屬性、中斷與還原。
常見問題
為什麼 rsync 透過 WAN 很慢？
瓶頸可能在目錄掃描、逐檔中繼資料、RTT、SSH CPU、目的端寫入、丟包，或不必要的 --checksum 預掃描。先分別量測開始傳送前等待、檔案數、RTT、丟包、CPU、磁碟與完整總耗時。
rsync 適合傳大量小檔案嗎？
rsync 會處理流程並使用增量遞迴，但每個檔案仍需列舉、比對、建立與中繼資料操作。大量小檔案可能受檔案系統或延遲限制，即使 WAN 頻寬還有空間。
透過網路 rsync 應該加壓縮嗎？
用真實檔案測試。文字、紀錄、CSV 可能減少傳輸量；JPEG、MP4、ZIP 通常收益很小，反而增加 CPU。保留能改善完整時間的設定，不看單一壓縮率。
加 --checksum 會更安全嗎？
它改變的是傳輸前的變更判斷，會讓兩端讀取檔案內容，可能增加大量 I/O。rsync 對已傳輸檔案另有重建驗證。只有大小與修改時間不可信時，才應測試並使用 --checksum。