it-swarm.com.de

So kopieren Sie schnell eine große Anzahl von Dateien zwischen zwei Servern

Ich muss eine große Menge von MP3s zwischen zwei Aufschlägen übertragen (Ubuntu). Mit riesig meine ich ungefähr eine Million Dateien, die durchschnittlich 300 KB groß sind. Ich habe es mit scp versucht, aber es hätte ungefähr eine Woche gedauert. (ca. 500 KB/s) Wenn ich eine einzelne Datei per HTTP übertrage, erhalte ich 9-10 MB/s, weiß aber nicht, wie ich alle übertragen soll.

Gibt es eine Möglichkeit, alle schnell zu übertragen?

96
nicudotro

Ich würde Teer empfehlen. Wenn die Dateibäume bereits ähnlich sind, führt rsync sehr gut aus. Da rsync jedoch mehrere Analysedurchläufe für jede Datei durchführt und dann die Änderungen kopiert, ist es für die erste Kopie viel langsamer als tar. Dieser Befehl wird wahrscheinlich tun, was Sie wollen. Es kopiert die Dateien zwischen den Computern und behält sowohl Berechtigungen als auch Benutzer-/Gruppenbesitz bei.

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

Laut Mackintoshs Kommentar unten ist dies der Befehl, den Sie für rsync verwenden würden

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
119
Scott Pack

Externe Festplatte und Kurierdienst am selben Tag.

38
Adam

Ich würde rsync verwenden.

Wenn Sie sie über HTTP mit verfügbaren Verzeichnislisten exportieren lassen, können Sie auch wget und das Argument --mirror verwenden.

Sie sehen bereits, dass HTTP schneller als SCP ist, da SCP alles verschlüsselt (und somit einen Engpass auf der CPU verursacht). HTTP und rsync werden sich schneller bewegen, weil sie nicht verschlüsseln.

Hier sind einige Dokumente zum Einrichten von rsync unter Ubuntu: https://help.ubuntu.com/community/rsync

In diesen Dokumenten wird über das Tunneln von rsync über SSH gesprochen. Wenn Sie jedoch nur Daten in einem privaten LAN verschieben, benötigen Sie kein SSH. (Ich gehe davon aus, dass Sie sich in einem privaten LAN befinden. Wenn Sie 9-10 MB/s über das Internet erhalten, möchte ich wissen, welche Art von Verbindungen Sie haben!)

Hier sind einige andere sehr grundlegende Dokumente, mit denen Sie einen relativ unsicheren rsync-Server einrichten können (ohne Abhängigkeit von SSH): http://transamrit.net/docs/rsync/

17
Evan Anderson

Verwenden Sie ohne viel Diskussion netcat, Netzwerk-Schweizer Messer. Kein Protokoll-Overhead, Sie kopieren direkt auf den Netzwerk-Socket. Beispiel

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

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

Mit vielen Dateien, wenn Sie mit rsync arbeiten, Ich würde versuchen, Version 3 oder höher an beiden Enden zu bekommen. Der Grund dafür ist, dass eine kleinere Version jede Datei auflistet, bevor die Übertragung gestartet wird. Die neue Funktion heißt inkrementelle Rekursion .

Ein neuer inkrementeller Rekursionsalgorithmus wird jetzt verwendet, wenn rsync mit einer anderen 3.x-Version spricht. Dadurch wird die Übertragung schneller gestartet (bevor alle Dateien gefunden wurden) und es wird viel weniger Speicher benötigt. Einige Einschränkungen finden Sie in der Manpage unter --recursive.

8
Kyle Brandt

rsync, wie andere bereits empfohlen haben. Wenn der CPU-Overhead durch die Verschlüsselung ein Engpass ist, verwenden Sie einen anderen weniger CPU-intensiven Algorithmus wie Blowfish. Z.B. etwas wie

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

7
janneb

Beim Verschieben von 80 TB von Daten (Millionen winziger Dateien)) gestern erwies sich der Wechsel von rsync zu tarals richtig viel schneller , als wir aufhörten es zu versuchen

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

und wechselte stattdessen zu tar ...

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

Da sich diese Server im selben LAN befinden, ist das Ziel NFS-gemountet auf dem Quellsystem, das den Push ausführt. Nein, machen Sie es noch schneller, wir haben beschlossen, das atime der Dateien nicht beizubehalten:

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

Die folgende Grafik zeigt den Unterschied, den der Wechsel von rsync zu tar gemacht hat. Es war die Idee meines Chefs und mein Kollege haben sie beide ausgeführt und das gemacht großartiger Artikel in seinem Blog . Ich mag nur schöne Bilder . :) :)

rsync_vs_tar

7
Philip Durbin

Beim Kopieren einer großen Anzahl von Dateien stellte ich fest, dass Tools wie tar und rsync aufgrund des Overheads beim Öffnen und Schließen vieler Dateien ineffizienter sind als erforderlich. Ich habe ein Open-Source-Tool namens Fast-Archiver geschrieben, das für diese Szenarien schneller als tar ist: https://github.com/replicon/fast-archiver ; Es funktioniert schneller, indem mehrere Dateivorgänge gleichzeitig ausgeführt werden.

Hier ist ein Beispiel für Fast-Archiver vs. Tar bei einer Sicherung von über zwei Millionen Dateien. Die Archivierung von Fast-Archiver dauert 27 Minuten, während Tar 1 Stunde und 23 Minuten benötigt.

$ 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

Um Dateien zwischen Servern zu übertragen, können Sie Fast-Archiver mit ssh wie folgt verwenden:

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

Ich verwende den Ansatz tar auch über netcat, außer ich bevorzuge socat - viel mehr Leistung, um für Ihre Situation zu optimieren - zum Beispiel durch Optimieren von mss. (Lachen Sie auch, wenn Sie wollen, aber ich finde socat Argumente leichter zu merken, weil sie konsistent sind). Für mich ist dies in letzter Zeit sehr, sehr häufig, da ich Dinge auf neue Server verschoben habe:

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

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

Aliase sind optional.

3
  • Network File System (NFS) und kopieren Sie sie dann mit einem beliebigen Element, z. Midnight Commander (mc), Nautilus (vom Gnom). Ich habe NFS v3 mit guten Ergebnissen verwendet.
  • Samba (CIFS) und kopiere dann die Dateien mit was auch immer du willst, aber ich habe keine Ahnung, wie effizient es ist.
  • [~ # ~] http [~ # ~] mit wget --mirror as Evan Anderson hat vorgeschlagen oder einen anderen http-Client. Achten Sie darauf, keine bösen Symlinks oder irreführenden Indexdateien zu haben. Wenn Sie nur MP3s haben, sollten Sie sicher sein.
  • rsync . Ich habe es mit ziemlich guten Ergebnissen verwendet und eine seiner netten Funktionen ist, dass Sie die Übertragung später unterbrechen und fortsetzen können.

Ich habe festgestellt, dass andere Leute die Verwendung von netcat empfohlen haben. Basierend auf meiner Erfahrung damit kann ich sagen, dass es im Vergleich zu den anderen Lösungen langsam ist.

2

Es sieht so aus, als ob die oberste Antwort ein paar Tippfehler enthält. Dies kann besser funktionieren:

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

Dank der wunderbaren Antwort von Scott Pack (ich wusste vorher nicht, wie ich das mit ssh machen soll) kann ich diese Verbesserung anbieten (wenn bash Ihre Shell ist). Dies fügt eine parallele Komprimierung, eine Fortschrittsanzeige und eine Überprüfung der Integrität über die Netzwerkverbindung hinzu:

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 ist ein Nice Progress Viewer-Programm für Ihre Pipe und pigz ist ein paralleles gzip-Programm, das standardmäßig so viele Threads verwendet, wie Ihre CPU hat (ich glaube bis zu 8 max). Sie können die Komprimierungsstufe anpassen, um das Verhältnis von CPU zu Netzwerkbandbreite besser anzupassen, und sie mit pxz -9e Und pxz -d Austauschen, wenn Sie viel mehr CPU als Bandbreite haben. Sie müssen erst nach Abschluss überprüfen, ob die beiden Beträge übereinstimmen.

Diese Option ist nützlich für sehr große Datenmengen sowie für Netzwerke mit hoher Latenz, aber nicht sehr hilfreich, wenn die Verbindung instabil ist und unterbrochen wird. In diesen Fällen ist rsync wahrscheinlich die beste Wahl, da es fortgesetzt werden kann.

Beispielausgabe:

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

Für Blockgeräte:

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
    '

Stellen Sie natürlich sicher, dass sie mit count =, skip =, seek = usw. dieselbe Größe oder Grenze haben.

Wenn ich Dateisysteme auf diese Weise kopiere, werde ich häufig zuerst dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs Den größten Teil des nicht genutzten Speicherplatzes auf Null setzen, was den xfer beschleunigt.

2
Daniel Santos

Eine andere Alternative ist nison . Könnte in diesem Fall etwas effizienter sein als Rsync, und es ist etwas einfacher, einen Listener einzurichten.

2
Adam D'Amico

Sie haben nicht erwähnt, ob sich die beiden Computer im selben LAN befinden oder ob ein sicherer Kanal (d. H. Die Verwendung von SSH) obligatorisch ist, aber ein anderes Tool, das Sie verwenden könnten, ist netcat .

Ich würde Folgendes auf dem Empfangsgerät verwenden:

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

Dann auf der sendenden Seite:

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

Es hat folgende Vorteile:

  • Kein CPU-Overhead für die Verschlüsselung von ssh.
  • Der gzip -1 Bietet eine leichte Komprimierung, ohne eine CPU zu überlasten, sodass ein guter Kompromiss erzielt wird, der ein wenig Komprimierung bietet und gleichzeitig den maximalen Durchsatz beibehält. (Wahrscheinlich nicht so vorteilhaft für MP3-Daten, tut aber nicht weh.)
  • Wenn Sie die Dateien in Gruppen aufteilen können, können Sie zwei oder mehr Pipes parallel ausführen und sicherstellen, dass Ihre Netzwerkbandbreite voll ist.

z.B.,

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

Anmerkungen:

  • Wie auch immer Sie übertragen, ich würde wahrscheinlich danach einen rsync oder nisono ausführen, um sicherzustellen, dass Sie alles haben.
  • Sie können tar anstelle von cpio verwenden, wenn Sie dies bevorzugen.
  • Selbst wenn Sie am Ende ssh verwenden, würde ich sicherstellen, dass es keine Komprimierung selbst verwendet, und stattdessen gzip -1 Durchleiten, um eine CPU-Sättigung zu vermeiden. (Oder setzen Sie zumindest die Komprimierungsstufe auf 1.)
1
Evan

Wenn Sie einen FTP-Server auf der src-Seite haben, können Sie ncftpget von ncftp site verwenden. Es funktioniert perfekt mit kleinen Dateien, da es intern tar verwendet.

Ein Vergleich zeigt dies: Verschieben von 1,9 GB kleinen Dateien (33926 Dateien)

  1. Die Verwendung von scp dauert 11m59s
  2. Die Verwendung von rsync dauert 7m10s
  3. Die Verwendung von ncftpget dauert 1: 20s
1
Ali Nikneshan

Sie können auch versuchen, den BBCP-Befehl für Ihre Übertragung zu verwenden. Es ist eine gepufferte parallele SSH, die wirklich schreit. Wir können normalerweise eine Leitungsrate von 90% + erhalten, vorausgesetzt, wir können das Rohr gespeist halten.

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

Normalerweise bemühen wir uns sehr, nicht zu viel bewegen zu müssen. Wir verwenden ZFS-Pools, denen wir immer nur mehr Speicherplatz hinzufügen können. Aber manchmal ... muss man nur Sachen bewegen. Wenn wir ein "Live" -Dateisystem haben, dessen Kopieren Stunden (oder Tage) dauern kann, selbst wenn es auf Hochtouren läuft. Wir führen die alte zweistufige zfs-Senderoutine aus:

  1. Erstellen Sie einen ZFS-Snapshot und übertragen Sie ihn in den neuen Pool auf dem neuen Computer. Lass es so lange dauern wie es dauert.
  2. Machen Sie einen zweiten Schnappschuss und senden Sie ihn inkrementell. Der inkrementelle Snapshot enthält nur den (viel kleineren) Änderungssatz seit dem ersten, sodass er relativ schnell ausgeführt wird.
  3. Sobald der inkrementelle Schnappschuss abgeschlossen ist, können Sie das Original ausschalten und auf die neue Kopie umschneiden, und Ihre "Offline-Ausfallzeit" wird auf ein Minimum reduziert.

Wir senden unsere zfs-Dumps auch über BBCP ... dies maximiert unsere Netzwerkauslastung und minimiert die Übertragungszeiten.

BBCP ist frei verfügbar, Sie können es googeln und es ist eine direkte Kompilierung. Kopieren Sie es einfach in Ihren/usr/local/bin auf src- und Zielcomputern, und es funktioniert so ziemlich einfach.

1
C. Shamis

Ich denke, meine Antwort ist hier etwas spät, aber ich habe gute Erfahrungen mit der Verwendung von mc (Midnight Commander) auf einem Server gemacht, um eine Verbindung über SFTP mit dem anderen Server herzustellen.

Die Option zum Herstellen einer Verbindung über FTP befindet sich in den Menüs "Links" und "Rechts", indem Sie die folgende Adresse eingeben:

/#ftp:[email protected]/

oder

/#ftp:[email protected]/

Sie können navigieren und Dateivorgänge fast wie in einem lokalen Dateisystem ausführen.

Es hat eine eingebaute Option, um das Kopieren im Hintergrund durchzuführen, aber ich bevorzuge es, den Befehl screen zu verwenden und mich vom Bildschirm zu trennen, während mc kopiert (ich denke, es läuft dann auch schneller).

1
w-sky

Um @scottpack Antwort der rSync-Option

Um den Fortschritt des Uploads anzuzeigen, verwenden Sie '--progess' als Option nach -avW im Befehl wie unten gezeigt.

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

enter image description here

1
Dinesh Sunny

Ein einfacher SCP mit den richtigen Optionen erreicht über LAN problemlos 9-10 MB/s:

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

Mit diesen Optionen ist es wahrscheinlich, dass der Durchsatz 4x oder 5x schneller wurde als keine Optionen (Standard)

1
user57125

Ich glaube nicht, dass Sie es besser machen als scp, wenn Sie nicht schnellere Netzwerkkarten installieren. Wenn Sie dies über das Internet tun, hilft dies jedoch nicht.

Ich würde empfehlen, rsync zu verwenden. Es ist möglicherweise nicht schneller, aber zumindest wenn es fehlschlägt (oder Sie es herunterfahren, weil es zu lange dauert), können Sie dort weitermachen, wo Sie das nächste Mal aufgehört haben.

Wenn Sie die beiden Computer direkt über Gigabit-Ethernet verbinden können, ist dies wahrscheinlich der schnellste.

1
Brent

Für 100 MBit/s beträgt der theoretische Durchsatz 12,5 MBit/s, sodass Sie mit 10 MBit/s ziemlich gut abschneiden.

Ich würde auch den Vorschlag wiederholen, rsync zu machen, wahrscheinlich durch ssh. Etwas wie:

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

Bei 100 MBit/s sollten Ihre CPUs in der Lage sein, das Ver-/Entschlüsseln zu handhaben, ohne die Datenrate merklich zu beeinflussen. Und wenn Sie den Datenfluss unterbrechen, sollten Sie dort weitermachen können, wo Sie aufgehört haben. Achtung, bei "Millionen" Dateien dauert der Start eine Weile, bis tatsächlich etwas übertragen wird.

1

Ich bin darauf gestoßen, außer dass ich Oracle-Protokolle übertragen habe.

Hier ist die Aufschlüsselung

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

Ich habe FTP mit großem Erfolg verwendet (wobei großer Erfolg ~ 700 MBit/s in einem GB-Netzwerk entspricht). Wenn Sie 10 MB (was 80 MB/s entspricht) erhalten, stimmt wahrscheinlich etwas nicht.

Was können Sie uns über die Quelle und das Ziel der Daten sagen? Ist es Einzellaufwerk zu Einzellaufwerk? RAID auf USB?

Ich weiß, dass diese Frage bereits eine Antwort hat, aber wenn Ihr Netzwerk mit einem Gbit/s-Crossover-Kabel so langsam läuft, muss unbedingt etwas behoben werden.

1
Matt Simmons

Hier ist ein kurzer Benchmark, um einige Techniken zu vergleichen:

  • Quelle ist eine 4-Kern Intel (R) Xeon (R) CPU E5-1620 bei 3,60 GHz mit 250 Mbit/s und SATA-Laufwerk
  • Ziel ist eine 6-Kern Intel (R) Xeon (R) CPU E-2136 bei 3,30 GHz mit 1 Gbit/s Bandbreite und SSD-Laufwerk

Anzahl der Dateien: 9632, Gesamtgröße: 814 MiB, Durchschn. Größe: 84 KiB

  • RSYNC: 1m40.570s
  • RSYNC + KOMPRESSION: 0m26.519s
  • TAR + NETCAT: 1m58.763s
  • TAR + COMPRESSION + NETCAT: 0m28.009s

Befehl für tar/netcat war:

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

Wenn Sie über MP3s und andere komprimierte Dateien senden, profitieren Sie nicht von einer Lösung, die versucht, diese Dateien weiter zu komprimieren. Die Lösung könnte mehrere Verbindungen zwischen beiden Servern herstellen und somit die Bandbreite zwischen den beiden Systemen stärker belasten. Sobald dies maximal ist, kann nicht viel erreicht werden, ohne Ihre Hardware zu verbessern. (Zum Beispiel schnellere Netzwerkkarten zwischen diesen Servern.)

0
Wim ten Brink

Ich musste die BackupPC-Festplatte auf einen anderen Computer kopieren.

Ich habe rsync verwendet.

Die Maschine hatte 256 MB Speicher.

Das Verfahren, dem ich folgte, war das folgende:

  • rsync ohne -H ausgeführt (dauerte 9 Stunden)
  • als rsync fertig war, synchronisierte ich das Verzeichnis cpool und begann mit dem Verzeichnis pc. Ich habe die Übertragung gekürzt.
  • anschließend wurde rsync mit dem Flag -H neu gestartet, und alle im Verzeichnis pc fest verknüpften Dateien wurden korrekt übertragen (die Prozedur fand alle realen Dateien in cpool und dann mit dem Verzeichnis pc verknüpft) (dauerte 3 Stunden).

Am Ende konnte ich mit df -m Verifizieren, dass kein zusätzlicher Speicherplatz ausgegeben wurde.

Auf diese Weise entziehe ich mich dem Problem mit dem Speicher und rsync. Ich kann die Leistung jederzeit mit top und atop überprüfen und schließlich 165 GB Daten übertragen.

0
Hector

Ich habe einige Tools zum Kopieren einer 1-GB-Datei ausprobiert. Das Ergebnis ist unten aufgeführt: HTTP am schnellsten, wobei wget -c nc Sekunde in Zeile scp am langsamsten ist und einige Male fehlgeschlagen ist. Keine Möglichkeit, rsync fortzusetzen, verwendet ssh als Backend, daher das gleiche Ergebnis. Abschließend würde ich mit wget -bqc auf http gehen und ihm etwas Zeit geben. Hoffe das hilft

0
Mijo

rsync oder Sie möchten es vielleicht tarieren, damit alles in einer Datei und dann scp ist. Wenn Ihnen der Speicherplatz fehlt, können Sie den Teer während der Erstellung direkt über ssh leiten.

0
Adam Gibbins