解決策 1:
スニーカーネット？
これが 1 回限りのコピーであると仮定すると、ファイルを CD (または他のメディア) にコピーして、一晩で宛先にコピーすることはできないと思いますか?
その接続を介したそのサイズのファイル転送は正しくコピーされない可能性があるため、実際にはこれが最速のオプションである可能性があります...その場合、最初からやり直す必要があります.
rsync
失敗した転送、部分的な転送などを検出し、中断したところから再開できるため、私の 2 番目の選択肢/試みは rsync です。
rsync --progress file1 file2 [email protected]:/destination/directory
--progress フラグは、ただそこに座って自分で推測するのではなく、いくつかのフィードバックを提供します。 :-)
Vuze (bittorrent)
3 番目の選択肢は、Vuze を torrent サーバーとして使用してから、リモートの場所で標準の bitorrent クライアントを使用してダウンロードすることです。私はこれを行った他の人を知っていますが、ご存知のように...彼らがすべてのセットアップを実行するまでに...私はデータを一晩中保存できたはずです...
あなたの状況次第だと思います。
頑張ってください!
更新:
ほら、あなたの問題についてもう少し考えてみました。ファイルが単一の巨大な tarball でなければならないのはなぜですか? Tar は大きなファイルを小さなファイルに完全に分割できます (たとえば、複数のメディアにまたがるため)。その巨大な tarball をより管理しやすい部分に分割し、代わりにその部分を転送してみませんか?
解決策 2:
私は過去に、60GBのtbz2ファイルでそれを行いました。スクリプトはもうありませんが、簡単に書き直せるはずです。
まず、ファイルを ~2GB の断片に分割します:
split --bytes=2000000000 your_file.tgz
各ピースについて、MD5 ハッシュを計算し (これは整合性をチェックするためです)、どこかに保存してから、選択したツールを使用して、ピースとその md5 をリモート サイトにコピーし始めます (me :netcat-tar-pipe in a screen)セッション）
しばらくして、md5 でピースに問題がないか確認してください。
cat your_file* > your_remote_file.tgz
元のファイルの MD5 も行っている場合は、それも確認してください。問題がなければ、ファイルを untar できます。すべて問題ないはずです。
(時間があればスクリプトを書き直します)
解決策 3:
通常、私は rsync を大いに支持していますが、単一のファイルを初めて転送するときはあまり意味がないようです。ただし、わずかな違いだけでファイルを再転送する場合は、rsync が明らかに勝者になります。とにかく rsync を使用する場合は、--daemon で一方の端を実行することを強くお勧めします モードを使用して、パフォーマンスを低下させる ssh トンネルを排除します。 man ページでは、このモードについて詳しく説明しています。
私の推薦？中断されたダウンロードの再開をサポートするサーバーとクライアントを使用する FTP または HTTP。どちらのプロトコルも高速で軽量なので、ssh トンネルのペナルティを回避できます。 Apache + wget は高速で叫ぶでしょう。
netcat パイプ トリックも問題なく動作します。単一の大きなファイルを転送する場合、tar は必要ありません。完了しても通知されないのは、通知されていないためです。 -q0 を追加 サーバー側にフラグを付けると、期待どおりに動作します。
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
netcat アプローチの欠点は、転送が 74 GB で停止した場合に再開できないことです...
解決策 4:
netcat (nc と呼ばれることもあります) を試してみてください。以下はディレクトリで機能しますが、1 つのファイルをコピーするだけの微調整は簡単です。
宛先ボックス:
netcat -l -p 2342 | tar -C /target/dir -xzf -
ソースボックス:
tar czf * | netcat target_box 2342
ファイルが既に圧縮されているため、両方の tar コマンドで「z」オプションを削除して、速度を少し上げることができます。