apa cara tercepat dan paling dapat diandalkan untuk mentransfer banyak file?

10

Saya mencoba mentransfer sekitar 100k file dengan jumlah total 90GB. Saat ini saya menggunakan daemon rsync tetapi 3.4mb / s lambat dan saya perlu melakukan ini beberapa kali. Saya bertanya-tanya opsi apa yang saya miliki yang akan memaksimalkan koneksi 100mbit melalui internet dan menjadi sangat andal.

rsync file-transfer

— penyamaran2
sumber

2

Anda mendapatkan hampir sepertiga dari koneksi Anda - itu terhormat, tetapi tidak bagus. Seberapa jauh elektron terbang dari file yang ditransfer?

— Shane Madden

50 ms latensi antara kedua server.

— incognito2

5

Saya melihat banyak sekali file hyperboleandahalf.blogspot.com/2010/04/...

— Smudge

Jika Anda menggunakan daemon rsync, tidak ada ssh yang terlibat, bukan? Maka penjelasannya mungkin infrastruktur di antara host. Anda bisa mencoba netperf atau iperf atau flowgrind untuk menguji kecepatan antar host. Jika tes ini memberi Anda kecepatan transfer yang lebih tinggi, maka Anda harus melihat bagaimana rsync membuat segalanya menjadi lambat: baca i / o di server lambat, tulis i / o di klien, banyak file kecil, sistem file, dll.

— AndreasM

kemungkinan duplikat dari Bagaimana cara menyalin sejumlah besar file dengan cepat antara dua server

— Scott Pack

11

Sudahkah Anda mempertimbangkan Sneakernet ? Dengan set data besar pengiriman dalam semalam sering kali akan menjadi lebih cepat dan lebih murah daripada mentransfer melalui Internet.

— ceejayoz
sumber

10

"Jangan pernah meremehkan bandwidth gerobak stasiun yang penuh dengan kaset yang meluncur deras di jalan raya." - AST

— voretaq7

1

baik, mengingat keterjangkauan perangkat keras gigabit LAN, jika ini merupakan transfer LAN, waktu yang dihabiskan untuk menulis melalui eSATA ke satu poros tidak terlalu menarik.

— memnoch_proxy

10

Bagaimana? Atau TL; DR

Metode tercepat yang saya temukan adalah kombinasi dari tar, mbufferdan ssh.

Misalnya:

tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"

Dengan ini saya telah mencapai transfer jaringan lokal yang berkelanjutan lebih dari 950 Mb / s pada tautan 1Gb. Ganti jalur di setiap perintah tar agar sesuai untuk apa yang Anda transfer.

Mengapa? mbuffer!

Hambatan terbesar dalam mentransfer file besar melalui jaringan adalah, sejauh ini, disk I / O. Jawabannya adalah mbufferatau buffer. Mereka sebagian besar mirip tetapi mbuffermemiliki beberapa keunggulan. Ukuran buffer default adalah 2MB untuk mbufferdan 1MB untuk buffer. Buffer yang lebih besar cenderung tidak pernah kosong. Memilih ukuran blok yang merupakan kelipatan umum terendah dari ukuran blok asli pada sistem file target dan tujuan akan memberikan kinerja terbaik.

Buffering adalah hal yang membuat semua perbedaan! Gunakan jika Anda memilikinya! Jika Anda tidak memilikinya, dapatkan! Menggunakan (m}?bufferplus apa pun lebih baik daripada apa pun dengan sendirinya. hampir secara harfiah merupakan obat mujarab untuk transfer file jaringan yang lambat.

Jika Anda mentransfer banyak file, gunakan taruntuk "menyatukan" keduanya menjadi satu aliran data. Jika itu adalah file tunggal yang dapat Anda gunakan catatau I / O redirection. Overhead tarvs catsecara statistik tidak signifikan jadi saya selalu menggunakan tar(atau di zfs -sendmana saya bisa) kecuali itu sudah tarball . Tidak satu pun dari ini dijamin memberi Anda metadata (dan khususnya cattidak akan). Jika Anda ingin metadata, saya akan meninggalkan itu sebagai latihan untuk Anda.

Akhirnya, menggunakan sshuntuk mekanisme transportasi aman dan membawa sedikit overhead. Sekali lagi, overhead sshvs ncsecara statistik tidak signifikan.

— bahamat
sumber

Terkadang ada enkripsi overhead dalam menggunakan SSH sebagai transportasi. Lihat: Menyalin file antara mesin linux dengan otentikasi kuat tanpa enkripsi

— ewwhite

2

Anda dapat menggunakan mekanisme enkripsi yang lebih cepat jika perlu. Tetapi Anda tidak perlu menyalurkan melalui ssh ini. Saya lebih suka mengatur port -O dan -I pada mbuffer di kedua sisi. Bahkan sekarang ini adalah dua perintah, Anda melewatkan enkripsi dan memaksimalkan bandwidth jaringan dengan buffering kedua ujungnya. Saya mengirim aliran tar pada 720 + Mbps di LAN lokal saya dengan yang setara dengantar -cf - .|mbuffer -m128k -s 256M -I 9090 & mbuffer -m128k -s 256M -O host:9090 | tar -xf -

— memnoch_proxy

2

@memnoch_proxy: Itu saran yang bagus (yang saya pilih) tetapi di zaman sekarang di mana NSA bahkan mengetuk jalur data pribadi antara pusat data (misalnya, Google dan Yahoo) menggunakan enkripsi, IMO, selalu merupakan kebiasaan yang baik untuk membuat . Menggunakannya sshmembuat hal itu sederhana. Menggunakan stunnel, socatatau opensslbekerja juga, tetapi lebih rumit untuk diatur untuk transfer sederhana.

— bahamat

1

@ Bahaham terima kasih telah membuat saya melihat pertanyaan itu lagi. Saran saya hanya cocok jika transfer dapat terjadi melalui VPN. Untuk transfer internet, saya pasti akan menggunakan ssh juga.

— memnoch_proxy

8

Anda menyebutkan "rsync," jadi saya berasumsi Anda menggunakan Linux:

Mengapa Anda tidak membuat file tar atau tar.gz? Waktu transfer jaringan dari satu file besar lebih cepat daripada banyak file kecil. Anda bahkan dapat mengompresnya jika Anda mau ...

Tar tanpa kompresi:

Di server sumber:

tar -cf file.tar /path/to/files/

Kemudian di ujung penerima:

cd /path/to/files/
tar -xf /path/to/file.tar

Tar dengan kompresi:

Di server sumber:

tar -czf file.tar.gz /path/to/files/

Kemudian di ujung penerima:

cd /path/to/files/
tar -xzf /path/to/file.tar.gz

Anda cukup menggunakan rsync untuk melakukan transfer file (tar | tar.gz) yang sebenarnya.

— Soviero
sumber

hanya jika ada tempat yang tersedia untuk menyimpan arsip ..

— Tebe

5

Anda dapat mencoba tardan sshtrik yang dijelaskan di sini :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "dd of=/backup/wwwdata.tar.gz"

ini harus ditulis ulang sebagai berikut :

tar cvzf - /wwwdata | ssh root@192.168.1.201 "tar xvf -"

Anda akan kehilangan --partialfitur rsyncdalam prosesnya. Jika file tidak terlalu sering berubah, hidup dengan inisial yang lambat rsyncbisa sangat bernilai - karena akan jauh lebih cepat di masa depan.

— warren
sumber

2

Anda dapat menggunakan berbagai opsi kompresi rsync.

-z, --compress              compress file data during the transfer
     --compress-level=NUM    explicitly set compression level
     --skip-compress=LIST    skip compressing files with suffix in LIST

rasio kompresi untuk file biner sangat rendah, sehingga Anda dapat melewati file-file tersebut menggunakan --skip-kompres misalnya iso, sudah terarsip dan tarbal terkompresi dll.

— Sachin Divekar
sumber

-6

Saya penggemar berat SFTP. Saya menggunakan SFTP untuk mentransfer media dari komputer utama saya ke server saya. Saya mendapatkan kecepatan yang baik, melalui LAN.

SFTP dapat diandalkan, saya akan mencobanya, karena mudah diatur, dan bisa lebih cepat dalam beberapa kasus.

— Tillman32
sumber

5

FTP harus mati. Itu tidak terenkripsi, tidak menangani gangguan dengan baik, dan ada setidaknya setengah lusin alternatif yang layak untuk itu yang tidak sepenuhnya menyedot.

— MDMarra

1

Pernah mendengar tentang SFTP?

— Tillman32

8

Ya kan Ini sama sekali tidak terkait dengan protokol FTP dalam apa pun kecuali nama dan fakta bahwa ia memindahkan file.

— MDMarra

5

FTP juga terkenal tidak dapat diandalkan ketika melintasi firewall (itu berasal dari masa sebelum firewall ketika klien Anda membuka port acak untuk menerima koneksi-kembali itu keren, dan peretasan Pasif & Extended Passive FTP untuk mengatasi keterbatasan itu hanya itu: Hackery)

— voretaq7