# Was ist schneller cp oder rsync?

## Eistaucher

Hallo,

ich muss große Datenmengen (ganze Partitionen) umkopieren. Hat jemand eine Ahnung ob rsync schneller ist als cp? Ich hab irgendwo mal gelesen, das rsync sehr schnell sein soll. Aber es geht mir ums einfache kopieren des Inhaltes von z.B. /dev/hda5 nach /dev/hdb5. Also beide Platten und die Partitionen sind lokal....

Gruß, und danke im vorraus

----------

## nephros

Wenn du wirklich die gesamten Daten kopierst ist cp sicher schneller, weil es eben nichts anderes macht als Kopieren.

rsync macht noch einiges mehr, und ist eigentlich gedacht, zwei Verzeichnisstrukturen zu inkrementell synchronisieren, d.h. die Unterschiede herauszufinden und nur diese zu kopieren.

----------

## Robelix

Wenn am Zielort ein guter Teil der Daten schon vorhanden ist, du also nur neue Sachen abgleichen willst, dann wird rsync schneller sein.

----------

## c07

In der Zeit, in der überprüft wird, ob die Daten identisch sind, sind sie aber schon fast kopiert, wenn das rein lokal ist, außer wenn deine Platten wesentlich langsamer schreiben als lesen.

----------

## _hephaistos_

wie wärs mit "cp -u"?

 *Quote:*   

> 
> 
>        -u, --update
> 
>               Do not copy a nondirectory that has an existing destination with
> ...

 

----------

## Marlo

 *Eistaucher wrote:*   

> Hallo,
> 
> ich muss große Datenmengen (ganze Partitionen) umkopieren. Hat jemand eine Ahnung ob rsync schneller ist als cp ...

 

Hi,

sollten ganze Dateibäume kopiert werden, könnten auch symbolische Links dabei sein. In diesem Fall eignet sich:

```

root#  (cd /alte-platte ;  tar cf - .) | (cd /neue-platte ; tar xvf  -)

```

Es könnte sein, dass in deinem Falle sicheres kopieren vor schnelligkeit geht, wenn dem so ist ?

Gruß

Ma

----------

## Fauli

 *Marlboro wrote:*   

> 
> 
> ```
> 
> root#  (cd /alte-platte ;  tar cf - .) | (cd /neue-platte ; tar xvf  -)
> ...

 

Hat dieses komplizierte Konstrukt Vorteile gegenüber "cp -av"?

----------

## Eistaucher

Hallo,

erstmal danke für die vielen Hinweise. Da es sich bei mir immer um den Fall handelt bei dem die Zielpartition leer ist, verwende ich jetzt cp -av. Update und Vergleich der Quell und Zielpartition brauch ich ja daher nicht...

Danke.

----------

## toralf

Ein

```

(cd /old_path; tar -cpf- . | tar -xpf- -C /new_path)

```

ist wesentlich schneller als ein cp - Befehl und hat demgegenüber auch noch den Vorteil, timestamps und permissions 1:1 zu duplizieren.

----------

## Eistaucher

Hallo,

ich hab mich jetzt doch mal durchgerungen und hab einen Vergleich zwischen cp und tar mittels dem "time"-Kommando durchgeführt. Da mir rsync jetzt nicht mehr so wichtig war, hab ich das jetzt nicht mehr probiert... Mit cp "-ax" hat das kopieren 3:30 gedauert und mit dem tar-Kommando 3:40. Der Unterschied ist also kaum der Rede Wert. Allerdings übergeht tar ein paar wenige Dateien (Sockets...). Zudem behält auch cp mit der Option -a (Archiv) die original Timestamps und Permissions.

Irgendwie hat mich das nämlich gewundert, das tar schneller sein soll. Übers netzt wahrscheinlich schon, weil er ja die Daten packt. Aber das packen und entpacken dauerd ja auch seine Zeit... Vielleicht wärs ohne Packen lokal schneller. Aber ich hab jetzt keine Lust mehr soviel zu kopieren  :Smile: 

Danke an alle für die Hilfe

----------

## nephros

 *Eistaucher wrote:*   

> Übers netzt wahrscheinlich schon, weil er ja die Daten packt. Aber das packen und entpacken dauerd ja auch seine Zeit... Vielleicht wärs ohne Packen lokal schneller. 

 

Weitverbreitetes Missverständnis: tar komprimiert gar nix. Es klebt nur die Dateien zusammen.

Komprimieren tun dann andere utilities, klassischerweise compress (.Z), gzip (.gz), bzip (.bz) und bzip2 (.bz2)

----------

## Marlo

 *nephros wrote:*   

>  *Eistaucher wrote:*   Übers netzt wahrscheinlich schon, ...  
> 
> Weitverbreitetes Missverständnis: tar komprimiert gar nix. ...
> 
> 

 

Für mich stellt sich die Frage, bist du Moderator in Sachen Linux Befehle und wenn nein: Warum nicht? Du könntest das! 

Ich würde sowas sehr begrüßen, wenn man sich geordnet und strukturiert über sowas unterhalten könnte.

Herzlichen Dank

Ma

----------

## nephros

 *Marlboro wrote:*   

> bist du Moderator in Sachen Linux Befehle 

 

Hä? Was solln das sein??  :Shocked: 

Ich bin nur einer der ein Häufchen weis und einen ganzen Haufen nicht weis. Und aus diesem Grund den "view unanswered posts" link sehr schätzt, weil: da kann man dann von seinem Häufchen was weitergeben und den Haufen verkleinern.  :Razz: 

Ach und sollte dir das auf die Nerven gehen, hmm, naja Pech halt.

 *Marlboro wrote:*   

> Ich würde sowas sehr begrüßen, wenn man sich geordnet und strukturiert über sowas unterhalten könnte.

 

Na, das wird doch hier gemacht oder?

----------

## Eistaucher

Hallo,

 *Quote:*   

> 
> 
> Weitverbreitetes Missverständnis: tar komprimiert gar nix. Es klebt nur die Dateien zusammen.
> 
> Komprimieren tun dann andere utilities, klassischerweise compress (.Z), gzip (.gz), bzip (.bz) und bzip2 (.bz2)
> ...

 

gut, das tar an sich nicht komprimiert war mir eigentlich klar. Aber es ist doch richtig, das die Option -z (für gezipped) die Daten komprimiert. Praktisch das Kommando zip mit einschließt. Darum heißt ja dann die Endung auch .tar.gz, oder kurz tgz. Für T(ape)AR(chiver).(GeZiped).

Ups, ich hab gerade gesehen, das oben die Option -z gar nicht angegeben war. Sorry, die mach ich schon automatisch dazu...

Gruß,

----------

## c07

 *toralf wrote:*   

> Ein
> 
> ```
> (cd /old_path; tar -cpf- . | tar -xpf- -C /new_path)
> ```
> ...

 

Das mit dem 1:1 stimmt aber nicht ganz. An Timestamps enthält das tar-Format nichts außer mtime, und das nur in Sekundenauflösung; alles Andere geht verloren. Ob ACLs und dergleichen erhalten bleiben, ist auch unsicher. Das klassische Format hat jedenfalls keine Möglichkeit, sie zu übertragen.

Schneller kann ein tar u.U. dann sein, wenn der IO-Scheduler versagt und so größere Einheiten am Stück zwischen zwei verschiedenen Platten transferiert werden können. Dass es innerhalb der selben Platte jemals schneller ist, halt ich für unwahrscheinlich. Schließlich ist der Overhead bei kleineren Dateien (und bei großen ist es eh ziemlich egal) nicht unerheblich: Neben den zusätzlichen Prozessen wird jede Datei auf die übernächsten vollen 512 Byte aufgerundet und die Header müssen auch erst mal kodiert und dekodiert werden.

----------

