Çok sayıda küçük dosyayı scp üzerinden en iyi nasıl kopyalayabilirim?


59

Birkaç gigabayt ve birkaç bin küçük dosya içeren bir dizin var. Bir kereden fazla scp ile ağ üzerinden kopyalamak istiyorum. Kaynak ve hedef makinelerde CPU zamanı ucuzdur, ancak her bir dosyayı ayrı ayrı kopyalayarak eklenen ağ ek yükü çok büyüktür. Onu tar / gzip ile gönderir ve gönderirdim, ancak kaynak makinesi diskte kısa.

tar -czf <output> <directory>Scp ' nin çıkışını borulamamın bir yolu var mı ? Olmazsa, başka bir kolay çözüm var mı? Kaynak makinem eskidir (SunOS) bu yüzden üzerine bir şeyler yüklememeyi tercih ederim.

Yanıtlar:


104

Katranı bir ssh oturumu boyunca yönlendirebilirsiniz:

$ tar czf - <files> | ssh user@host "cd /wherever && tar xvzf -"

3
+1 katranlı boru çözümü. Daha fazla bant genişliğine ve daha az CPU'ya sahipseniz, sıkıştırma bayrağını kaldırabilirsiniz (gzip oldukça hafif olmasına rağmen).
dietbuddha

2
Ve sıkıştırma bayrağını bırakıp bunun yerine SSH ( ssh -Cveya Compression yesiçinde ~/.ssh/config) özelliğini etkinleştirebilirsiniz .
sam hocevar

3
Asla böyle tar kullanmayı düşünmedim. İşte bu yüzden buraya geldim!
Bay Shickadance

2
Bu komut biraz daha kısa yapılabilir:$ tar cz <files> | ssh user@host "cd /wherever; tar xvz"
carlito

2
@ Dash, POSIX uyumlu bir yazılımda, bağlama bağlı olarak STDIN veya STDOUT anlamına gelen bir kuraldır. İlk çizgi '/ dev / stdin'den oku' anlamına gelir ve ikincisi - aslında uzak ana bilgisayarda yürütülen - '/ dev / stdin' anlamına gelir. Boru ve ssh bu iki işlemi birbirine bağlar. Daha fazla bilgi için unix.stackexchange.com/questions/16357/… adresine bakın .
Richard Metzler

22

Bzip2 sıkıştırmalı katran ağdan ve cpudan çok fazla yük almalıdır.

$ tar -C /path/to/src/dir -jcf - ./ | ssh user@server 'tar -C /path/to/dest/dir -jxf -'

-vEkran çıkışı işlemi yavaşlatabileceğinden kullanılmaması . Ancak ayrıntılı bir çıktı istiyorsanız -jcvf, uzak kısımda değil, tar ( ) yerel tarafında kullanın .

Tekrar tekrar aynı hedef yoldan kopyalarsanız, bir yedek kopyayı güncellemek gibi, en iyi seçiminiz sıkıştırmalı rsync'dir.

$ rsync -az -e ssh /path/to/src/dir/ user@server:/path/to/dest/dir/

Hem src hem de dest yollarının a / ile bittiğine dikkat edin. Yine, kullanmamak -vve -Pbilerek işaretlemek, ayrıntılı çıktıya ihtiyacınız varsa bunları ekleyin.


16

kullanın rsync, SSH kullanır.

Kullanımı:

rsync -aPz /source/path destination.server:remote/path

Rsync anahtarları sıkıştırma ve I-Node bilgileriyle ilgilenir. -Pher dosyanın ilerlemesini görüntüler.

Sen kullanabilirsiniz scp -Csıkıştırmayı sağlayan, fakat mümkünse kullanmayın rsync.


Maalesef, kaynak makinede rsync bulunmuyor ve sshd de yok.
nmichaels

1
İstemci makinedeki işlemler için sshd gerekli değildir.
polemon

3

Her tariki uçta da ssh kullanarak koşabilirsiniz . iyilik ailesinin bir scpparçası ssh, bu yüzden muhtemelen her iki ucunda da var.

 8:03AM 12 % tar cf - some_directory | ssh dest_host "tar xf -"

Ağ trafiğini azaltmak için gzip veya bzip2'yi boru hattına dahil etmenin bir yolu olabilir.


3

@ pdo'nin cevabı iyidir, ancak bir arabellek ve iyi bir sıkıştırma ile hızı artırabilir ve bir ilerleme çubuğu ekleyebilir.

Genellikle ağ darboğazıdır ve hız zamanla değişir. Bu nedenle, verileri ağ üzerinden göndermeden önce arabelleğe almanıza yardımcı olur. Bu ile yapılabilir pv.

Ek olarak, kişi genellikle uygun bir sıkıştırma algoritmasıyla hızı artırabilir. Gzip (yukarıda kullanıldığı gibi) hızlı bir sıkıştırma algoritmasıdır, ancak genel olarak zstandard ( zstd) (ve yüksek sıkıştırma oranları için LZMA / LZMA2 ( xz) daha iyi sıkıştıracak ve aynı zamanda daha hızlı olacaktır. Birden çok çekirdekli gzip kullanmak için pigz kullanılabilir.

İlerleme çubuğu, arabelleğe alma ve ağ üzerinde zstandard sıkıştırma ile veri gönderme örneği:

tar cf - . | pv -perabs $(du -sk . | cut -f 1)K | zstd -14 --long=31 -T0 | pv -qCB 512M | ssh user@host "cd /wherever && pv -qCB 512M | zstd -cd -T0 --long=31 | tar xf -"

Birincisi pv, ilerlemeyi ( p ), tahmini süreyi ( e ), transfer hızını ( r ), ortalama hızı ( a ), toplam aktarılan baytları ( b ) göstermektir. Toplam boyutu ile tahmin edilir duve boyut seçeneğiyle (ilave ler ). İlerleme sıkıştırma ve tamponlamadan önce ölçülür, bu nedenle çok doğru değil, yine de yardımcı olur.

zstdSıkıştırma ayarında 14 kullanılır . Bu sayı ağa ve CPU hızına bağlı olarak azaltılabilir veya arttırılabilir, böylece zstd ağ hızından biraz daha hızlıdır. Bir Haswell 3.2 GHz'de dört çekirdekli CPU 14 , yaklaşık 120 MB / s hıza sahip. Örnekte, uzun mod 31 (2 GB'lık bir pencere kullanır, çok fazla RAM gerektirir, ancak örneğin veritabanı dökümlerini sıkıştırmak için çok iyi) kullanılır. T0 seçenekleri çekirdek sayısı parçacığı miktarını ayarlar. Uzun ayarlarla birlikte bu ayarların çok fazla bellek kullandığının bilinmesi gerekir.

Zstd ile ilgili bir sorun, çoğu işletim sisteminin>> 1.3.4 sürümüyle birlikte gönderilmemesidir. Bu sürüm uygun çok çekirdekli ve uzun destek için gereklidir. Mevcut değil ise, derlenebilir ve yüklü https://github.com/facebook/zstd sadece birlikte make -j4 && sudo make install. Zstd yerine xz veya pigz de kullanılabilir. xz yavaştır, ancak çok iyi sıkıştırır (yavaş bağlantılara göre iyidir), pigz / gzip hızlıdır ancak çok iyi sıkıştırmaz. pvdaha sonra tekrar kullanılır, fakat tamponlama için ( qsessiz Ciçin, eksiz mod için [her zaman tamponlama için gerekli] ve Btampon boyutunu ayarlamak için) kullanılır.

Örnekte, alıcı tarafında da bir tampon kullanılmıştır. Bu genellikle gereksizdir (çünkü sıkıştırma ve sabit disk yazma hızı çoğu zaman ağ hızından daha yüksektir), ancak genellikle de zarar vermez.


2

Her iki ucunda da gzip varsa: sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh user@destinationhost "cd destinationdir && gzip -c -d | tar xf -"

Kaynak makinede gzip yoksa, hedefe sıkıştırılmamış olduğunuzdan emin olun: sourcehost$ cd sourcedir && tar cf - . | compress | ssh user@destinationhost "cd destdir && uncompress | tar xf -"

Bu, ilk önce sıkıştırmaktan, daha sonra göndermek, sonra açmaktan daha hızlı olacaktır ve her iki taraf için de fazladan disk alanı gerektirmez. Tar'da sıkıştırma (z) bayrağını sıktım, çünkü muhtemelen antik tarafta yoktur.


2

Ya da gerekirse başka şekilde de yapabilirsiniz. Bu tarball'ı ağ üzerinden çekmek yerine, itildiği gibi itmek. Bu, sorunuzun yinelenen bölümünü çözmez ve bunun için en iyisi rsync'dir, ancak muhtemelen yardımcı olacak katran anahtarları vardır.

Yani yerel makinede:

ssh remote 'tar zcf - /etc/resolv.conf' | tar zxf -

Önce doğru dizinde olmanız en iyisidir ya da sonunda untaring komutunda -C anahtarını kullanmanız gerekir.

Sadece ihtiyaç duyulması halinde bundan söz ediyorum. Benim için benim durumumdaki gibi yerel sunucum nat arkasında, bu yüzden daha önce bahsedildiği şekilde yapmak için biraz ağ fışkırmak alacaktı.

HTH


1

Veya uzak dosya sistemini sshfs ile bağlayın

sshfs user@remotehost:/path/on/remote /path/on/local

1

En şık olmasa da, özellikle tek bir zip veya tar dosyasını kopyalamadığından ve ağın genelini azaltmaya yardımcı olmadığından iki katına çıkmadığından, tek seçeneğim kullanmaktı scp -r:

-r

      Tüm dizinleri tekrar tekrar kopyalayın. Not scp ağacın enine karşılaşılan sembolik bağlantıları izler.
Kaynak: scp (1)

30 GB'lık sıkıştırılmış bir tar dosyasıyla disk alanınızın tükenmesiyle ilgili sorunlarla karşılaşıyordum. Gunzip'in satır içi yapabileceğini düşündüm, yani orijinali açıldığı sırada kaldırarak (ve bir Google sonucunu kaçırmış olabilirim) ancak hiçbir şey bulamadım.

Sonunda, tar ya da sıkıştırmayı bitirmek için yeni bir TAR ya da ZIP dosyasının beklemesini beklemekten bıktım çünkü sonunda yaptım:

  1. Orijinal sunucu / PC / dizüstü bilgisayardan, çok sayıda dosya / klasör içeren klasörünüzün bulunduğu dizine gidin.
  2. scp -r source_folder_name yourname@yourservername:destination_folder_name

O zaman biraz bira, kahve veya patlamış mısır alın ve bekleyin. İyi ki, ağ bağlantısı "durduğunda" scp yeniden denenecek. Umarım tamamen bitmez.


Tamam, bu açıkça binlerce scpkomut yazmadan daha az zaman alır . Ancak soru “ağ ek yükü” hakkında soruyor. Çözümünüz ağı her dosyayı ayrı ayrı kopyalamaktan daha az kullanıyor mu? Çözümünüz, daha önce bildirilmiş olan yedi kişiden daha üstün mü?
G-Man

Snap, benim kötüsüm - genel gider ağını tamamen kaçırdım - bunu gördüğünüz için teşekkürler @ G-Man. Cevabı güncelledim, birileri benim gibi bir soruna rastlarsa ve bu soruyu tökezlediğimde yine de yararlı olabileceğini düşünüyorum.
JGlass
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.