將大文件從一台 Linux 伺服器複製到另一台
我正在嘗試通過 10MB 連結將 75 GB tgz（mysql lvm 快照）從我們洛杉磯數據中心的 Linux 伺服器複製到我們紐約數據中心的另一台 Linux 伺服器。
我得到大約 20-30Kb/s 的 rsync 或 scp，它在 200-300 小時之間波動。
目前它是一個相對安靜的連結，因為第二個數據中心還沒有啟動，我從小文件傳輸中獲得了極好的速度。
我已經按照我通過Google找到的不同的 tcp 調整指南無濟於事（也許我正在閱讀錯誤的指南，得到一個好的指南？）。
我已經看過 tar+netcat 隧道提示，但我的理解是它只適用於大量小文件，並且在文件有效完成傳輸時不會更新您。
在我訴諸運送硬碟之前，有沒有人有什麼好的意見？
更新： 嗯…畢竟可能是連結:(請參閱下面的測試…
從紐約轉移到洛杉磯：
得到一個空白文件。
[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000 4700000+0 records in 4700000+0 records out 4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s [nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST . FROM_NY_TEST 3% 146MB 9.4MB/s 07:52 ETA獲取快照壓縮包。
[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz -rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz [nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz . db_dump.08120922.tar.gz 0% 56MB 574.3KB/s 14:20:40 ET從洛杉磯轉移到紐約：
得到一個空白文件。
[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000 4700000+0 records in 4700000+0 records out 4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s [nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST . FROM_LA_TEST 0% 6008KB 497.1KB/s 2:37:22 ETA獲取快照壓縮包。
[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz -rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz [nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz . db_dump_08120901.tar.gz 0% 324KB 26.8KB/s 314:11:38 ETA我想我會和執行我們設施的人一起討論這個連結被標記為 MPLS/乙太網 10MB 連結。（聳肩）
有人嗎？
假設這是一次複製，我認為不可能將文件複製到 CD（或其他媒體）並在一夜之間將其複製到目的地嗎？
這實際上可能是您最快的選擇，因為通過該連接傳輸該大小的文件可能無法正確複製……在這種情況下，您可以重新開始。
rsync
我的第二個選擇/嘗試是 rsync，因為它檢測到失敗的傳輸、部分傳輸等，並且可以從中斷的地方繼續。
rsync --progress file1 file2 user@remotemachine:/destination/directory–progress 標誌會給你一些回饋，而不是坐在那裡讓你自己去猜測。:-)
Vuze (bittorrent)
第三種選擇可能是嘗試使用 Vuze 作為 torrent 伺服器，然後讓您的遠端位置使用標準的 bitorrent 客戶端下載它。我知道其他人已經這樣做了，但你知道……當他們把它全部設置好執行時，等等……我本可以在一夜之間保存數據……
取決於你的情況，我猜。
祝你好運！
更新：
你知道，我開始考慮你的問題了。為什麼文件必須是一個巨大的壓縮包？Tar 完全能夠將大文件拆分成較小的文件（例如跨媒體），那麼為什麼不將那個巨大的 tarball 拆分成更易於管理的部分，然後將這些部分轉移過來呢？