Solusi 1:
Sneakernet Siapa saja?
Dengan asumsi ini adalah salinan satu kali, saya rasa tidak mungkin untuk hanya menyalin file ke CD (atau media lain) dan bermalam ke tujuan, kan?
Itu mungkin sebenarnya pilihan tercepat Anda karena transfer file sebesar itu, melalui koneksi itu, mungkin tidak disalin dengan benar... dalam hal ini Anda harus memulai dari awal lagi.
rsync
Pilihan/upaya kedua saya adalah rsync karena mendeteksi transfer yang gagal, transfer sebagian, dll. dan dapat melanjutkan dari bagian sebelumnya.
rsync --progress file1 file2 [email protected]:/destination/directory
Bendera --progress akan memberi Anda umpan balik alih-alih hanya duduk di sana dan membiarkan Anda menebak-nebak sendiri. :-)
Vuze (bittorrent)
Pilihan ketiga mungkin adalah mencoba dan menggunakan Vuze sebagai server torrent dan kemudian meminta lokasi terpencil Anda menggunakan klien bitorrent standar untuk mengunduhnya. Saya tahu orang lain yang telah melakukan ini tetapi Anda tahu... pada saat mereka menyiapkan semuanya berjalan, dll... Saya dapat menyimpan data dalam semalam...
Tergantung pada situasi Anda, saya kira.
Semoga berhasil!
PEMBARUAN:
Kau tahu, aku memikirkan masalahmu sedikit lagi. Mengapa file tersebut harus berupa satu tarball besar? Tar sangat mampu membagi file besar menjadi file yang lebih kecil (untuk menjangkau media misalnya) jadi mengapa tidak membagi tarbal besar itu menjadi bagian yang lebih mudah dikelola dan kemudian mentransfer bagian tersebut?
Solusi 2:
Saya pernah melakukannya di masa lalu, dengan file tbz2 60GB. Saya tidak memiliki skrip lagi tetapi seharusnya mudah untuk menulis ulang.
Pertama, pisahkan file Anda menjadi beberapa bagian berukuran ~2GB :
split --bytes=2000000000 your_file.tgz
Untuk setiap bagian, hitung hash MD5 (ini untuk memeriksa integritas) dan simpan di suatu tempat, lalu mulailah menyalin bagian dan md5 mereka ke situs jarak jauh dengan alat pilihan Anda (saya :netcat-tar-pipe di layar sesi).
Setelah beberapa saat, periksa md5 apakah karya Anda baik-baik saja, lalu :
cat your_file* > your_remote_file.tgz
Jika Anda juga telah melakukan MD5 dari file aslinya, periksa juga. Jika tidak apa-apa, Anda dapat meng-untar file Anda, semuanya akan baik-baik saja.
(Jika saya punya waktu, saya akan menulis ulang skripnya)
Solusi 3:
Biasanya saya sangat mendukung rsync, tetapi saat mentransfer satu file untuk pertama kalinya, sepertinya tidak masuk akal. Namun, jika Anda mentransfer ulang file dengan hanya sedikit perbedaan, rsync akan menjadi pemenang yang jelas. Jika Anda tetap memilih untuk menggunakan rsync, saya sangat menyarankan untuk menjalankan salah satu ujungnya di --daemon mode untuk menghilangkan terowongan ssh yang mematikan kinerja. Halaman manual menjelaskan mode ini secara menyeluruh.
Rekomendasi saya? FTP atau HTTP dengan server dan klien yang mendukung melanjutkan unduhan yang terputus. Kedua protokol cepat dan ringan, menghindari penalti ssh-tunnel. Apache + wget akan berteriak dengan cepat.
Trik pipa netcat juga akan bekerja dengan baik. Tar tidak diperlukan saat mentransfer satu file besar. Dan alasan itu tidak memberi tahu Anda ketika selesai adalah karena Anda tidak menyuruhnya. Tambahkan -q0 tandai ke sisi server dan itu akan berperilaku persis seperti yang Anda harapkan.
server$ nc -l -p 5000 > outfile.tgz client$ nc -q0 server.example.com 5000 < infile.tgz
Kelemahan dari pendekatan netcat adalah tidak memungkinkan Anda untuk melanjutkan jika transfer Anda mati 74GB di...
Solusi 4:
Cobalah netcat (terkadang disebut nc). Berikut ini berfungsi pada direktori, tetapi seharusnya cukup mudah untuk men-tweak hanya dengan menyalin satu file.
Di kotak tujuan:
netcat -l -p 2342 | tar -C /target/dir -xzf -
Di kotak sumber:
tar czf * | netcat target_box 2342
Anda dapat mencoba menghapus opsi 'z' di kedua perintah tar untuk sedikit lebih cepat karena file tersebut sudah dikompresi.