使用 Rsync 以一種方式移動然後同步大量數據
編輯：基於兩個深入的答案，我試了一下：
rsync --progress -v -az -e “ssh” /archive/images/dcam/ root@10.x.x.xxx:/data/archive/images/dcam --dry-run所以 –progress 來查看結果 -v 讓它變得冗長？-az 存檔它（從而獲得時間戳）和 z 壓縮它以節省網路流量。-e 通過 ssh 登錄，其中機器 10.xxxxx 確實在授權密鑰中具有源 ssh 密鑰。唉，我得到了這個錯誤：
rsync: Failed to exec \#342\#200\#234ssh\#342\#200\#235: No such file or directory (2) rsync error: error in IPC code (code 14) at pipe.c(84) [sender=3.0.6] rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in IPC code (code 14) at io.c(600) [sender=3.0.6]這很奇怪，因為遠端機器已經有一個 /data/archive/images/dcam 裡面有數據。
我一定不能完全理解 rsync 是如何工作的。我有兩台伺服器……一台有大量數據我想轉移到另一台。所以…我 NFS 將文件夾從伺服器 B（各種備份所在的位置）安裝到伺服器 A。
然後因為這是一個重要的實時伺服器，我很緊張讓 RSYNC 在 2TB 的數據上執行……我像這樣手動執行：（在 /archive/images 文件夾中）rsync -r imageDateXX/ /mnt/backup/ archive/images/imageDateXX 並為 2TB 的文件夾和數據重複此操作。我終於讓它工作了。所以我很高興我沒有讓伺服器癱瘓，然後這個數據整晚都在更新。因此，為了讓伺服器 B 保持最新數據，我設置了一個 cronjob：
0 8 * * * rsync -r /archive/images/ /mnt/backup/archive/images這開始了（我假設），但仍然需要 2 天才能完成。看起來不僅是查看伺服器 A 上的新內容/或更改的內容並將其放入伺服器 B，而且將所有文件再次覆蓋返回伺服器 B。我不知道如何測試這個理論，但它需要很長時間。我是否錯過了 rsync 中的一個開關，或者我正在逐個文件夾執行 rsync 文件夾是否讓我在父文件夾上執行 rsync 看起來與 rsync 不同，因為它認為它的所有新數據並複制所有內容，即使它到相同的確切位置伺服器 b?
不知道如何測試這個理論或確定。認為它是直截了當的，如果文件在伺服器 B 上不存在或在伺服器 A 上發生更改，rsync 會自動覆蓋文件或複製文件。
您的解決方案有兩個主要問題，這就是為什麼每個副本都需要這麼長時間才能完成：
- 您沒有復製文件時間，因此
rsync無法辨識和跳過已複製的文件。因此每次呼叫都會複製所有內容- 您正在從
rsync本地文件系統的一部分複製到另一部分。在這種情況下，您不會獲得增量副本，但是對文件的任何更改都會導致整個內容被完整複製修復
- 包括
--times(-t) 或考慮--archive(-a) 以一次性獲取大部分元數據。即使您必須繼續使用 NFS，也要這樣做- 不要使用 NFS，而是使用
ssh到 NFS 伺服器的傳輸（remoteHost在我的範例中）--compress使用(-z)壓縮網路上的流量例子
rsync -az /archive/images/ remoteHost:/mnt/backup/archive/images如果以互動方式執行，我通常也會包含
--partial --progress --verbose( )-Pv在您的情況下第一次執行這個修改過的命令時，您會發現它仍然需要很長時間才能完成。這是因為
rsync沒有快速的方法來辨識哪些文件是最新的 - 它通過文件時間和大小來做到這一點 - 所以它必須比較每個文件對（源和目標）以發現只有元數據是不同的。此後，rsync僅當文件大小或時間不同時才會考慮複製文件，因此將跳過未更改的文件。
rsync --progress -av -e "ssh" /archive/images/ username@[serverIP-or-domainname]:/archive/images --dry-run樣本：
rsync --progress -av -e "ssh" /archive/images/ fred@192.168.1.119:/archive/images --dry-run這是假設兩台機器上的目錄都是/archive/images，並且您已經設置了密鑰，並且遠端系統已經執行了sshd，我很確定它確實如此。
--dry-run查看操作會做什麼總是有用的，有助於避免令人討厭的錯誤。
-v添加輸出詳細程度，這對於跟踪操作的位置很有用。
--delete從目標中刪除源上不再存在的文件，如果您在遠端系統上創建數據的鏡像，通常需要這樣做。如果您的數據變化很大，您可能需要查看--delete-before、--delete-after、--delete-during，看看哪個最能滿足您的需求。但是，我發現--delete通常可以正常工作，但是對於 TiB 數據，這可能很重要。--delete-before例如，如果您正在處理幾乎已滿的遠端磁碟，這很有用。小心刪除！！它將刪除在本地路徑中找不到的遠端路徑中的任何內容，這意味著，如果您提供錯誤的路徑，它會愉快地開始刪除或嘗試刪除該遠端目錄中的所有內容。至少不要在
--delete沒有--dry-run第一次的情況下使用，以確保您沒有犯錯！
-rtvz是一種比-a. 我發現這個對於大多數應用程序來說已經足夠好了。
-a基本上創建了-aHAX源的幾乎真實的鏡像（主要是完整的鏡像）。-a/--archive與-rlptgoD(no-H,-A,-X) 相同。
--progress在作業執行時顯示進度，這很有用。
-e "ssh"正在執行 ssh，如果您在命令中需要更多 ssh 選項或其他任何內容，例如特定的 ssh 埠，這可能是一個更長的命令。樣本：-e "ssh -p 423"
-z：如果您想降低 cpu 使用率，假設圖像等二進製文件對頻寬沒有太大變化，請刪除-zcompress 選項。
--bwlimit：如果您擔心佔用過多機器之間的網路頻寬，這很有用，最小速度大小為 1k，1 KiB/s，可以是 1m，又名，1 MiB/s 等。如果您不這樣做，這將非常有用’不想佔用進行傳輸的網路的所有頻寬。正如 man 所說，請參閱--max-size不同單位的語法。單位字元串的第一個字母可以是 B (bytes[not for
--bwlimit)、K (kilo)、M (mega)、G (giga)、T (tera) 或 P (peta)。如果字元串是單個字元或添加了“ib”（例如“G”或“GiB”），則單位是 1024 的倍數。如果您使用以“B”結尾的兩個字母后綴（例如"kb") 那麼你得到的單位是 1000 的倍數。字元串的字母可以是你想要使用的大小寫的任意組合。
--partial：如果您認為傳輸可能會被中斷，這很有用，這可以防止 rsync 在中斷時刪除部分傳輸的預設設置。請注意，在您第一次完成同步後，所有後續同步都將大大加快，因為只更新更改的文件。一旦邏輯工作正常，您總是希望
--delete在未來的同步中使用以保持本地和遠端文件同步，刪除已刪除或重命名的文件等。在某些配置中，僅更新文件上更改的數據，例如，如果該文件具有可以更改的元數據，但是不會更改的二進制核心數據，只有元數據部分會更改。不太適用於圖像，但它適用於其他數據類型，可以使同步速度提高 100 倍。rsync 和 nfs
特別是如果使用 ext4，rsync over nfs 將失敗，因為它不支持所有文件系統屬性，如果您正在傳輸這些屬性，您在 -a 的情況下會這樣做。它也很慢。nfs 適用於通過本地網路進行較小的傳輸，您不會遇到擴展文件屬性問題，但我不會在生產中使用它。我曾經使用 rsync 在 nfs 上進行備份，當 ext4 出現時不得不停止，因為太多屬性無法傳輸。
重新同步手冊頁
在使用這些系統時，沒有什麼比花一些時間閱讀 rysnc 手冊頁更有用的了，例如，
--partial直到今天我才意識到這是一件事，並且一直在努力解決非常大的文件傳輸中斷並且不得不重新開始下次啟動時中斷的文件。然而，我不會粉飾它，儘管在我看來是有史以來最好的 cli 軟體之一，rysnc 的手冊頁很糟糕，非常需要重組，在裡面很難找到東西，我沒有甚至在今天閱讀之前了解其中的一些內容，例如，不知道例如，
--partial由於大文件的中斷傳輸而導致我失去了無數小時的重新啟動。給 Andrew Tridgell 送一份披薩，哈哈，當人們想付錢給他製作 rsync 時，他常常要求這樣做，但更好的是，幫助修復手冊頁以使其更有用，將其分解成合乎邏輯的部分，真的是閱讀和使用的鬥爭。但它是優秀的文件，但沒有很好地重組。