Şu anda iki CentOS sunucum var. Resim dizinini ve SCP'yi "tar" yapmak için nasıl ve en hızlı yolun ne olduğunu ve ne olduğunu öğrenmem gerekiyor?

Bu önerdiğim en hızlı yol mu? Çünkü tarring sonsuza kadar sürüyor ... Komutayı koştum:

tar cvf imagesbackup.tar images

Ve ben sadece onu taramak için gidiyordum.

Daha hızlı bir yol varsa bana bildirin. Her iki makineye de uzaktan / SSH erişimim var.

Yerel diskinize yazmak için tar kullanmak yerine, ssh kullanarak doğrudan uzaktaki sunucuya yazabilirsiniz.

server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"

"Ssh" komutunuzu izleyen herhangi bir dize, etkileşimli oturum açma yerine uzak sunucuda çalıştırılacaktır. Bu uzak komutlara giriş / çıkışları SSH üzerinden yerelmiş gibi yönlendirebilirsiniz. Komutu tırnak işaretleri içine almak, özellikle yönlendirme kullanırken karışıklığı önler.

Veya tar dosyasını diğer sunucudan doğrudan çıkarabilirsiniz:

server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"

Nadiren kullanılan -Cseçeneği not alın. "Bir şey yapmadan önce bu dizine değiştir" demek.

Veya, hedef sunucudan "çekmek" isteyebilirsiniz:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Not <(cmd) yapı vurmayı yeni ve eski sistemler üzerinde çalışmaz. Bir programı çalıştırır ve çıktıyı bir boruya gönderir ve bu boruyu bir dosya gibi komutun yerine koyar.

Yukarıdakileri kolayca kolayca şöyle yazabilirdim:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Veya aşağıdaki gibi:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Veya kendinize biraz keder kurtarabilir ve sadece rsync kullanabilirsiniz:

server1$ rsync -az ./path server2:/destination/

Son olarak, aktarımdan önce verileri sıkıştırmanın bant genişliğinizi azaltacağını unutmayın, ancak çok hızlı bir bağlantıda işlemin daha fazla zaman almasına neden olabilir . Bunun nedeni, bilgisayarınızın yetişmek için yeterince hızlı sıkıştırılamaması olabilir: 100 MB'lık sıkıştırmak 100 MB'lık göndermek daha uzun sürerse , sıkıştırılmamış göndermesi daha hızlı olur.

Alternatif olarak, sıkıştırma seviyesini belirtebilmeniz için (-z seçeneğini kullanmak yerine) kendinizi gzip ile borulamayı düşünebilirsiniz. Sıkıştırılabilir veriye sahip hızlı ağ bağlantılarında, seviye 2 veya 3'te gzip kullanarak (varsayılan 6'dır) çoğu durumda en iyi toplam verimi sağladığıma dair deneyimim oldu. Bunun gibi:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"

Kendim üzerinde rsync için cazip olmak isterdim - bu sıkıştırma yapar ve bağlantı kaybı iyi idare eder.

Eğer sadece tar katırsanız ve başka hiçbir şey yapmazsanız, bu sadece minimum hız kazancı ile zaman kaybettirir.

Bu yüzden sadece dosyaları cvf anahtarları ile düzenlemek, tüm 55GB görüntüleri okumak ve onları tekrar diske yazmak için harcadığınız süreyi etkili bir şekilde harcar. (Etkili bir ek yükü olacağı için etkili bir şekilde daha fazla zaman harcanacaktır).

Burada kazandığınız tek bir avantaj var, birçok dosya yüklemek için ek masraflar azaltılıyor. Görüntüleri sıkıştırırsanız daha hızlı aktarım süreleri elde edebilirsiniz (ancak sıkıştırılmış bir formatta olduklarına inanıyorum, bu pek yardımcı olmaz). Hesaplama zamanı sadece daha fazla atık.

Tel üzerinden devasa bir katran arşivini transfer etmenin en büyük dezavantajı, bir şey ters giderse baştan başlamanız gerektiği anlamına gelmesidir.

Bu şekilde kullanırdım:

md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/

Yeni sunucuda

md5sum /images/* > md5sum_new.txt

Ve sonra sadece diff. Ayrıca scp anında sıkıştırmayı desteklediğinden, ayrı arşivlere gerek kalmaz.

Düzenle

OP için faydalı olduğundan MD5 bilgilerini saklayacağım. Ancak bir yorum bana yeni bir kavrayışla vurdu. Bu yüzden biraz araştırma bu yararlı bilgiyi sağladı. Lütfen buradaki konunun doğrudan SCP değil SFTP olduğunu unutmayın .

FTP'nin aksine, SFTP dosya aktarımına ek yükü ekler. Bir dosya istemci ve sunucu arasında aktarıldığı için, "paketler" adı verilen daha küçük parçalara bölünür. Örneğin, her bir paketin 32KB olduğunu varsayalım. SFTP protokolü, gönderildiği gibi her 32KB dosya üzerinde bir sağlama toplamı yapar ve bu sağlama toplamı ile birlikte bu paketi içerir. Alıcı bu paketi alır ve verilerin şifresini çözer ve ardından sağlama toplamını doğrular. Sağlama toplamı, CRC32 sağlama toplamından daha güçlüdür. (SFTP, MD5 veya SHA gibi bir 128 bit veya daha yüksek sağlama toplamı kullandığından ve bu her pakette yapıldığından, aktarımın bir parçası olarak gerçekleştirilen çok taneli bir bütünlük kontrolü vardır.) Böylece protokol kendisi daha yavaştır (ek yük nedeniyle), ancak bir transfer aracının başarılı bir şekilde tamamlanması, fiili,

Pacey'nin md5sum önerisinin üzerine, aşağıdakileri kullanırdım:

Hedefte: nc -w5 -l -p 4567 | tar -xvf -

Ardından kaynakta: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Hala bir tar / untar, ve şifreleme yok, fakat diğer sunucuya direkt. İkisini de birbiri ardına başlatın ( -w5size 5 saniye zarafet verir). Bant genişliği kısıtlıysa, her iki uçtaki katrana -z ekleyin.

Bir nokta - tüm ana bilgisayarlar rsync'e sahip değildir ve ana bilgisayarlar farklı tar sürümlerine sahip olabilir. Bu nedenle, oft ihmal edilen cpio'yu kullanarak ilk arama limanı olarak önerilebilir.

Ana bilgisayarlar arasında dosya / dizin yapılarının geçici çoğaltmasını yapmak için ssh üzerinden cpio yapabilirsiniz. Bu şekilde, cpio'yu "beslemeye" ihtiyaç duyduğunuzda neyin gönderileceğini daha iyi kontrol edebilirsiniz, nom-nom. Aynı zamanda daha fazla taşınabilir - cpio fazla değişmez - eğer heterojen bir ortamda birden fazla ana bilgisayara bakıyorsanız bu önemli bir nokta.

Örnek kopya / ihracat / ev ve uzak ana bilgisayara alt dizinler:

cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'

Yukarıdakiler, / export / home içeriğini ve herhangi bir alt dizini uzak ana bilgisayardaki / export / home dizinine kopyalar.

Bu yardımcı olur umarım.

Ben ssh erişiminiz var, rsync erişiminiz var.

rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/

veya

rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/

"Rsync error: bazı dosyalar main.c'de (kod 23) aktarılamadı (kod 23)" gibi bir hata alırsanız, kullanıcı ve sunucular arasında grupları kontrol edin; bir uyumsuzluk olabilir.

Rsync'in aktarımı sıkıştırmasını istiyorsanız, rsync "-z" seçeneğini kullanın. Bu seçenek daha fazla CPU kullanır ancak daha az bant genişliği kullanır, bu yüzden bunun farkında olun.

Size yüzde transfer yapacak bir "- ilerleme" seçeneği var, bu tür bir şeyi sevdiyseniz hoş bir şey.

Dosyaları aktarmak için internete ihtiyaç duymak yerine paylaşılan bir ağdalar mı? NFS veya FTP, SCP'nin yükünden çok daha hızlı olabilir, ancak aktarım sırasında şifrelemeyi kaybedersiniz.

Veya her zaman katran boruları kullanabilirsiniz:

(cd /path && tar -cjf - * ) | ssh user@host 'tar -xjf - -C /path'

'j' = bzip2, tarınız destekliyorsa, gzip için 'z' ya da --lzma kullanabilirsiniz.