如果輸入檔已經被 gzip 壓縮,rysnc -z 會有任何壓縮優勢嗎?我有一個 100GB 的大壓縮檔案要透過網路跨伺服器發送,但在不同的時間後它始終失敗(管道損壞)。想知道我是否應該嘗試 -z 標誌。
答案1
在傳輸過程中壓縮已壓縮的檔案通常不值得佔用 CPU 時間。有一些警告。在比較兩個檔案的過程中,使用具有壓縮的rsync可以加快資料雜湊值的比較。
如果您只想在多個系統上同步大檔案的壓縮版本,可以考慮的一個地方是 gzip 的某些版本。在 Ubuntu 系統上,我得到:
$ gzip -h 用法:gzip [選項]...[檔案]... 壓縮或解壓縮檔案(預設情況下,就地壓縮檔案)。 長期權的強制性參數對於短期權也是強制性的。 -c, --stdout 寫入標準輸出,保持原始檔案不變 -d, --decompress 解壓縮 -f, --force 強制覆蓋輸出檔並壓縮鏈接 -h, --help 提供協助 -l, --list 列出壓縮檔案內容 -L, --license 顯示軟體許可證 -n, --no-name 不儲存或還原原始名稱和時間戳 -N, --name 儲存或還原原始名稱和時間戳 -q, --quiet 抑制所有警告 -r, --recursive 對目錄進行遞迴操作 -S, --suffix=SUF 在壓縮檔上使用後綴 SUF -t, --test 測試壓縮檔案的完整性 -v, --verbose 詳細模式 -V, --version 顯示版本號 -1, --fast 壓縮得更快 -9, --best 壓縮得更好 --rsyncable 製作 rsync 友善的檔案 沒有 FILE 或 FILE 為 - 時,讀取標準輸入。 向 報告錯誤。
注意到那個--rsyncable
選項了嗎?它避免使用自適應壓縮,以便當來源檔案僅發生很小的更改時,僅更改壓縮檔案的一小部分。二進位資料的其餘部分保持不變,因此 rsync 不需要重新傳輸整個資料。手冊頁表明,與不使用該選項相比,該選項不應將壓縮檔案的大小增加超過 1% 左右,且gunzip 不會知道其中的差異。
我有一個 468MB 的 sql 文件,我使用該--rsyncable
選項將其壓縮為 57MB。我將此文件傳輸到我的本機系統。然後,我為遠端系統上的原始 sql 檔案添加一行註釋,並使用 rsyncable 選項重新壓縮。
$ rsync -avvz --progress -h fooboo:foo.sql.gz 。 使用 ssh fooboo rsync --server --sender -vvlogDtprz 開啟連線。 foo.sql.gz 接收文件列表... 需要考慮的 1 個文件 啟用增量傳輸 foo.sql.gz 59.64M 100% 43.22MB/s 0:00:01(xfer#1,待檢查=0/1) 總計:符合項目 = 7723 hash_hits = 9468 false_alarms = 0 資料 = 22366 發送 54.12K 位元組 接收 22.58K 位元組 17.05K 位元組/秒 總大小為 59.64M 加速比為 777.59
不錯。 Rsync 只需傳輸少量較新的壓縮檔案。
答案2
rsync 不會使已壓縮的檔案在傳輸過程中明顯變小。
透過新增 -z 標誌不太可能修復失敗的傳輸。我建議嘗試 rsync 未壓縮的檔案。然後 rsync 將即時壓縮。這樣您就有一個優勢,如果原始檔案發生更改並且您需要再次進行 rsync,則只會傳輸更改的位元組。如果更改壓縮文件,rsync 很可能必須重新傳輸整個文件。請參閱此處以了解更多詳細資訊:
答案3
與僅處理已使用良好壓縮格式壓縮的檔案時相比,使用它rsync -z
不會有任何優勢。rsync
但是,您可能會考慮將壓縮檔案分割成較小的部分,以便能夠使用 rsync 傳輸它。
這是 Linux 的指南:http://www.techiecorner.com/107/how-to-split-large-file-into-several-smaller-files-linux/ 對於 Windows:http://www.online-tech-tips.com/computer-tips/how-to-split-a-large-file-into-multiple-smaller-pieces/