2 sunucu arasında milyonlarca dosyayı kopyalamanın en iyi yolu

Aynı gigabit ağındaki başka bir makineye kopyalamak istediğim tek bir dizinde yaklaşık 5 milyon küçük (5-30k) dosyam var. Rsync kullanmayı denedim, ancak birkaç saat çalıştıktan sonra sürünerek yavaşlayacaktı, rsync'in kaynak ve hedef dosyasını her seferinde kontrol etmesi gerektiğine inanıyorum?

İkinci düşüncem scp kullanmak olacaktır, ancak daha iyi bir yol olup olmadığını görmek için dışarıdan görüş almak istedim. Teşekkürler!

Böyle bir şey iyi çalışması gerekir:

tar c some/dir | gzip - |  ssh host2 tar xz

Belki de bir gigabit ağında olduğunuzdan, çıkartma için gzip ve "z" bayrağını atlayın.

Tüm FIVE MILLION dosyalarının tek bir dizinde bulunmasının birçok aracı tizzy'ye attığından eminim. Rsync'in bunu incelikle yerine getirmemesine şaşırmadım - bu oldukça "benzersiz" bir durum. Dosyaları bir tür dizin yapısına yapılandırmanın bir yolunu bulabilirseniz, rsync gibi standart senkronizasyon araçlarının çok daha duyarlı olacağından eminim.

Ancak, yalnızca bazı gerçek tavsiyeler vermek için - belki de bir çözüm, sürücüyü fiziksel olarak hedef makineye geçici olarak taşımaktır; böylece dosyaların asıl sunucudaki (ağ üzerinden değil) bir kopyasını alabilirsiniz. Ardından, sürücüyü geri alın ve işleri güncel tutmak için rsync kullanın.

Ayrıca bir kombinasyonunu kullanabilir (güvenilir bir ortamda) bir gigabit anahtar üzerinden dosyaları milyonlarca kopyalamak için netcat (or nc)ve tarzaten user55286 tarafından önerildiği gibi,. Bu, tüm dosyaları tek bir büyük dosya halinde yayınlar (bkz. Hızlı Dosya Kopyalama - Linux! (39 GB) ).

# requires netcat on both servers
nc -l -p 2342 | tar -C /target/dir -xzf -   # destination box
tar -cz /source/dir | nc Target_Box 2342    # source box

Bir dizinde yaklaşık 1 milyon dosya vardı (yaklaşık 4 yıllık dosya değerinde).

Ve dosyaları YYYY / MM dizinine taşımak için robokopi kullandık (ayda yaklaşık 35-45.000 dosya).

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081201 /MINAGE:20090101 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\12
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090101 /MINAGE:20090201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\01
ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20090201 /MINAGE:20090301 /MOV H:\Cs\out\fix H:\BCK_REPORT\2009\02

kısa notlar .. /ns /nc /nfl /nplog dosyasını şişirmekten kaçınmak için ek bilgilerle /log+...log dosyasına özet bilgiler yazmaktır.

/minage and /maxage is to copy files modified with in that date range. 

öyleyse, örneğin, değiştirilmiş dosyalar> = 01 / Kasım / 2008 (dahil), <01 / Aralık / 2008 değiştirilmiş (dahil değil) dosyalara

ROBOCOPY /NS /NC /NFL /NP /LOG+:H:\BCK_REPORT\ROBO.LOG /MAXAGE:20081101 /MINAGE:20081201 /MOV H:\Cs\out\fix H:\BCK_REPORT\2008\11

/mov dosyaları taşımak

sonra kaynak dizini geliyor

sonra hedef dizini (dizinler anında ve gerektiğinde oluşturulacak) gelir.

1 aylık transfer için yaklaşık 40 - 60 dakika sürdü (yaklaşık 35-45.000 dosya) 1 yıllık transfer için yaklaşık 12 saat veya daha az sürer.

Windows Server 2003'ü Kullanma.

Tüm şeyler log dosyasına kaydedilir ... Başlangıç ​​Saati, Bitiş Saati ve Kopyalanan dosya sayısı.

Robocopy günü kurtardı.

Bilirsin, katran çözümünü artı-1'ledim, ama - çevreye bağlı olarak - ortaya çıkan başka bir fikir var. Dd (1) kullanmayı düşünebilirsiniz . Bunun gibi bir şeyle ilgili hız sorunu, beş milyon kez yapacağınız bir dosyayı açmak ve kapatmak için birçok kafa hareketi gerektirmesidir. Bunların tartışmalı bir şekilde atanmasını sağlayabilirsiniz, bunun yerine onları hareket ettirebilirsiniz, bu da kafa hareketlerinin sayısını 5 veya daha fazla bir faktörle azaltır.

Şu anda en hızlı sıkıştırma aracı olarak lz4 kullanmayı tercih ediyorum . SSH seçeneği -c arcfour128 , varsayılandan daha hızlı şifreleme algoritması kullanır. [1]

Yani dizin transferi gibi bir şey görünüyor:

tar -c folder | lz4 -c | ssh -carcfour128 somehost 'lz4 -d | tar -x > folder'

Lütfen Debian lz4 komutunda lz4c olduğunu ve CentOS'ta da lz4 olduğunu unutmayın.

Robocopy bu gibi şeyler için mükemmeldir. Ağ zaman aşımlarından sonra tekrar deneyecek ve aynı zamanda boruyu gömmek için paketler arası bir boşluk gecikmesi ayarlamanıza olanak tanır.

[Düzenle]

Bunun yalnızca Windows uygulaması olduğunu unutmayın.

Bunun aptalca olabileceğini biliyorum - ama onları harici bir diske kopyalamayı ve diğer sunucuya taşımayı düşündünüz mü? Aslında en verimli ve basit çözüm olabilir.

Şu anda bu konuyu araştırıyoruz. Yaklaşık 200 milyon toplam - yaklaşık 18 milyon küçük dosya aktarmamız gerekiyor. Düz eski XCopy kullanarak en iyi performansı elde ettik, ancak yine de uzun zaman aldı. 1 sunucudan diğerine yaklaşık 3 Gün, harici bir sürücüye yaklaşık 2 hafta!

Başka bir işlemle sunucuyu çoğaltmamız gerekiyordu. Bu Acronis ile yapıldı. Yaklaşık 3 saat sürdü!

Bunu biraz daha araştıracağız. Yukarıdaki dd önerisi muhtemelen benzer sonuçlar verecektir.

Zaten tonlarca iyi öneri, ancak Beyond Compare'i atmak istedim . Geçenlerde 5 KB ile 20 MB arasında bir sunucudan diğerine bir gigabit anahtarı üzerinden yaklaşık 750.000 dosya aktardım. Hiç hıçkırık bile etmedi. Biraz zaman aldı, ancak bunu çok fazla veri ile beklerdim.

Bir zip-> copy-> unzip'in nasıl çalıştığını görürdüm

ya da en sevdiğiniz sıkıştırma / arşiv sistemi ne olursa olsun.

Kopyalamadan önce bunları tek bir dosyaya paketleyin, sonra kopyalandıktan sonra tekrar açın.

Benzer bir durumda, dosyaları toplu işlemek için tar kullanmaya çalıştım. Tar komutunun çıktısını doğrudan hedef makineye yönlendirmek için dosyaları birleştiren alıcı bir tar işlemine ufak bir senaryo yazdım.

Katran yaklaşımı, scp veya rsync (YMMV) ile karşılaştırıldığında transfer oranını neredeyse iki katına çıkardı.

İşte tar komutları. Her makinenin giriş dizininde .rhosts dosyaları oluşturarak r-komutlarını etkinleştirmeniz gerekeceğini unutmayın (kopyalama tamamlandıktan sonra bunları kaldırın - bunlar kötü güvenlik sorunlarıdır). Ayrıca, her zamanki gibi, HP-UX'in garip olduğunu - dünyanın geri kalanının uzak kabuk komutu için 'rsh', HP-UX 'remsh' kullandığını unutmayın. 'rsh', HP parlance'da bir çeşit kısıtlı kabuktur.

box1> cd source_directory; tar cf - . | remsh box2 "cd target_directory; tar xf - "

İlk tar komutu, bu durumda 'standart çıktı' anlamına gelen özel bir belirteç olan '-' adlı bir dosya oluşturur. Oluşturulan arşiv, geçerli dizindeki (.) Tüm dosyaları ve tüm alt dizinleri (tar varsayılan olarak özyinelemelidir) içerir. Bu arşiv dosyası, box2 makinesine gönderen remsh komutuna aktarılır. Kutu 2'de önce uygun alıcı dizine geçiyorum, sonra gelen dosyaları '-' ya da 'standart girdi' den çıkartıyorum.

Ağ bağlantısının verilerle doymasını sağlamak için aynı anda çalışan bu tar komutlarından 6'sı vardı, ancak disk erişiminin sınırlayıcı faktör olabileceğinden şüpheleniyorum.

Dosya sistemini atla.

Dosyaların üzerinde yaşadığı bu bölümü kaldırabilir veya salt okunur olarak bağlayabilir misiniz? Bunu yapın, sonra şöyle bir şey:

dd if=/dev/PARTITION | ssh username@host "dd of=diskimage.bin"

Daha sonra diskimage.bin, hedef tarafa bir geridöngü aygıtı olarak monte edebilir ve dosyaları asıl hedef dosya sisteminize kopyalayabilir veya hedef taraftaki boş bir bölüme geri dikmek için uygun araçları kullanabilirsiniz (tehlikeli, ancak muhtemelen mümkün olabilir). , ama ben hiç yapmadım.)

Gerçekten cesursanız, dddoğrudan hedef taraftaki bir bölüme dönebilirsiniz. Bunu tavsiye etmiyorum.

Aşağıdakileri deneyebilirsiniz (toplu dosyalarda olabilir)

• toplu iş dosyaları tar
• onları gzip
• eğer mümkünse scp kullanarak kopyala
• gunzip
• dosyaları aç

Sth tarafından önerildiği gibi ssh üzerinden tar deneyebilirsiniz.

Şifrelemeye ihtiyacınız yoksa (başlangıçta rsync kullandınız, ancak rsync + ssh olduğunu belirtmediyseniz), ssh ek yükünü önlemek için netcat üzerinden tar'ı deneyebilirsiniz.

Tabii ki, gzip veya başka bir sıkıştırma yöntemi kullanarak da geçen süreyi kısaltabilirsiniz.

Dikkate alınması gereken başka bir şey var. Bunu dene:

• Dinamik olarak boyutlandırılmış bir VHD oluşturun
• Takın, muhtemelen bir dizin olarak
• 'Diskin tamamını sıkıştır' özelliğini ayarlayın

Bunu yaparak, dizinin yinelenmesi veya sıkıştırılması için ek yük yoktur, çünkü dosyalar yazıldığı sırada yapıldı. Taşınacak tek bir dosya var - VHD.

Windows'ta varsayılan TCP paket boyutunu 16348 gibi daha büyük olacak şekilde ayarladım. Bu, daha az IP başlığı ek yükü anlamına gelir.

Bununla birlikte, karşılaştığım tek şey, bir ağ veya USB aktarımı için dosya boyutlarını 100 Mb'nin altında tutmanın en iyisi olmasıdır. Bunun için Rar.exe kullanıyorum - dosyaları bölmek için.

Bir şampiyon gibi çalışıyor. Bu Linux'ta 'dd' ye eşdeğerdir. Sıkıştırılmış bir dosya sistemini bir dizine bağlama kavramı Linux için de normaldir, bu yüzden aynı mantık geçerlidir. Diğer yöntemlerde olduğu gibi işlem başlamadan önce tüm dosyaların kapalı olduğundan emin olmalısınız.

Bu, bir klasöre bir boyut kotası koymayı mümkün kılma avantajına sahiptir. Eğer VHD sabit bir boyuta sahipse, bu sınırın aşılması sunucuyu düşürmez, sadece dosyayı oluştururken veya yazarken bir hataya neden olur.

NTFS olarak biçimlendirilmiş bir VHD, bir klasördeki milyonlarca dosyayı da işleyebilir.