İki sunucu arasında çok sayıda dosyayı hızlı bir şekilde kopyalama

Harici sabit disk ve aynı gün kurye teslimi.

Rsync kullanırdım.

Bunları HTTP üzerinden dizin listeleri mevcut olarak dışa aktardıysanız, wget ve --mirror argümanını da kullanabilirsiniz.

Zaten HTTP'nin SCP'den daha hızlı olduğunu görüyorsunuz çünkü SCP her şeyi şifreliyor (ve böylece CPU'da darboğaz). HTTP ve rsync, şifrelemedikleri için daha hızlı hareket edecekler.

Ubuntu'da rsync kurulumu ile ilgili bazı dokümanlar: https://help.ubuntu.com/community/rsync

Bu dokümanlar SSH üzerinden rsync tünellemesinden bahsediyor, ancak sadece özel bir LAN'da veri taşıyorsanız SSH'ye ihtiyacınız yok. (Özel bir LAN'da olduğunuzu varsayıyorum. İnternet üzerinden 9-10MB/sn alıyorsanız, ne tür bağlantılarınız olduğunu bilmek istiyorum!)

Göreceli olarak güvensiz bir rsync sunucusu kurmanıza izin verecek diğer bazı temel dokümanlar (SSH'ye bağımlılık olmadan): http://transamrit.net/docs/rsync/

Fazla tartışma olmadan, netcat, ağ İsviçre bıçağı kullanın. Protokol yükü yok, doğrudan ağ soketine kopyalama yapıyorsunuz. Misal

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

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

Çok sayıda dosya ile rsync ile giderseniz, Ben her iki uçta sürüm 3 veya üstü almaya çalışacağız. Bunun nedeni, daha küçük bir sürümün aktarımı başlatmadan önce her dosyayı numaralandırmasıdır. Yeni özelliğe artımlı özyineleme denir.

Artık rsync başka bir 3.x sürümüyle konuşurken yeni bir artımlı özyineleme algoritması kullanılmaktadır. Bu aktarımın daha hızlı başlamasını sağlar (tüm dosyalar bulunmadan önce) ve çok daha az bellek gerektirir. Bazı kısıtlamalar için kılavuzdaki --recursive seçeneğine bakın.

rsync, diğerleri gibi zaten tavsiye etti. Şifrelemenin CPU yükü bir darboğaz ise, blowfish gibi daha az CPU yoğun bir algoritma kullanın. Örneğin. gibi bir şey

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

Dün 80 TB veri (milyonlarca küçük dosya) taşınırken, rsync yerine tararasında geçiş yapıldı denemeyi bıraktığımız için çok daha hızlı

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

ve bunun yerine tar olarak değiştirildi ...

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

Bu sunucular aynı LAN üzerinde olduğundan, hedef, kaynak sistemine NFS'ye monte edilir, bu da Push'u yapar. Daha da hızlı hale getirmeyin, dosyaların atime değerini korumamaya karar verdik:

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

Aşağıdaki grafik, rsync'ten katran'a yapılan değişikliği göstermektedir. Benim patronumun fikriydi ve meslektaşım hem onu ​​yürüttü hem de blogunda büyük yazma . Sadece güzel resimlerden hoşlanıyorum. :)

Çok sayıda dosyayı kopyalarken, tar ve rsync gibi araçların, birçok dosyayı açma ve kapatma yükü nedeniyle olması gerekenden daha verimsiz olduğunu gördüm. Bu senaryolar için katrandan daha hızlı olan hızlı arşivleyici adlı açık kaynaklı bir araç yazdım: https://github.com/replicon/fast-archiver ; birden fazla eşzamanlı dosya işlemi gerçekleştirerek daha hızlı çalışır.

İşte iki milyondan fazla dosyanın yedeklemesinde hızlı arşivleyici ve katran örneği; fast-archiver arşivlemek için 27 dakika, tar 1 saat 23 dakika sürer.

$ 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

Sunucular arasında dosya aktarmak için ssh ile hızlı arşivleyici kullanabilirsiniz, örneğin:

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

Katranı netcat yaklaşımıyla da kullanıyorum, ancak socat - durumunuz için optimize etmek için çok daha fazla güç kullanmayı tercih ediyorum - örneğin, mss ayarlayarak. (Ayrıca, isterseniz gülün, ancak socat argümanlarını hatırlaması daha kolay buluyorum çünkü tutarlılar. Yani benim için, son zamanlarda işleri yeni sunuculara taşıdığım için çok yaygın:

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

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

Takma adlar isteğe bağlıdır.

• Ağ Dosya Sistemi (NFS) seçin ve istediğiniz gibi kopyalayın, ör. Geceyarısı Komutanı (mc), Nautilus (cüceden). NFS v3'ü iyi sonuçlarla kullandım.
• Samba (CIFS) ve daha sonra dosyaları istediğiniz herhangi bir şeyle kopyalayın, ancak ne kadar verimli olduğu hakkında hiçbir fikrim yok.
• [~ # ~] http [~ # ~] ile wget --mirror as Evan Anderson önerdi veya başka bir http istemcisi. Kötü sembolik işaretlere veya yanıltıcı dizin dosyalarına sahip olmamaya dikkat edin. Eğer sahip olduğunuz tek şey MP3 ise güvende olmalısınız.
• rsync . Oldukça iyi sonuçlarla kullandım ve Nice özelliklerinden biri, aktarımı daha sonra kesip devam ettirebilmenizdir.

Başkalarının netcat kullanılmasını önerdiğini fark ettim. benim deneyimim onunla diğer çözümlere kıyasla yavaş olduğunu söyleyebilirim.

Üst cevapta birkaç yazım hatası olabilir. Bu daha iyi olabilir:

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

Scott Pack'in harika cevabı sayesinde (bunu daha önce ssh ile nasıl yapacağımı bilmiyordum), bu iyileştirmeyi sunabilirim (bash Shell'inizse). Bu, paralel sıkıştırma, bir ilerleme göstergesi ekleyecek ve ağ bağlantısı boyunca bütünlüğü kontrol edecektir:

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 borunuz için güzel bir ilerleme görüntüleme programıdır ve pigz CPU'nuzun varsayılan olarak sahip olduğu kadar çok iş parçacığı kullanan paralel bir gzip programıdır (8 maks. kadar inanıyorum). Sıkıştırma seviyesini CPU'nun ağ bant genişliğine oranına daha iyi uyacak şekilde ayarlayabilir ve pxz -9e ve pxz -d bant genişliğinden çok daha fazla CPU'nuz varsa. Yalnızca iki toplamın tamamlandıktan sonra eşleştiğini doğrulamanız gerekir.

Bu seçenek, çok yüksek miktarda veri ve yüksek gecikmeli ağlar için yararlıdır, ancak bağlantı kararsızsa ve düşerse çok yararlı değildir. Bu durumlarda, rsync muhtemelen devam edebileceği en iyi seçimdir.

Örnek çıktı:

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

Blok cihazlar için:

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
    '

Açıkçası, count =, skip =, seek =, vb. İle aynı boyutta veya sınırda olduğundan emin olun.

Dosya sistemlerini bu şekilde kopyaladığımda, ilk önce dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs, xfer'ı hızlandıran kullanılmayan alanın çoğunu sıfıra indirir.

Başka bir alternatif nison . Bu durumda Rsync'den biraz daha verimli olabilir ve bir dinleyici kurmak biraz daha kolaydır.

İki makinenin aynı LAN'da olup olmadığından veya güvenli bir kanalın (yani SSH kullanarak) zorunlu olduğundan bahsetmediniz, ancak kullanabileceğiniz başka bir araç netcat .

Alıcı makinede aşağıdakileri kullanırdım:

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

Sonra gönderen tarafta:

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

Aşağıdaki avantajlara sahiptir:

• Ssh'nin sahip olduğu şifreleme için CPU ek yükü yoktur.
• gzip -1 CPU'yu doyurmadan hafif sıkıştırma sağlar, böylece iyi bir değiş tokuş yapar ve maksimum verimi korurken biraz sıkıştırma sağlar. (Muhtemelen MP3 verileri için bu avantajlı değildir, ancak incinmez.)
• Dosyaları gruplara ayırabiliyorsanız, iki veya daha fazla boruyu paralel olarak çalıştırabilir ve ağ bant genişliğinizi doyurduğunuzdan emin olabilirsiniz.

örneğin.,

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

Notlar:

• Ne şekilde transfer ederseniz edin, muhtemelen her şeyi aldığınızdan emin olmak için bir rsync veya nison çalıştırırdım.
• İsterseniz tar yerine cpio kullanabilirsiniz.
• Eğer ssh kullanarak bitirseniz bile, herhangi bir sıkıştırma kullanmamasını ve gzip -1 yerine CPU doygunluğu önlemek için kendiniz. (Veya en azından CompressionLevel değerini 1 olarak ayarlayın.)

Src tarafında ftp sunucunuz varsa ncftp site adresinden ncftpget kullanabilirsiniz. Dahili olarak tar kullandığından küçük dosyalarla kaymakam çalışır.

Bir karşılaştırma şunu gösterir: 1,9 GB'lık küçük dosyaları (33926 dosya) taşıma

1. Scp kullanımı 11m59s alır
2. RSync kullanımı 7 dakika sürer
3. Ncftpget kullanmak 1m20s alır

Aktarımınızı yapmak için BBCP komutunu kullanmayı da deneyebilirsiniz. Gerçekten çığlık atan tamponlu paralel ssh. Boruyu beslememiz koşuluyla genellikle% 90 + hat oranı alabiliriz.

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

Normalde, yeterince hareket etmek zorunda kalmamak için çok çalışıyoruz. Her zaman daha fazla disk alanı ekleyebileceğimiz ZFS havuzlarını kullanıyoruz. Ama bazen ... sadece bir şeyler taşımak zorundasın. Eğer tam patlama sırasında bile kopyalamak saatler (veya günler) sürebilir bir "canlı" dosya sistemimiz varsa .. biz ole iki adım zfs rutin göndermek yapmak:

1. Bir ZFS anlık görüntüsü oluşturun ve yeni makinedeki yeni havuza aktarın. Sürdüğü sürece alsın.
2. İkinci bir enstantane yapın ve artımlı olarak gönderin. Artımlı enstantane sadece ilkinden beri (çok daha küçük) değişiklik setini içerir, bu yüzden nispeten hızlı geçer.
3. Artımlı anlık görüntü tamamlandığında, orijinal belgeyi döndürebilir ve yeni kopyaya kesebilirsiniz ve "çevrimdışı kapalı kalma süreniz" minimumda tutulur.

Ayrıca zfs dökümlerimizi BBCP üzerinden de gönderiyoruz ... ağ kullanımımızı en üst düzeye çıkarıyor ve aktarım sürelerini en aza indiriyor.

BBCP serbestçe kullanılabilir, Google'a gidebilirsiniz ve düz ileri bir derleme. Sadece src ve hedef makinelerde/usr/local/bin'e kopyalayın ve hemen hemen işe yarayacak.

Cevabım burada biraz geç, ama SFTP üzerinden diğer sunucuya bağlanmak için bir sunucuda mc (Midnight Commander) kullanarak iyi deneyimler kazandım.

FTP üzerinden bağlanma seçeneği, aşağıdaki gibi adres girilerek "Sol" ve "Sağ" menülerdedir:

/#ftp:[email protected]/

veya

/#ftp:[email protected]/

Yerel bir dosya sisteminde olduğu gibi dosya işlemlerinde gezinebilir ve yapabilirsiniz.

Arka planda kopyalama yapmak için yerleşik bir seçeneği vardır, ancak mc kopyalama sırasında ekran komutunu kullanmayı ve ekrandan ayırmayı tercih ederim (o zaman çok daha hızlı çalıştığını düşünüyorum).

RSync seçeneğinin cevabını @scottpack etmek için

Yüklemenin ilerlemesini görüntülemek için, aşağıda gösterildiği gibi komutta -avW'den sonra '--progess' seçeneğini kullanın.

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

Uygun seçeneklere sahip basit bir scp, LAN üzerinden 9-10 MB/s'ye kolayca ulaşacaktır:

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

Bu seçeneklerle, iş hacminin seçeneklerden 4x veya 5x daha hızlı olması muhtemeldir (varsayılan)

Daha hızlı ağ kartları takmadıkça scp'den daha iyisini yapacağınızı sanmıyorum. Bunu internet üzerinden yapıyorsanız, bu yardımcı olmaz.

rsync kullanmanızı tavsiye ederim. Daha hızlı olmayabilir, ancak en azından başarısız olursa (veya çok uzun sürdüğü için kapatırsanız), bir dahaki sefere kaldığınız yerden devam edebilirsiniz.

2 makineyi doğrudan gigabit ethernet kullanarak bağlayabiliyorsanız, bu muhtemelen en hızlısı olacaktır.

100Mb/s için teorik verim 12.5 MB/s'dir, bu nedenle 10MB/s'de oldukça iyi iş çıkarırsınız.

Ben de rsync, muhtemelen ssh aracılığıyla öneri yankı. Gibi bir şey:

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

100Mb/s'de CPU'larınız veri hızını önemli ölçüde etkilemeden şifreleme/şifre çözme işlemini gerçekleştirebilmelidir. Ve veri akışını kesintiye uğratırsanız, kaldığınız yerden devam edebilmeniz gerekir. Dikkat edin, "milyonlarca" dosya ile başlangıç ​​aslında bir şey aktarmadan önce biraz zaman alacaktır.

Oracle günlüklerini aktarmam dışında bununla karşılaştım.

İşte arıza

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

FTP'yi büyük bir başarıyla kullandım (büyük başarının bir Gb ağında ~ 700Mb/s'ye eşdeğer olduğu yerlerde). 10 MB (80Mb/s'ye eşit) alıyorsanız, bir şeyler yanlış olabilir.

Verilerin kaynağı ve hedefi hakkında bize neler söyleyebilirsiniz? Tek sürücüden tek sürücüye mi? USB'ye RAID mi?

Bu sorunun zaten bir cevabı olduğunu biliyorum, ancak ağınız bir Gb/s geçit kablosunda bu kadar yavaş gidiyorsa, bir şeyin kesinlikle düzeltilmesi gerekiyor.

İşte bazı teknikleri karşılaştırmak için hızlı bir karşılaştırma,

• Kaynak, 250 Mbps ve SATA sürücülü 4 çekirdekli Intel (R) Xeon (R) CPU E5-1620 @ 3.60GHz
• Hedef, 1 Gbps bant genişliği ve SSD sürücülü 6 çekirdekli Intel (R) Xeon (R) CPU E-2136 @ 3.30GHz

Dosya sayısı: 9632, Toplam boyut: 814 MiB, Ortalama boyut: 84 KiB

• RSYNC: 1m40.570s
• RSYNC + SIKIŞTIRMA: 0m26.519s
• TAR + NETCAT: 1 dk58.763s
• TAR + SIKIŞTIRMA + NETCAT: 0m28.009s

Tar/netcat için komut:

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

MP3 ve diğer sıkıştırılmış dosyalar üzerinden gönderiyorsanız, bu dosyaları daha fazla sıkıştırmaya çalışan herhangi bir çözümden fazla kazanç elde edemezsiniz. Çözüm, her iki sunucu arasında birden çok bağlantı oluşturabilen ve böylece iki sistem arasındaki bant genişliği üzerinde daha fazla stres yaratabilecek bir şey olacaktır. Bu en üst düzeye çıktıktan sonra, donanımınızı geliştirmeden kazanılabilecek çok şey yoktur. (Örneğin, bu sunucular arasında daha hızlı ağ kartları.)

BackupPC diskini başka bir makineye kopyalamak zorunda kaldım.

Rsync kullandım.

Makinede 256 MB bellek vardı.

Takip ettiğim prosedür şuydu:

• rsync olmadan -H (9 saat sürdü)
• rsync tamamlandığında, cpool dizinini senkronize ettim ve pc diziniyle başladım; Aktarımı kestim.
• daha sonra rsync ile -H bayrağı ve pc dizinine sabit bağlantılı tüm dosyalar doğru şekilde aktarıldı (prosedür cpool içindeki tüm gerçek dosyaları buldu ve sonra pc dizinine bağlandı) ( 3 saat sürdü).

Sonunda df -m fazladan alan harcanmamış.

Bu şekilde, bellek ve rsync ile ilgili sorunu ortadan kaldırıyorum. Her zaman performansı üst ve üstüne kullanarak doğrulayabilirim ve sonunda 165GB veri aktardım.

1GB dosyasını kopyalamak için birkaç araç denedim Sonuç aşağıda: HTTP en hızlı, wget -c nc ikinci satır scp ile en yavaş ve birkaç kez başarısız oldu. Rsync'i sürdürmenin hiçbir yolu ssh'yi arka uç olarak kullanmaz, dolayısıyla aynı sonuç. Sonuç olarak, http için wget -bqc ile gider ve biraz zaman verir. Umarım bu yardımcı olur

rsync ya da hepsini tek bir dosya içinde tar ve sonra scp. Disk alanından yoksunsanız, katranı yapılırken doğrudan ssh üzerine borulayabilirsiniz.