it-swarm-id.com

Cara menyalin sejumlah besar file dengan cepat antara dua server

Saya perlu mentransfer sejumlah besar mp3 antara dua serve (Ubuntu). Maksud saya sekitar satu juta file yang rata-rata 300 ribu. Saya mencoba dengan scp tetapi itu akan memakan waktu sekitar satu minggu. (sekitar 500 KB/s) Jika saya mentransfer satu file dengan HTTP, saya mendapatkan 9-10 MB/s, tetapi saya tidak tahu bagaimana cara mentransfer semuanya.

Apakah ada cara untuk mentransfer semuanya dengan cepat?

96
nicudotro

Saya akan merekomendasikan tar. Ketika pohon file sudah serupa, rsync melakukan sangat dengan baik. Namun, karena rsync akan melakukan beberapa analisis lewati pada setiap file, dan kemudian menyalin perubahan, itu jauh lebih lambat daripada tar untuk salinan awal. Perintah ini kemungkinan akan melakukan apa yang Anda inginkan. Ini akan menyalin file-file di antara mesin-mesin, serta menjaga baik izin dan kepemilikan pengguna/grup.

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

Sesuai komentar Mackintosh di bawah ini adalah perintah yang akan Anda gunakan untuk rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
119
Scott Pack

Hard drive eksternal dan pengiriman kurir pada hari yang sama.

38
Adam

Saya akan menggunakan rsync.

Jika Anda mendapatkannya diekspor melalui HTTP dengan daftar direktori yang tersedia, Anda bisa menggunakan argumen wget dan --mirror.

Anda sudah melihat bahwa HTTP lebih cepat daripada SCP karena SCP mengenkripsi semuanya (dan karenanya menghambat CPU). HTTP dan rsync akan bergerak lebih cepat karena mereka tidak mengenkripsi.

Berikut ini beberapa dokumen tentang pengaturan rsync di Ubuntu: https://help.ubuntu.com/community/rsync

Dokumen-dokumen itu berbicara tentang tunneling rsync melalui SSH, tetapi jika Anda hanya memindahkan data di LAN pribadi Anda tidak perlu SSH. (Saya berasumsi Anda menggunakan LAN pribadi. Jika Anda mendapatkan 9-10MB/detik melalui Internet, maka saya ingin tahu koneksi apa yang Anda miliki!)

Berikut adalah beberapa dokumen yang sangat mendasar yang akan memungkinkan Anda untuk mengatur server rsync relatif tidak aman (tanpa ketergantungan pada SSH): http://transamrit.net/docs/rsync/

17
Evan Anderson

Tanpa banyak diskusi, gunakan netcat, pisau swissarmy jaringan. Tanpa overhead protokol, Anda langsung menyalin ke soket jaringan. Contoh

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -
16
Icapan

Dengan banyak file jika Anda menggunakan rsync, Saya akan mencoba untuk mendapatkan versi 3 atau lebih di kedua ujungnya. Alasannya adalah bahwa versi yang lebih rendah akan menghitung setiap file sebelum memulai transfer. Fitur baru ini disebut incremental-recursion .

Algoritma incremental-recursion baru sekarang digunakan ketika rsync sedang berbicara dengan versi 3.x lainnya. Ini memulai transfer menjadi lebih cepat (sebelum semua file ditemukan), dan membutuhkan lebih sedikit memori. Lihat opsi --recursive di halaman manual untuk beberapa batasan.

8
Kyle Brandt

rsync, seperti yang lainnya telah direkomendasikan. Jika overhead CPU dari enkripsi adalah hambatan, gunakan algoritma CPU yang kurang intensif lainnya, seperti blowfish. Misalnya. sesuatu seperti

rsync -ax -e 'ssh -c blowfish' /local/path [email protected]:/remote/path

7
janneb

Dalam memindahkan 80 TB data (jutaan file kecil) kemarin, beralih dari rsync ke tarterbukti menjadi jauh lebih cepat , ketika kami berhenti mencoba

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

dan beralih ke tar sebagai gantinya ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

Karena server ini berada di LAN yang sama, tujuannya adalah NFS-mount pada sistem sumber, yang melakukan Push. Tidak membuatnya lebih cepat, kami memutuskan untuk tidak mempertahankan atime file:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

Grafik di bawah ini menggambarkan perbedaan perubahan dari rsync ke tar yang dibuat. Itu adalah ide bos saya dan rekan saya keduanya mengeksekusi dan membuat Langgan hebat di blognya . Saya hanya suka gambar-gambar cantik . :)

rsync_vs_tar

7
Philip Durbin

Ketika menyalin sejumlah besar file, saya menemukan bahwa alat-alat seperti tar dan rsync lebih tidak efisien daripada yang seharusnya karena overhead membuka dan menutup banyak file. Saya menulis alat open source yang disebut fast-archiver yang lebih cepat daripada tar untuk skenario ini: https://github.com/replicon/fast-archiver ; ini bekerja lebih cepat dengan melakukan beberapa operasi file bersamaan.

Berikut adalah contoh pengarsip cepat vs. tar pada cadangan lebih dari dua juta file; pengarsip cepat membutuhkan 27 menit untuk mengarsipkan, vs tar mengambil 1 jam 23 menit.

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

Untuk mentransfer file antar server, Anda dapat menggunakan pengarsip cepat dengan ssh, seperti ini:

ssh [email protected] "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
4
mfenniak

Saya menggunakan tar melalui pendekatan netcat juga, kecuali saya lebih suka menggunakan socat - kekuatan yang lebih besar untuk mengoptimalkan situasi Anda - misalnya, dengan mengubah-ubah mss. (Juga, tertawa jika Anda mau, tetapi saya menemukan argumen socat lebih mudah diingat karena konsisten). Jadi bagi saya, ini sangat umum akhir-akhir ini karena saya telah memindahkan beberapa hal ke server baru:

Host1$ tar cvf - filespec | socat stdin tcp4:Host2:portnum

Host2$ socat tcp4-listen:portnum stdout | tar xvpf -

Alias ​​adalah opsional.

3
  • Sistem File Jaringan (NFS) lalu salin dengan apa pun yang Anda suka, mis. Midnight Commander (mc), Nautilus (dari gnome). Saya telah menggunakan NFS v3 dengan hasil yang baik.
  • Samba (CIFS) dan kemudian salin file dengan apa pun yang Anda inginkan, tapi saya tidak tahu seberapa efisien itu.
  • [~ # ~] http [~ # ~] dengan wget --mirror as Evan Anderson telah menyarankan atau klien http lainnya. Berhati-hatilah untuk tidak memiliki symlink jahat atau file indeks yang menyesatkan. Jika yang Anda miliki hanyalah MP3, Anda harus aman.
  • rsync . Saya telah menggunakannya dengan hasil yang cukup bagus dan salah satu fitur bagusnya adalah Anda dapat mengganggu dan melanjutkan transfer nanti.

Saya perhatikan bahwa orang lain merekomendasikan menggunakan netcat. Berdasarkan pengalaman saya dengan itu saya bisa mengatakan itu lambat dibandingkan dengan solusi lain.

2

Sepertinya mungkin ada beberapa kesalahan ketik di jawaban atas. Ini mungkin bekerja lebih baik:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'
2
retracile

Berkat jawaban luar biasa Scott Pack (saya tidak tahu bagaimana melakukan ini dengan ssh sebelumnya), saya dapat menawarkan peningkatan ini (jika bash adalah Shell Anda). Ini akan menambah kompresi paralel, indikator kemajuan dan memeriksa integritas di seluruh tautan jaringan:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pv adalah program penampil kemajuan yang bagus untuk pipa Anda dan pigz adalah program gzip paralel yang menggunakan sebanyak utas seperti yang dimiliki CPU Anda secara default (saya yakin hingga 8 maks). Anda dapat menyesuaikan tingkat kompresi agar lebih sesuai dengan rasio CPU dengan bandwidth jaringan dan menukar dengan pxz -9e dan pxz -d jika Anda memiliki lebih banyak CPU daripada bandwidth. Anda hanya perlu memverifikasi bahwa kedua jumlah cocok setelah selesai.

Opsi ini berguna untuk jumlah data yang sangat besar serta jaringan latensi tinggi, tetapi tidak sangat membantu jika tautannya tidak stabil dan turun. Dalam kasus tersebut, rsync mungkin merupakan pilihan terbaik karena dapat dilanjutkan.

Output sampel:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

Untuk perangkat blok:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [[email protected]]remote_Host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

Jelas, pastikan ukuran atau batasnya sama dengan count =, skip =, seek =, dll.

Ketika saya menyalin filesystems dengan cara ini, saya akan sering lebih dulu dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs ke nol sebagian besar ruang yang tidak digunakan, yang mempercepat xfer.

2
Daniel Santos

Alternatif lain adalah Serempak . Mungkin sedikit lebih efisien daripada Rsync dalam kasus ini, dan agak lebih mudah untuk mengatur pendengar.

2
Adam D'Amico

Anda tidak menyebutkan apakah kedua mesin berada di LAN yang sama, atau jika saluran aman (yaitu menggunakan SSH) adalah wajib, tetapi alat lain yang dapat Anda gunakan adalah netcat .

Saya akan menggunakan yang berikut ini di mesin penerima:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

Kemudian di sisi pengirim:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

Ini memiliki keuntungan sebagai berikut:

  • Tidak ada overhead CPU untuk enkripsi yang dimiliki ssh.
  • gzip -1 memberikan kompresi ringan tanpa membuat CPU jenuh sehingga menghasilkan pertukaran yang baik, memberikan sedikit kompresi sambil mempertahankan throughput maksimum. (Mungkin tidak menguntungkan untuk data MP3, tetapi tidak ada salahnya.)
  • Jika Anda dapat mempartisi file menjadi kelompok-kelompok, Anda dapat menjalankan dua atau lebih pipa secara paralel dan benar-benar memastikan Anda menjenuhkan bandwidth jaringan Anda.

misalnya.,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

Catatan:

  • Apa pun cara Anda mentransfer, saya mungkin akan menjalankan rsync atau serempak setelahnya untuk memastikan Anda mendapatkan segalanya.
  • Anda dapat menggunakan tar alih-alih cpio jika Anda mau.
  • Bahkan jika Anda akhirnya menggunakan ssh, saya akan memastikan itu tidak menggunakan kompresi itu sendiri, dan pipa melalui gzip -1 sendiri sebagai gantinya untuk menghindari saturasi CPU. (Atau setidaknya mengatur CompressionLevel ke 1.)
1
Evan

Jika Anda memiliki server ftp di sisi src, Anda dapat menggunakan ncftpget dari situs ncftp . Ini berfungsi prefek dengan file kecil karena menggunakan tar secara internal.

Satu perbandingan menunjukkan ini: memindahkan 1.9GB file kecil (33926 file)

  1. Menggunakan scp membutuhkan waktu 11m59s
  2. Menggunakan rsync membutuhkan waktu 7m10s
  3. Menggunakan ncftpget membutuhkan waktu 1m20s
1
Ali Nikneshan

Anda juga dapat mencoba menggunakan perintah BBCP untuk melakukan transfer Anda. Ini adalah ssh paralel buffered yang benar-benar menjerit. Kami biasanya bisa mendapatkan 90% + line-rate asalkan kita bisa terus makan pipa.

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

Biasanya, kami berusaha sangat keras untuk menghindari keharusan bergerak. Kami menggunakan kumpulan ZFS yang kami selalu bisa "menambahkan" lebih banyak ruang disk. Tapi kadang-kadang ... Anda hanya perlu memindahkan barang. Jika kita memiliki sistem file "live" yang mungkin membutuhkan waktu berjam-jam (atau berhari-hari) untuk menyalin bahkan ketika akan full-blast .. kita melakukan dua langkah zfs mengirim rutin:

  1. Buat snapshot ZFS, dan transfer ke kumpulan baru pada mesin baru. Biarkan selama yang diperlukan.
  2. Buat snapshot kedua, dan kirimkan sebagai tambahan. Snapshot tambahan hanya mencakup set perubahan (jauh lebih kecil) sejak yang pertama, sehingga melalui relatif cepat.
  3. Setelah snapshot tambahan selesai, Anda dapat mengubah aslinya dan memotong ke salinan baru dan "downtime offline" Anda dijaga agar tetap minimum.

Kami juga mengirim pembuangan zf kami ke BBCP juga ... ini memaksimalkan pemanfaatan jaringan kami dan meminimalkan waktu transfer.

BBCP tersedia secara gratis, Anda dapat mencarinya di Google, dan kompilasi langsung-foward. Cukup salin ke/usr/local/bin Anda di kedua src dan mesin tujuan dan itu hanya akan berfungsi.

1
C. Shamis

Saya kira jawaban saya agak terlambat di sini, tetapi saya membuat pengalaman yang baik dengan menggunakan mc (Midnight Commander) pada satu server untuk terhubung melalui SFTP ke server lain.

Opsi untuk terhubung melalui FTP ada di menu "Kiri" dan "Kanan", dengan memasukkan alamat seperti ini:

/#ftp:[email protected]/

atau

/#ftp:[email protected]/

Anda dapat menavigasi dan melakukan operasi file hampir seperti pada sistem file lokal.

Ini memiliki opsi bawaan untuk melakukan penyalinan di latar belakang, tetapi saya lebih suka menggunakan perintah layar dan melepaskan dari layar saat mc menyalin (saya pikir itu berjalan lebih cepat juga).

1
w-sky

Scp sederhana dengan opsi yang tepat akan dengan mudah mencapai 9-10 MB/s melalui LAN:

scp -C -c arcfour256 ./local/files.mp3 [email protected]:/opt/remote

Dengan opsi-opsi itu, kemungkinan throughput menjadi 4x atau 5x lebih cepat daripada tidak ada opsi (default)

1
user57125

Saya tidak berpikir Anda akan melakukan yang lebih baik daripada scp kecuali Anda memasang kartu jaringan yang lebih cepat. Jika Anda melakukan ini melalui internet, itu tidak akan membantu.

Saya akan merekomendasikan menggunakan rsync. Mungkin tidak lebih cepat, tetapi setidaknya jika gagal (atau Anda mematikannya karena terlalu lama), Anda dapat melanjutkan di mana Anda tinggalkan di waktu berikutnya.

Jika Anda dapat menghubungkan 2 mesin secara langsung menggunakan gigabit ethernet, itu mungkin yang tercepat.

1
Brent

Untuk 100Mb/s, throughput teoretis adalah 12,5 MB/s, jadi pada 10MB/s Anda melakukannya dengan cukup baik.

Saya juga akan mengulangi saran untuk melakukan rsync, mungkin melalui ssh. Sesuatu seperti:

rsync -avW -e ssh $SOURCE [email protected]$REMOTE:$DEST

Pada 100Mb/s CPU Anda harus mampu menangani enkripsi/dekripsi tanpa berdampak besar pada kecepatan data. Dan jika Anda mengganggu aliran data, Anda harus dapat melanjutkan dari tempat Anda tinggalkan. Hati-hati, dengan "jutaan" file, startup akan membutuhkan waktu sebelum benar-benar mentransfer apa pun.

1

Saya pernah mengalami ini, kecuali bahwa saya mentransfer log Oracle.

Inilah gangguannya

  • scp

    inefficient and encrypted (encrypted = slower than unencrypted 
    depending on the link and your processor) 
    
  • rsync

    efficient but typically encrypted (though not necessarily)
    
  • FTP/HTTP

    both seem to be efficient, and both are plaintext. 
    

Saya menggunakan FTP dengan sukses besar (di mana kesuksesan besar setara dengan ~ 700Mb/s pada jaringan Gb). Jika Anda mendapatkan 10MB (yang setara dengan 80MB/s), mungkin ada sesuatu yang salah.

Apa yang bisa Anda ceritakan tentang sumber dan tujuan data? Apakah itu drive tunggal ke drive tunggal? RAID ke USB?

Saya tahu pertanyaan ini sudah memiliki jawaban, tetapi jika jaringan Anda berjalan lambat pada kabel crossover Gb/s, sesuatu yang benar-benar perlu diperbaiki.

1
Matt Simmons

Berikut ini adalah patokan cepat untuk membandingkan beberapa teknik,

  • Source adalah CPU 4-core Intel (R) Xeon (R) E5-1620 @ 3.60GHz dengan 250 Mbps dan drive SATA
  • Destination adalah CPU 6-core Intel (R) Xeon (R) E-2136 @ 3.30GHz dengan bandwidth 1 Gbps dan drive SSD

Jumlah file: 9632, Ukuran total: 814 MiB, Ukuran rata-rata: 84 KiB

  • RSYNC: 1m40.570s
  • RSYNC + KOMPRESI: 0m26.519s
  • TAR + NETCAT: 1m58.763s
  • TAR + KOMPRESI + NETCAT: 0m28.009s

Perintah untuk tar/netcat adalah:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -
1
Antares

Jika Anda mengirim lebih dari MP3 dan file terkompresi lainnya, Anda tidak akan mendapat banyak manfaat dari solusi apa pun yang mencoba untuk mengompres file-file tersebut lebih lanjut. Solusinya akan menjadi sesuatu yang dapat membuat beberapa koneksi antara kedua server dan dengan demikian lebih menekankan pada bandwidth antara kedua sistem. Setelah ini maksimal, tidak banyak yang bisa diperoleh tanpa meningkatkan perangkat keras Anda. (Kartu jaringan yang lebih cepat antara server-server itu, misalnya.)

0
Wim ten Brink

Saya harus menyalin disk BackupPC ke komputer lain.

Saya menggunakan rsync.

Mesin memiliki 256 MB memori.

Prosedur yang saya ikuti adalah yang ini:

  • dieksekusi rsync tanpa -H (butuh 9 jam)
  • ketika rsync selesai, saya menyinkronkan direktori cpool dan mulai dengan direktori pc; Saya memotong transfer.
  • kemudian memulai kembali rsync dengan -H flag, dan semua file yang ditautkan dalam direktori pc telah ditransfer dengan benar (prosedur menemukan semua file nyata di cpool dan kemudian ditautkan ke direktori pc)) ( butuh 3 jam).

Pada akhirnya saya bisa memverifikasi dengan df -m bahwa tidak ada ruang tambahan yang dihabiskan.

Dengan cara ini saya menghindari masalah dengan memori dan rsync. Sepanjang waktu saya dapat memverifikasi kinerja menggunakan atas dan atas dan akhirnya saya mentransfer data 165GB.

0
Hector

Saya mencoba beberapa alat untuk menyalin file 1GB. Hasilnya adalah di bawah ini: HTTP tercepat, dengan wget -c nc dalam baris scp paling lambat, dan gagal beberapa kali. Tidak ada cara untuk melanjutkan rsync menggunakan ssh sebagai backend, dengan demikian hasilnya sama. Sebagai kesimpulan, saya akan pergi untuk http dengan wget -bqc dan berikan waktu. Semoga ini bisa membantu

0
Mijo

rsync atau Anda mungkin ingin menaruhnya jadi itu semua dalam satu file dan kemudian scp. Jika Anda tidak memiliki ruang disk, Anda dapat memasang tar secara langsung di atas ssh saat sedang dibuat.

0
Adam Gibbins