Einen großen Verzeichnisbaum lokal kopieren? cp oder rsync?

Lösung 1:

Ich würde rsync verwenden, da dies bedeutet, dass Sie es bei einer Unterbrechung aus irgendeinem Grund problemlos und mit sehr geringen Kosten neu starten können. Und da es rsync ist, kann es sogar mitten durch eine große Datei neu starten. Wie andere bereits erwähnt haben, kann es Dateien einfach ausschließen. Der einfachste Weg, die meisten Dinge zu bewahren, ist die Verwendung von -a flag – „Archiv“. Also:

rsync -a source dest

Obwohl UID/GID und Symlinks von -a beibehalten werden (siehe -lpgo ), impliziert Ihre Frage, dass Sie vielleicht ein volles möchten Kopie der Dateisysteminformationen; und -a enthält keine festen Links, erweiterten Attribute oder ACLs (unter Linux) oder die obigen noch Resource Forks (unter OS X.) Daher müssen Sie für eine robuste Kopie eines Dateisystems diese Flags einschließen:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

Der Standard-CP wird erneut gestartet, obwohl der -u Flag wird "nur kopieren, wenn die SOURCE-Datei neuer als die Zieldatei ist oder wenn die Zieldatei fehlt" . Und die -a (Archiv)-Flag ist rekursiv und kopiert keine Dateien, wenn Sie neu starten und Berechtigungen beibehalten müssen. Also:

cp -au source dest

Lösung 2:

Beim Kopieren in das lokale Dateisystem neige ich dazu, rsync mit den folgenden Optionen zu verwenden:

# rsync -avhW --no-compress --progress /src/ /dst/

Hier ist meine Begründung:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

Ich habe 17 % schnellere Übertragungen mit den obigen rsync-Einstellungen gegenüber dem folgenden tar-Befehl gesehen, wie in einer anderen Antwort vorgeschlagen:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Lösung 3:

Wenn ich große Datenmengen kopieren muss, verwende ich normalerweise eine Kombination aus tar und rsync. Der erste Durchgang besteht darin, es zu tarieren, etwa so:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Normalerweise gibt es bei einer großen Menge an Dateien einige, die tar aus irgendeinem Grund nicht verarbeiten kann. Oder vielleicht wird der Prozess unterbrochen, oder wenn es sich um eine Dateisystemmigration handelt, möchten Sie vielleicht die erste Kopie vor dem eigentlichen Migrationsschritt durchführen. Auf jeden Fall mache ich nach der ersten Kopie einen rsync-Schritt, um alles zu synchronisieren:

# cd /dst; rsync -avPHSx --delete /src/ .

Beachten Sie, dass der abschließende Schrägstrich auf /src/ ist wichtig.

Lösung 4:

rsync

Hier ist das rsync, das ich verwende, ich bevorzuge cp für einfache Befehle, nicht das.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

Hier ist ein Weg, der noch sicherer ist, cpio. Es ist ungefähr so ​​schnell wie Teer, vielleicht etwas schneller.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

tar

Das ist auch gut und setzt sich bei Lesefehlern fort.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

Beachten Sie, dass dies alles nur für lokale Kopien gilt.

Lösung 5:

Dieser Thread war sehr nützlich, und da es so viele Optionen gab, um das Ergebnis zu erzielen, entschied ich mich, einige davon zu benchmarken. Ich glaube, dass meine Ergebnisse hilfreich sein können, damit andere ein Gefühl dafür bekommen, was schneller funktioniert hat.

Zum Verschieben von 532 GB von Daten verteilt auf 1.753.200 Dateien wir hatten diese Zeiten:

• rsync dauerte 232 Minuten
• tar dauerte 206 Minuten
• cpio dauerte 225 Minuten
• rsync + parallel dauerte 209 Minuten

In meinem Fall habe ich es vorgezogen, rsync + parallel zu verwenden . Ich hoffe, diese Informationen helfen mehr Menschen, sich zwischen diesen Alternativen zu entscheiden.

Der vollständige Benchmark wird hier veröffentlicht