Salin file besar dari satu server Linux ke yang lain

Saya mencoba menyalin 75 gigabyte tgz (mysql lvm snapshot) dari server Linux di pusat data LA kami ke server Linux lain di pusat data NY kami melalui tautan 10MB.

Saya mendapatkan sekitar 20-30Kb / s dengan rsync atau scp yang berfluktuasi antara 200-300 jam.

Saat ini ini adalah tautan yang relatif sepi karena pusat data kedua belum aktif dan saya mendapatkan kecepatan yang sangat baik dari transfer file kecil.

Saya telah mengikuti berbagai panduan penyetelan tcp yang saya temukan melalui google tetapi tidak berhasil (mungkin saya membaca panduan yang salah, dapat yang bagus?).

Saya telah melihat ujung terowongan tar + netcat, tetapi pemahaman saya adalah bahwa itu hanya baik untuk BANYAK file kecil dan tidak memperbarui Anda ketika file secara efektif selesai mentransfer.

Sebelum saya melakukan pengiriman hard drive, apakah ada yang punya input bagus?

UPDATE: Yah ... mungkin itu tautannya :( Lihat tes saya di bawah ...

Transfer dari NY ke LA:

Mendapatkan file kosong.

[nathan@laobnas test]$ dd if=/dev/zero of=FROM_LA_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.412 seconds, 164 MB/s
[nathan@laobnas test]$ scp -C obnas:/obbkup/test/FROM_NY_TEST .
FROM_NY_TEST                                    3%  146MB   9.4MB/s   07:52 ETA

Mendapatkan tarball snapshot.

[nathan@obnas db_backup]$ ls -la db_dump.08120922.tar.gz
-rw-r--r-- 1 root root 30428904033 Aug 12 22:42 db_dump.08120922.tar.gz

[nathan@laobnas test]$ scp -C obnas:/obbkup/db_backup/db_dump.08120922.tar.gz .
db_dump.08120922.tar.gz            0%   56MB 574.3KB/s 14:20:40 ET

Transfer dari LA ke NY:

Mendapatkan file kosong.

[nathan@obnas test]$ dd if=/dev/zero of=FROM_NY_TEST bs=1k count=4700000
4700000+0 records in
4700000+0 records out
4812800000 bytes (4.8 GB) copied, 29.2501 seconds, 165 MB/s
[nathan@obnas test]$ scp -C laobnas:/obbkup/test/FROM_LA_TEST .
FROM_LA_TEST                                    0% 6008KB 497.1KB/s 2:37:22 ETA

Mendapatkan tarball snapshot.

[nathan@laobnas db_backup]$ ls -la db_dump_08120901.tar.gz
-rw-r--r-- 1 root root 31090827509 Aug 12 21:21 db_dump_08120901.tar.gz

[nathan@obnas test]$ scp -C laobnas:/obbkup/db_backup/db_dump_08120901.tar.gz .
db_dump_08120901.tar.gz                0%  324KB  26.8KB/s 314:11:38 ETA

Saya kira saya akan membahasnya dengan orang-orang yang menjalankan fasilitas kami, tautannya diberi label sebagai tautan 10MB MPLS / Ethernet. (mengangkat bahu)

Sneakernet Siapa Saja?

Dengan asumsi ini adalah salinan satu kali, saya kira tidak mungkin hanya menyalin file ke CD (atau media lain) dan bermalam ke tujuan apakah ada?

Itu mungkin benar-benar menjadi pilihan tercepat Anda sebagai transfer file sebesar itu, melalui koneksi itu, mungkin tidak menyalin dengan benar ... dalam hal ini Anda bisa memulai dari awal lagi.

rsync

Pilihan / usaha saya yang kedua adalah rsync karena mendeteksi transfer yang gagal, transfer parsial, dll. Dan dapat mengambil dari tempatnya.

rsync --progress file1 file2 user@remotemachine:/destination/directory

Bendera --progress akan memberi Anda beberapa umpan balik alih-alih hanya duduk di sana dan membuat Anda menebak diri sendiri. :-)

Vuze (bittorrent)

Pilihan ketiga mungkin untuk mencoba dan menggunakan Vuze sebagai server torrent dan kemudian minta lokasi jauh Anda menggunakan klien bitorrent standar untuk mengunduhnya. Saya tahu orang lain yang telah melakukan ini tetapi Anda tahu ... pada saat mereka mengatur semuanya berjalan, dll ... Saya bisa menyimpan data ...

Tergantung situasimu, kurasa.

Semoga berhasil!

MEMPERBARUI:

Anda tahu, saya sedikit memikirkan masalah Anda. Mengapa file tersebut harus menjadi tarball besar tunggal? Tar sangat mampu memecah file besar menjadi yang lebih kecil (untuk menjangkau media misalnya) jadi mengapa tidak membagi tarball besar itu menjadi potongan-potongan yang lebih mudah dikelola dan kemudian memindahkan potongan-potongan itu?

Saya telah melakukan itu di masa lalu, dengan file tbz2 60GB. Saya tidak memiliki skrip lagi tetapi harus mudah untuk menulis ulang.

Pertama, bagi file Anda menjadi ~ 2GB:

split --bytes=2000000000 your_file.tgz

Untuk setiap bagian, hitung hash MD5 (ini untuk memeriksa integritas) dan simpan di suatu tempat, kemudian mulai menyalin potongan dan md5 mereka ke situs jarak jauh dengan alat pilihan Anda (saya: netcat-tar-pipa di layar) sidang).

Setelah beberapa saat, periksa dengan MD5 jika bagian Anda baik-baik saja, maka:

cat your_file* > your_remote_file.tgz

Jika Anda juga telah melakukan MD5 dari file asli, periksa juga. Jika tidak apa-apa, Anda dapat menghapus file Anda, semuanya akan beres.

(Jika saya menemukan waktu, saya akan menulis ulang skrip)

Biasanya saya adalah penganjur besar rsync, tetapi ketika mentransfer satu file untuk pertama kalinya, sepertinya tidak masuk akal. Namun, jika Anda mentransfer kembali file dengan hanya sedikit perbedaan, rsync akan menjadi pemenang yang jelas. Jika Anda memilih untuk menggunakan rsync, saya sangat merekomendasikan menjalankan salah satu ujung dalam --daemonmode untuk menghilangkan terowongan ssh yang mematikan kinerja. Halaman manual menjelaskan mode ini dengan cukup teliti.

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 cepat.

Trik pipa netcat juga akan berfungsi dengan baik. Tar tidak diperlukan saat mentransfer satu file besar. Dan alasan itu tidak memberi tahu Anda ketika itu dilakukan adalah karena Anda tidak memberi tahu. Tambahkan -q0bendera ke sisi server dan itu akan berperilaku tepat 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 bahwa hal itu tidak akan memungkinkan Anda untuk melanjutkan jika transfer Anda mati 74GB di ...

Berikan tembakan pada netcat (kadang-kadang disebut nc). Berikut ini berfungsi pada direktori, tetapi harus cukup mudah untuk men-tweak hanya dengan mengatasi 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 melihat sedikit lebih cepat karena file sudah dikompresi.

SCP dan Rsync default (yang menggunakan SCP) sangat lambat untuk file besar. Saya kira saya akan melihat ke dalam menggunakan protokol dengan overhead yang lebih rendah. Sudahkah Anda mencoba menggunakan enkripsi enkripsi yang lebih sederhana, atau tidak sama sekali? Coba cari --rshopsi rsync untuk mengubah metode transfer.

Kenapa tidak FTP atau HTTP?

Meskipun itu menambah sedikit overhead pada situasi BitTorrent sebenarnya adalah solusi yang sangat bagus untuk mentransfer file besar. BitTorrent memiliki banyak fitur bagus seperti memotong file secara asli dan memeriksa setiap chunk yang dapat dikirim ulang jika rusak.

Sebuah program seperti Azureus [sekarang dikenal sebagai Vuze] berisi semua bagian yang perlu Anda buat, server & unduh torrent dalam satu aplikasi. Perlu diingat Azureus bukan yang paling ramping dari solusi yang tersedia untuk BitTorrent dan saya pikir memerlukan GUI juga - ada banyak alat torrent yang digerakkan oleh command line untuk linux.

Secara pribadi, 20-30Kb / s tampaknya cukup rendah untuk tautan 10Mb (dengan asumsi 10Mb dan bukan 10MB).

Jika saya adalah Anda, saya akan melakukan salah satu dari dua hal (dengan asumsi akses fisik tidak tersedia) -

Yang mana pun, saya sarankan Anda untuk membagi file besar menjadi potongan-potongan kecil, sekitar 500MB Hanya dalam kasus korupsi dalam perjalanan.

Ketika Anda memiliki potongan yang lebih kecil, gunakan rsync lagi, atau saya pribadi lebih suka menggunakan sesi ftp Secure pribadi, dan kemudian CRC file setelah selesai.

Beberapa pertanyaan mungkin membantu dalam diskusi: Seberapa penting data akan ditransfer? Apakah ini untuk pemulihan bencana, cadangan panas, penyimpanan offline atau apa? Apakah Anda bermaksud untuk membuat cadangan basis data saat sedang naik atau turun? Bagaimana dengan mengatur basis data di sistem jarak jauh dan tetap menyinkronkannya menggunakan pengelompokan atau pemutakhiran melalui changelogs (Saya tidak sepenuhnya memahami kemampuan sistem basis data MySql). Ini mungkin membantu mengurangi jumlah data yang perlu ditransfer melalui tautan.

bbcp akan memotong file untuk Anda dan menyalin dengan beberapa aliran.

Jawaban telat untuk googler:

Saat mentransfer dataset besar, rsync dapat digunakan untuk membandingkan sumber dan tujuan, kemudian menulis file batch ke media lepasan lokal menggunakan flag --on-write-batch. Anda kemudian mengirimkan media lokal ke lokasi jarak jauh, pasang, dan jalankan rsync lagi, menggunakan --read-batch untuk memasukkan perubahan ke dalam dataset jarak jauh.

Jika file sumber berubah selama transportasi fisik, atau jika media transportasi terisi, Anda dapat terus mengulangi - hanya-tulis-batch | kapal | --baca siklus -baca sampai tujuan tercapai.

(Ref: Saya adalah salah satu penulis fitur ini di rsync - untuk latar belakang dan kasus penggunaan yang lebih banyak, lihat diskusi tentang implementasi prototipe ini: https://lists.samba.org/archive/rsync/2005-March/011964 .html )