Mentransfer sejumlah besar data antar benua [duplikat]

12

Kemungkinan Gandakan:
Cara gratis untuk berbagi file besar melalui Internet?
Apa sajakah pilihan untuk mentransfer file besar tanpa menggunakan Internet?

Laboratorium istri saya sedang melakukan proyek di sini di AS dengan kolaborator di Singapura. Mereka kadang-kadang perlu mentransfer sejumlah besar data gambar dimensi tinggi (~ 10GB terkompresi) di seluruh benua. Dengan teknologi saat ini, apa solusi yang baik untuk skenario penggunaan ini?

Saya dapat memikirkan beberapa tetapi tidak satupun dari mereka yang tampak ideal:

Koneksi langsung melalui Internet: kecepatan transfer sekitar 500KB / dtk, juga tidak memiliki alat untuk menangani kesalahan / transmisi ulang.
Unggah ke server atau layanan umum seperti Dropbox: menyakitkan untuk diunggah untuk kolaborator non-AS.
Membakar disk atau menyalin ke HD dan mengirim melalui Kurir: latensi sangat penting, ditambah pekerjaan tambahan untuk membuat salinan lokal.

Ada saran?

Pembaruan: tidak satu pun pihak kolaborasi yang pengguna teknologi cerdas.

data-transfer

— jujur
sumber

Gambar seperti dalam gambar, atau gambar seperti dalam file yang mewakili DVD?

— Daniel Beck

Gambar dimensi tinggi, seperti yang dihasilkan oleh mikroskop.

— Frank

1

Jadi ini beberapa file yang sangat besar? Bisakah Anda memberi kami informasi lebih lanjut mengenai jumlah file, ukuran file individual, dan berapa banyak dari mereka yang berubah di antara transfer? Apakah semuanya, sebagian, dll.?

— Daniel Beck

1

Beberapa sequencer DNA telah memutuskan bahwa FedEx adalah cara tercepat untuk mengirim data dalam jumlah sangat besar ke seluruh dunia .

— joshuahedlund

Kedengarannya seperti pekerjaan untuk Sneakernet atau IPoAC .

— Naftuli Kay

20

Saya sarankan Anda menggunakan rsync . Rsync mendukung algoritma delta-transfer, jadi jika file Anda hanya diubah sebagian, atau jika transfer sebelumnya dihentikan secara tidak normal, Rsync cukup pintar untuk menyinkronkan hanya apa yang baru / diubah.

Ada beberapa port Rsync asli ke Windows dan sistem non-unix-kompatibel lainnya, baik yang gratis maupun yang tidak bebas. Silakan lihat artikel Wikipedia Rsync untuk detailnya.

Rsync over SSH sangat banyak digunakan, dan bekerja dengan baik. 10GB adalah jumlah data yang relatif kecil saat ini, dan Anda tidak menentukan apa artinya "sesekali". Mingguan? Harian? Per jam? Dengan transfer rate 500KB / detik akan memakan waktu sekitar 6 jam, tidak terlalu lama. Jika Anda perlu sering mentransfer data, mungkin lebih baik membuat tugas cron untuk memulai rsync secara otomatis.

— haim
sumber

Tidak rsyncmemerlukan protokol sendiri untuk delta, membutuhkan sistem rekanan yang mampu di ujung yang lain?

— Daniel Beck

@DanielBeck: Tidak ada dalam dokumen yang mengatakan bahwa rsync atas SSH tidak dapat menggunakan deltacopy ... Pada dasarnya klien rsync mengeksekusi salinan rsync lain di server melalui ssh, jadi saya tidak melihat mengapa itu tidak berhasil.

— haimg

+1 Anda ada benarnya. Itu meninggalkan persyaratan Linux di server?

— Daniel Beck

Apakah rsyncalgoritma delta berfungsi saat mentransfer data terkompresi biner ( .zipatau .jpg)?

— Aditya

@DanielBeck: Saya telah menambahkan tautan ke artikel Wikipedia dengan beberapa port rsync Windows. Rupanya setidaknya beberapa dari mereka bekerja sebagai server, termasuk ssh. Saya belum pernah menggunakan salah satu dari mereka.

— haimg

12

Koneksi di internet dapat menjadi opsi yang layak dan program seperti bittorrent sangat cocok untuk tujuan ini karena akan memecah file menjadi potongan-potongan logis untuk dikirim melalui internet untuk direkonstruksi di ujung lainnya.

Bittorrent juga memberi Anda koreksi kesalahan otomatis, perbaikan potongan-potongan yang rusak dan jika lebih banyak orang membutuhkan file maka mereka akan mendapat manfaat karena dapat dipasok file dari banyak sumber yang sudah memiliki (bagian) file yang diunduh.

Orang yang melihatnya melihatnya sebagai cara yang bagus untuk mengunduh film dan semacamnya, tetapi ia memang memiliki lebih banyak kegunaan hukum.

Banyak klien bittorrent juga memiliki pelacak bawaan sehingga Anda tidak perlu memiliki server khusus untuk menyimpan file.

— Mokubai
sumber

2

Terima kasih atas masukannya. Penggunaan BitTorrent dalam jaringan akademik dapat membuat administrator mereka gugup. Selain itu, pengaturan dan pemeliharaan server pelacak mungkin tidak semudah itu bagi pengguna komputer biasa.

— Frank

2

Itu poin bagus, bittorrent secara aktif dilarang di banyak jaringan korporat dan akademik. Dengan administrasi yang tepat Anda dapat mengatur daftar putih di dalam jaringan pengguna atau mesin yang diizinkan menggunakan bittorrent, meskipun ini berarti hubungan yang sangat erat dengan masing-masing departemen TI berfungsi dengan baik. Seperti yang saya sebutkan, Anda tidak perlu memiliki dedicated server karena dapat dibangun ke banyak program klien. Jika tidak cocok untuk situasi Anda, maka jangan khawatir, menurut saya masuk akal mengingat persyaratan Anda.

— Mokubai

Jika Anda menggunakan bitorrent, gunakan juga biji web terdengar seperti ide yang cerdas

— Journeyman Geek

(Sebagai contoh salah satu 'lebih banyak kegunaan hukum' yang disebutkan dalam jawaban, Facebook menggunakan bittorrent untuk menyebarkan situs mereka, biner 1GB, ke ribuan server produksi. Sangat disayangkan bahwa suatu teknologi dibuang sebagian besar karena salah satu penggunaannya.)

— Anton Strogonoff

6

Bagi file dalam potongan misalnya 50MB (menggunakan misalnya split). Hitung checksum untuk semuanya (mis md5sum.). Unggah secara langsung menggunakan FTP dan klien FTP yang toleran terhadap kesalahan, seperti lftpdi Linux. Transfer semua potongan dan file yang berisi semua checksum.

Di situs jarak jauh, pastikan semua potongan memiliki checksum yang diinginkan, muat ulang yang gagal, dan pasang kembali ke file asli (misalnya menggunakan cat).

Kembalikan lokasi server (saya memposting dengan asumsi bahwa situs tujuan menyediakan server dan Anda memulai transfer secara lokal ketika file siap) sesuai kebutuhan. Klien FTP Anda seharusnya tidak peduli.

Saya pernah mengalami masalah serupa di masa lalu dan menggunakan klien FTP yang toleran terhadap kesalahan berhasil. Tidak ada bit yang dibalik, hanya koneksi gagal, jadi saya bisa melewatkan membuat potongan dan hanya mengunggah file. Kami masih menyediakan checksum untuk file lengkap, untuk berjaga-jaga.

— Daniel Beck
sumber

3

Anda harus menyadari bahwa lftpitu tidak membatalkan transfer yang sedang berlangsung karena alasan apa pun. Pastikan Anda selalu memiliki cukup ruang disk kosong di situs tujuan.

— Daniel Beck

3

Variasi jawaban Daniel Beck adalah membagi file dalam potongan-potongan dalam urutan 50MB hingga 200MB dan membuat file paritas untuk seluruh rangkaian.

Sekarang Anda dapat mentransfer file (termasuk file paritas) dengan FTP, SCP atau yang lainnya ke situs jarak jauh dan melakukan pemeriksaan setelah kedatangan seluruh rangkaian. Sekarang jika ada bagian yang rusak mereka dapat diperbaiki oleh file paritas jika ada cukup banyak blok. Ini tergantung kurang lebih pada berapa banyak file yang rusak dan berapa banyak file paritas yang Anda buat.

File paritas banyak digunakan di Usenet untuk mengirim file besar. Sebagian besar waktu mereka dipecah sebagai arsip RAR. Tidak jarang mengirim data hingga 50 hingga 60GB dengan cara ini.

Anda pasti harus memeriksa tautan pertama dan Anda juga bisa melihat QuickPar , alat yang dapat digunakan untuk membuat file paritas, memverifikasi file yang Anda unduh dan bahkan dapat mengembalikan file yang rusak dengan file paritas yang disediakan.

— Martijn B
sumber

+1 - Pendekatan ini berfungsi baik di usenet, dan file paritas dapat memperbaiki jumlah data yang hilang yang mencengangkan. Kelemahannya adalah waktu pemrosesan yang diperlukan untuk memisahkan dan menghasilkan file paritas dan untuk memeriksa paritas dan mengekstrak file setelah penerimaan.

— Deizel

1

Apakah ini file 10GB yang besar? Mungkinkah itu mudah pecah?

Saya belum banyak bermain dengan ini, tetapi menurut saya itu konsep yang menarik dan relatif sederhana yang mungkin berhasil dalam situasi ini:

http://sendoid.com/

— Craig H
sumber

Sendoid memang keren, tapi sayangnya mengunggah masih akan menyakitkan. Kemudian lagi, masalah tetap ada untuk semua jenis yang saya percaya, kecuali jika Anda akan mengirim HDD. Memberi +1 karena mudah digunakan.

— DMan

0

Jadikan data tersedia melalui ftp / http / https / sftp / ftps (memerlukan kredensial masuk) dan gunakan pengelola unduhan apa pun di sisi klien.

Pengelola unduhan dirancang khusus untuk mengambil data terlepas dari kesalahan apa pun yang mungkin terjadi sehingga mereka sesuai dengan tugas Anda.

Sedangkan untuk server, server FTP biasanya yang paling mudah untuk diatur. Anda dapat berkonsultasi daftar di Wikipedia. HTTPS, SFTP dan FTPS memungkinkan enkripsi (dalam FTP / HTTP murni, kata sandi dikirim dalam bentuk teks yang jelas) tetapi SFTP / FTPS kurang umum didukung oleh perangkat lunak klien dan pengaturan server HTTP / HTTPS rumit.

— ivan_pozdeev
sumber

1

Masalah dengan menggunakan http atau ftp adalah bahwa ada kesalahan transmisi, Anda harus mengirim semuanya lagi. rsync, bittorrent, dan protokol lainnya dapat memverifikasi bahwa file-file tersebut cocok dan hanya mentransmisikan kembali bagian yang rusak. Data paritas, seperti yang dihasilkan QuickPar, dapat membantu juga.

— afrazier

Baik FTP dan HTTP termasuk kemampuan melanjutkan transfer sebagai ekstensi opsional yang didukung oleh sebagian besar server dan hampir semua manajer unduhan.

— ivan_pozdeev

Mereka dapat melanjutkan, dan secara teoritis TCP memastikan bahwa data tiba dalam urutan dan dengan checksum yang valid. Namun, siapa pun yang memiliki transfer HTTP atau FTP besar yang rusak telah mengetahui nilai protokol yang lebih kuat atau semacam ECC.

— Afrazier