Schnellste Möglichkeit, 55 GB Bilder auf einen neuen Server zu übertragen

64

Ich habe derzeit zwei CentOS-Server. Ich muss wissen, wie und was der schnellste Weg wäre, um das Bilderverzeichnis zu "tarieren" und es zu scpen.

Ist das der schnellste Weg, den ich gerade vorgeschlagen habe, weil das Teern ewig dauert ... Ich habe den Befehl ausgeführt:

tar cvf imagesbackup.tar images

Und ich wollte es einfach durchgehen.

Lassen Sie mich wissen, ob es einen schnelleren Weg gibt. Ich habe Remote / SSH-Zugriff auf beide Maschinen.

Andrew Fashion
quelle
12
Sneakernet?
Nick T

Antworten:

98

Anstatt mit tar auf Ihre lokale Festplatte zu schreiben, können Sie mit ssh direkt über das Netzwerk auf den Remote-Server schreiben.

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

Alle Zeichenfolgen, die auf Ihren Befehl "ssh" folgen, werden auf dem Remoteserver anstelle der interaktiven Anmeldung ausgeführt. Sie können die Ein- / Ausgabe von und zu diesen Remote-Befehlen über SSH weiterleiten, als wären sie lokal. Wenn Sie den Befehl in Anführungszeichen setzen, werden Verwirrungen vermieden, insbesondere bei der Umleitung.

Oder Sie können die tar-Datei direkt auf dem anderen Server extrahieren:

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

Beachten Sie die selten verwendete -COption. Es bedeutet "Wechseln Sie zuerst in dieses Verzeichnis, bevor Sie etwas tun."

Oder möchten Sie vielleicht vom Zielserver "ziehen":

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

Beachten Sie, dass das <(cmd) Konstrukt für bash neu ist und auf älteren Systemen nicht funktioniert. Es führt ein Programm aus, sendet die Ausgabe an eine Pipe und ersetzt diese Pipe durch den Befehl, als wäre es eine Datei.

Ich hätte es einfach so schreiben können:

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

Oder wie folgt:

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

Oder Sie können sich etwas Kummer ersparen und einfach rsync verwenden:

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

Denken Sie schließlich daran, dass das Komprimieren der Daten vor der Übertragung Ihre Bandbreite verringert. Bei einer sehr schnellen Verbindung kann der Vorgang jedoch länger dauern . Dies liegt daran, dass Ihr Computer möglicherweise nicht schnell genug komprimiert, um Schritt zu halten. Wenn das Komprimieren von 100 MB länger dauert als das Senden von 100 MB, ist es schneller, es unkomprimiert zu senden.

Alternativ können Sie Piping in Betracht ziehen, um sich selbst zu gzipen (anstatt die Option -z zu verwenden), damit Sie eine Komprimierungsstufe angeben können. Ich habe die Erfahrung gemacht, dass bei schnellen Netzwerkverbindungen mit komprimierbaren Daten die Verwendung von gzip auf Stufe 2 oder 3 (die Standardeinstellung ist 6) in den meisten Fällen den besten Gesamtdurchsatz ergibt. Wie so:

server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
tylerl
quelle
Rsync hat wunderbar funktioniert - Komprimiert im laufenden Betrieb, kopiert ganze Ordner, setzt bei einem defekten Link fort. Alles in einem einfachen Befehl. Liebe es. Ich fand die folgenden Optionen nützlich: z: compress r: recurse = copy subfolder v: verbose. Mein Beispiel für einen Rsync-Befehl: rsync -azvr / src-path / username @ dest_server: / dest / path /
Bastion
68

Ich würde versucht sein, es über mich selbst zu synchronisieren - es macht Komprimierung und behandelt Linkverlust gut.

Chopper3
quelle
14
rsync ist genau das richtige Werkzeug.
Rich
4
+1 - Yay rsync!
Evan Anderson
1
+1, nur um zu stapeln. Außerdem mag ich rsync sehr.
Steven Montag
1
Aber wenn Sie rsync verwenden, müssen Sie die Daten trotzdem manuell komprimieren (wenn Sie Ihre Daten komprimiert speichern möchten)
wlk
Wie können Sie die komprimierten Dateien mit rsync speichern?
Dolan Antenucci
12

Wenn Sie sie nur tarieren und sonst nichts, wird dies Tonnen von Zeit mit nur minimalem Geschwindigkeitsgewinn verschwenden.

Das einfache Tarieren der Dateien mit den cvf-Schaltern kostet also effektiv die Zeit, die zum Lesen aller 55-GB-Bilder und zum Zurückschreiben auf die Festplatte benötigt wird. (Tatsächlich wird noch mehr Zeit verschwendet, da ein erheblicher Overhead entsteht.)

Sie haben hier nur einen Vorteil: Der Aufwand für das Hochladen vieler Dateien wird reduziert. Wenn Sie die Bilder komprimieren, können Sie möglicherweise schnellere Übertragungszeiten erzielen (da sie meines Erachtens bereits in einem komprimierten Format vorliegen, ist dies keine große Hilfe). Nur mehr Rechenzeitverschwendung.

Der größte Nachteil beim Übertragen eines riesigen Teerarchivs über Kabel besteht darin, dass bei einem Defekt ein Neustart erforderlich sein kann.

Ich würde so verwenden:

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

Auf dem neuen Server

md5sum /images/* > md5sum_new.txt

Und dann eben diff. Und da scp die Komprimierung im laufenden Betrieb unterstützt, sind keine separaten Archive erforderlich.

Bearbeiten

Ich werde die MD5-Informationen behalten, da sie für das OP nützlich waren. Aber ein Kommentar traf mich mit neuen Einsichten. Ein bisschen Suchen lieferte also diese nützliche Information. Bitte beachten Sie, dass das Thema hier SFTP ist, nicht direkt SCP .

Im Gegensatz zu FTP erhöht SFTP den Aufwand für die Übertragung von Dateien. Wenn eine Datei zwischen Client und Server übertragen wird, wird sie in kleinere Teile, sogenannte "Pakete", aufgeteilt. Angenommen, jedes Paket ist 32 KB groß. Das SFTP-Protokoll erstellt beim Senden eine Prüfsumme für jede 32-KB-Datei und schließt diese Prüfsumme zusammen mit diesem Paket ein. Der Empfänger erhält dieses Paket, entschlüsselt die Daten und überprüft dann die Prüfsumme. Die Prüfsumme selbst ist "stärker" als die CRC32-Prüfsumme. (Da SFTP eine 128-Bit- oder höhere Prüfsumme verwendet, z. B. MD5 oder SHA, und da dies für jedes einzelne Paket durchgeführt wird, erfolgt eine sehr detaillierte Integritätsprüfung, die als Teil der Übertragung durchgeführt wird.) Daher das Protokoll selbst ist langsamer (wegen des zusätzlichen Overheads), aber der erfolgreiche Abschluss einer Übertragung bedeutet de facto,

pacey
quelle
Vielen Dank, was macht der md5sum? und was ist der Unterschied? Danke, tritt jetzt auf!
Andrew Fashion
2
md5sum (oder md5) erstellt eine Prüfsumme der Dateien. Diff sucht nach Unterschieden in den Dateien (man diff). Die Prüfsumme erzeugt einen String, einen Hash, der, wenn die Datei während der Übertragung geändert wird, ein bisschen umgedreht wird, ein Fehler ... nicht übereinstimmt, wenn Sie ihn auf der anderen Seite erneut aufnehmen. Bei großen Dateien besteht ein erhöhtes Fehlerrisiko. Wenn Sie Websites sehen, auf denen Sie .iso-Dateien herunterladen können, ist häufig eine MD5-Prüfsumme vorhanden, mit der Sie Ihre heruntergeladene Datei vergleichen können, um sicherzustellen, dass sie übereinstimmt und nicht beschädigt ist.
Bart Silverstrim
3
scp ist verschlüsselt und garantiert die Integrität über die Leitung. Es besteht immer noch eine geringe Wahrscheinlichkeit, dass die Daten im Speicher oder auf der Festplatte beschädigt wurden, aber das ist ziemlich selten.
Ryan Bair
1
Ist der Aufwand für die SFTP-Prüfsummen tatsächlich von praktischer Bedeutung? Das kann ich mir nicht vorstellen. 4 Bytes für jeden 32768 klingen nicht signifikant. Das sind 128 kB pro GB. Das "langsamer" zu nennen, scheint eine Übertreibung zu sein, außer in einem langweiligen theoretischen Sinne.
Underscore_d
8

Zusätzlich zu Paceys Vorschlag für md5sum würde ich Folgendes verwenden:

Auf dem Bestimmungsort: nc -w5 -l -p 4567 | tar -xvf -

Dann auf der Quelle: tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567

Es ist immer noch ein tar / untar und es gibt keine Verschlüsselung, aber es ist direkt auf den anderen Server. Starten Sie beide im Tandem ( -w5gibt Ihnen 5 Sekunden Zeit) und schauen Sie zu, wie es losgeht. Wenn die Bandbreite knapp ist, fügen Sie -z an beiden Enden zum Teer hinzu.

SmallClanger
quelle
1
Ich denke, es ist umgekehrt, zuerst muss er am Bestimmungsort ausführen (um den Socket zu öffnen) und dann an der Quelle (um zu versenden)
Dimitrios Mistriotis
Platziere ich anstelle des Zielservers einfach [email protected]?
Andrew Fashion
Nein, nur die IP. netcat verwendet kein anderes Protokoll als TCP :) Dieser Befehl ist auch der schnellste aller oben angegebenen Befehle. Es gibt genau einen Lesevorgang pro Datei in der Quelle, den genauen minimalen Netzwerkverkehr zum Übertragen der Dateien und genau einen Schreibvorgang pro Datei im Ziel. Wenn Sie freie CPU-Zyklen haben, beschleunigt das Hinzufügen des Flags -z (für die Komprimierung) die Übertragung, da weniger Netzwerkdaten übertragen werden müssen.
Jeff McJunkin
@ user36845 - Richtig. Ich habe mit der obigen Reihenfolge keine Chronologie angegeben, aber Sie haben Recht, die Steckdose muss zuerst geöffnet werden. Ich werde es bearbeiten, um es zu klären. :)
SmallClanger
Ich bin mir nicht sicher, warum SSH / SCP auf 125 MB / s bis 133 MB / s begrenzt war, aber Netcat kann diese Daten mit ~ 380 MB / s problemlos weiterleiten (gleicher Link)
ThorSummoner
1

Ein Punkt - nicht alle Hosts haben rsync und viele Hosts haben unterschiedliche Versionen von tar. Aus diesem Grund könnte man als erste Anlaufstelle den oft vernachlässigten CPIO empfehlen.

Sie können über ssh eine Ad-hoc-Replikation von Datei- / Verzeichnisstrukturen zwischen Hosts durchführen. Auf diese Weise haben Sie eine genauere Kontrolle darüber, was gesendet wird, da Sie cpio, nom-nom, "füttern" müssen. Es ist auch mehr argument-portable, cpio ändert nicht viel - dies ist ein wichtiger Punkt, wenn Sie mehrere Hosts in einer heterogenen Umgebung betreuen.

Beispiel: Kopieren / Exportieren / Home und Unterverzeichnisse zum Remote-Host:

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

Das Obige kopiert den Inhalt von / export / home und alle Unterverzeichnisse nach / export / home auf dem Remote-Host.

Hoffe das hilft.

Rowley
quelle
Er erwähnte, dass es sich um zwei CentOS-Boxen handelte, damit sie rsync- und dateikompatible Versionen von tar hatten. Tools wie rsync wurden erstellt, um Tools wie cpio zu ersetzen :). Sie können mit cpio nicht "weitermachen", zumindest ohne zu wissen, wo genau Sie anfangen und Ihren Fund entsprechend filtern möchten. Welches ist ein unnötiger Zeitaufwand. Allerdings nützliche Informationen für "alte" UNIX-Boxen :)
Rafiq Maniar
Ja, das cmmand hat mich verloren haha
Andrew Fashion
1

Wenn Sie ssh-Zugriff haben, haben Sie rsync-Zugriff.

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

oder

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

Wenn Sie eine Fehlermeldung wie "rsync error: Einige Dateien konnten unter main.c (977) [sender = 2.6.9] nicht übertragen werden (Code 23)", überprüfen Sie Ihren Benutzer und die Gruppen zwischen den Servern. Sie könnten eine Fehlanpassung haben.

Verwenden Sie die Option rsync "-z", wenn Sie möchten, dass rsync die Übertragung komprimiert. Diese Option benötigt mehr CPU, aber weniger Bandbreite.

Es gibt eine "--progress" -Option, mit der Sie einen Prozentsatz übertragen, was ein bisschen nett ist, wenn Sie so etwas mögen.

quinnr
quelle
0

Befinden sie sich in einem gemeinsam genutzten Netzwerk, anstatt das Internet zum Übertragen von Dateien zu benötigen? NFS oder FTP sind möglicherweise viel schneller als der Overhead von SCP, obwohl Sie die Verschlüsselung während der Übertragung verlieren würden.

Tex
quelle
verschiedene Server an entfernten Standorten
Andrew Fashion
0

Oder Sie können immer Teerpfeifen verwenden:

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

'j' = bzip2, Sie können 'z' für gzip oder --lzma verwenden, wenn Ihr Tar dies unterstützt.

OneOfOne
quelle