it-swarm.com.de

Wie kann ich am besten eine große Anzahl kleiner Dateien über scp kopieren?

Ich habe ein Verzeichnis mit mehreren Gigabyte und mehreren tausend kleinen Dateien. Ich möchte es mehr als einmal mit scp über das Netzwerk kopieren. Die CPU-Zeit auf den Quell- und Zielcomputern ist günstig, aber der durch das Kopieren jeder Datei einzeln hinzugefügte Netzwerkaufwand ist enorm. Ich würde es tar/gzip up und versenden, aber der Quellcomputer ist kurz auf der Festplatte.

Gibt es eine Möglichkeit für mich, die Ausgabe von tar -czf <output> <directory> zu scp? Wenn nicht, gibt es eine andere einfache Lösung? Mein Quellcomputer ist uralt (SunOS), daher möchte ich lieber keine Dinge darauf installieren.

63
nmichaels

Sie können Teer über eine SSH-Sitzung leiten:

$ tar czf - <files> | ssh [email protected] "cd /wherever && tar xvzf -"
110
pdo

Tar mit bzip2-Komprimierung sollte das Netzwerk und die CPU so stark entlasten.

$ tar -C /path/to/src/dir -jcf - ./ | ssh [email protected] 'tar -C /path/to/dest/dir -jxf -'

Verwenden Sie -v Nicht, da die Bildschirmausgabe den Prozess verlangsamen kann. Wenn Sie jedoch eine ausführliche Ausgabe wünschen, verwenden Sie diese auf der lokalen Seite von tar (-jcvf), Nicht auf der Remote-Seite.

Wenn Sie wiederholt über denselben Zielpfad kopieren, z. B. eine Sicherungskopie aktualisieren, ist rsync mit Komprimierung die beste Wahl.

$ rsync -az -e ssh /path/to/src/dir/ [email protected]:/path/to/dest/dir/

Beachten Sie, dass sowohl der src- als auch der dest-Pfad mit einem/enden. Wenn Sie die Flags -v Und -P Nicht absichtlich verwenden, fügen Sie sie hinzu, wenn Sie eine ausführliche Ausgabe benötigen.

23
forcefsck

benutze rsync , es benutzt SSH.

Verwendungszweck:

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

Die rsync-Switches kümmern sich um Komprimierungs- und I-Node-Informationen. -P Zeigt den Fortschritt jeder Datei an.

Sie können scp -C Verwenden, um die Komprimierung zu aktivieren. Verwenden Sie jedoch nach Möglichkeit rsync.

16
polemon

Sie können tar an beiden Enden mit ssh ausführen. scp ist Teil der ssh Familie der Güte, also haben Sie es wahrscheinlich an beiden Enden.

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

Möglicherweise gibt es eine Möglichkeit, gzip oder bzip2 in die Pipeline einzubinden, um auch den Netzwerkverkehr zu verringern.

3
Bruce Ediger

Die Antwort von @ pdo ist gut, aber man kann die Geschwindigkeit mit einem Puffer und einer guten Komprimierung erhöhen und einen Fortschrittsbalken hinzufügen.

Oft ist das Netzwerk der Engpass und die Geschwindigkeit variiert im Laufe der Zeit. Daher ist es hilfreich, die Daten zu puffern, bevor sie über das Netzwerk gesendet werden. Dies kann mit pv erfolgen.

Zusätzlich kann man normalerweise die Geschwindigkeit mit einem geeigneten Komprimierungsalgorithmus erhöhen. Gzip (wie oben verwendet) ist ein schneller Komprimierungsalgorithmus, aber im Allgemeinen wird zstandard (zstd) (und für hohe Komprimierungsverhältnisse LZMA/LZMA2 (xz) besser komprimiert und gleichzeitig schneller Neue xz und zstd verfügen bereits über eine integrierte Multi-Core-Unterstützung. Zur Verwendung von gzip mit mehreren Kernen kann pigz verwendet werden.

Hier ist ein Beispiel zum Senden von Daten mit einem Fortschrittsbalken, Pufferung und zstandard-Komprimierung über ein Netzwerk:

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

Das erste pv zeigt den Fortschritt ( p ), die geschätzte Zeit ( e ), Übertragungsrate ( r ), Durchschnittsrate ( a ), insgesamt übertragene Bytes ( b ). Die Gesamtgröße wird mit du geschätzt und zur Größenoption ( s ) hinzugefügt. Der Fortschritt wird vor dem Komprimieren und Puffern gemessen, daher ist er nicht sehr genau, aber dennoch hilfreich.

zstd wird mit der Komprimierungseinstellung 14 verwendet. Diese Anzahl kann je nach Netzwerk- und CPU-Geschwindigkeit verringert oder erhöht werden, sodass zstd etwas schneller als die Netzwerkgeschwindigkeit ist. Mit vier Kernen auf einer Haswell 3,2-GHz-CPU ergibt 14 eine Geschwindigkeit von ca. 120 MB/s. Im Beispiel wird der Long-Modus 31 (verwendet ein 2-GB-Fenster, benötigt viel RAM, ist aber sehr gut, z. B. zum Komprimieren von Datenbank-Dumps) . Mit den Optionen T0 wird die Anzahl der Threads auf die Anzahl der Kerne festgelegt. Man sollte sich bewusst sein, dass diese Einstellungen zusammen mit dem langen Modus viel Speicher verbrauchen.

Ein Problem mit zstd ist, dass die meisten Betriebssysteme nicht mit Version> = 1.3.4 ausgeliefert werden. Diese Version ist für eine ordnungsgemäße Multi-Core- und lange Unterstützung erforderlich. Wenn nicht verfügbar, kann es von https://github.com/facebook/zstd mit nur make -j4 && Sudo make install Kompiliert und installiert werden. Anstelle von zstd kann man auch xz oder pigz verwenden. xz ist langsam, komprimiert aber sehr gut (gut über langsame Verbindungen), pigz/gzip ist schnell, komprimiert aber nicht so gut. pv wird dann erneut verwendet, aber zum Puffern (q für leise, C für den No-Splice-Modus [immer zum Puffern benötigt] und B zum Setzen die Puffergröße).

Im Beispiel wird auch auf der Empfängerseite ein Puffer verwendet. Dies ist häufig nicht erforderlich (da die Dekomprimierungs- und Festplattenschreibgeschwindigkeit meistens höher ist als die Netzwerkgeschwindigkeit), schadet aber normalerweise auch nicht.

3
Fabian Heller

Wenn Sie an beiden Enden gzip haben: sourcehost$ cd sourcedir && tar cf - . | gzip -c - | ssh [email protected] "cd destinationdir && gzip -c -d | tar xf -"

Wenn Sie gzip nicht auf dem Quellcomputer haben, stellen Sie sicher, dass Sie das Ziel dekomprimiert haben: sourcehost$ cd sourcedir && tar cf - . | compress | ssh [email protected] "cd destdir && uncompress | tar xf -"

Dies wäre schneller, als es zuerst zu komprimieren, dann zu senden und dann zu entpacken, und es erfordert keinen zusätzlichen Speicherplatz auf beiden Seiten. Ich habe die Komprimierungsflagge (z) auf Teer gesetzt, weil Sie sie wahrscheinlich nicht auf der alten Seite haben.

2
MattBianco

Oder Sie können es umgekehrt machen, wenn Sie müssen. Das heißt, ziehen Sie den Tarball über das Netzwerk, anstatt ihn wie vorgeschlagen zu pushen. Dies löst nicht den sich wiederholenden Teil Ihrer Frage und rsync ist dafür am besten geeignet, aber es gibt wahrscheinlich Tar-Schalter, die helfen.

Also auf dem lokalen Computer:

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

Am besten zuerst im richtigen Verzeichnis sein oder am Ende den Schalter -C für den Befehl untaring verwenden.

Erwähnen Sie dies nur, falls dies erforderlich ist. Es ist für mich so, dass in meiner Situation mein lokaler Server hinter nat liegt.

HTH

2
DaveQB

Oder mounten Sie das Remote-Dateisystem über sshfs

sshfs [email protected]:/path/on/remote /path/on/local
1
ivanivan

Obwohl es nicht das eleganteste ist, zumal es keine einzige Zip- oder TAR-Datei kopiert und doppelt, da es nicht dazu beiträgt, den Netzwerk-Overhead zu reduzieren, war meine einzige Wahl die Verwendung von scp -r:

-r

      Kopieren Sie rekursiv ganze Verzeichnisse. Beachten Sie, dass scp symbolischen Links folgt, die beim Durchlaufen des Baums auftreten.
Quelle: scp (1)

Ich hatte Probleme mit dem Speicherplatzmangel mit einer 30 GB komprimierten TAR-Datei. Ich dachte, gunzip könnte dies inline tun, d. H. Das Original beim Entpacken entfernen (und ich habe möglicherweise ein Google-Ergebnis verpasst), aber ich konnte nichts finden.

Da ich es satt hatte, mehrmals darauf zu warten, dass eine neue TAR- oder Zip-Datei fertig ist, habe ich endlich Folgendes getan:

  1. Navigieren Sie vom ursprünglichen Server/PC/Laptop zu dem Verzeichnis, in dem sich Ihr Ordner mit zahlreichen Dateien/Ordnern befindet.
  2. scp -r source_folder_nameyourname@yourservername:destination_folder_name

Dann nimm einfach ein Bier, Kaffee oder Popcorn und warte. Gut ist, dass scp es erneut versucht, wenn die Netzwerkverbindung "blockiert". Hoffe nur, dass es nicht ganz runter geht.

1
JGlass