342 votes

Copier localement une grande arborescence de répertoires ? cp ou rsync ?

Je dois copier une grande arborescence de répertoires, environ 1,8 To. Tout est en local. Par habitude, j'utilise rsync mais je me demande si c'est vraiment utile, et si je ne devrais pas plutôt utiliser cp .

Je m'inquiète des permissions et de l'uid/gid, car ils doivent être préservés dans la copie (je sais que rsync le fait). Ainsi que des choses comme les liens symboliques.

La destination est vide, je n'ai donc pas à me soucier de la mise à jour conditionnelle de certains fichiers. Tout est sur le disque local, donc je n'ai pas à me soucier de ssh ou de réseau.

La raison pour laquelle je serais tenté de me détourner de rsync, est que rsync pourrait faire plus que ce dont j'ai besoin. rsync vérifie les fichiers. Je n'ai pas besoin de cela, et je crains que cela ne prenne plus de temps que cp.

Alors, qu'en pensez-vous ? rsync o cp ?

3 votes

Si rsync fait exactement ce que vous voulez qu'il fasse, si vous êtes déjà familiarisé avec son utilisation pour cette application particulière, et s'il fonctionne assez rapidement à votre goût, alors pourquoi diable voudriez-vous changer ?

3 votes

Parce que j'ai peur que rsync prenne plus de temps que cp, puisque rsync fait beaucoup de checksumming que cp ne fera pas.

1 votes

L'overhead cpu de la somme de contrôle est faible comparé aux entrées/sorties disque/réseau. À moins que le disque ne soit sur le même système et que le système d'exploitation puisse faire une copie intelligente de disque à disque dans le contrôleur de bus.

269voto

Hamish Downer Points 9012

J'utiliserais rsync car s'il est interrompu pour une raison quelconque, vous pouvez le redémarrer facilement et à peu de frais. Et comme il s'agit de rsync, il peut même redémarrer une partie d'un gros fichier. Comme d'autres l'ont mentionné, il peut facilement exclure des fichiers. La façon la plus simple de préserver la plupart des choses est d'utiliser la fonction -a flag - "archive". Donc :

rsync -a source dest

Bien que UID/GID et les liens symboliques soient préservés par -a (voir -lpgo ), votre question implique que vous pourriez vouloir un complet une copie des informations sur le système de fichiers -a n'inclut pas les liens durs, les attributs étendus, les ACL (sous Linux) ou les éléments ci-dessus. ni (sur OS X.) Ainsi, pour une copie robuste d'un système de fichiers, vous devrez inclure ces drapeaux :

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

Le cp par défaut recommencera, bien que l'option -u le drapeau sera "copier uniquement lorsque le fichier SOURCE est plus récent que le fichier de destination ou lorsque le fichier de destination est manquant". . Et le -a (archive) sera récursif, ne recopiera pas les fichiers si vous devez redémarrer et préservera les permissions. Ainsi :

cp -au source dest

195voto

Ellis Percival Points 1862

Pour copier sur le système de fichiers local, j'ai tendance à utiliser rsync avec les options suivantes :

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

Voici mon raisonnement :

-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)

J'ai constaté des transferts 17% plus rapides en utilisant les paramètres rsync ci-dessus par rapport à la commande tar suivante, comme suggéré par une autre réponse :

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

90voto

Chad Huneycutt Points 2076

Lorsque je dois copier une grande quantité de données, j'utilise généralement une combinaison de tar et rsync. Le premier passage est de le tarer, quelque chose comme ceci :

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

En général, avec une grande quantité de fichiers, il y en a certains que tar ne peut pas traiter pour une raison quelconque. Ou bien le processus peut être interrompu, ou encore, s'il s'agit d'une migration de système de fichiers, il est préférable de faire la copie initiale avant l'étape de migration proprement dite. En tout cas, après la copie initiale, je fais une étape rsync pour synchroniser le tout :

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

Notez que la barre oblique de fin sur /src/ est important.

19voto

arjones Points 221

Ce fil de discussion a été très utile et comme il y avait beaucoup d'options pour obtenir le résultat, j'ai décidé d'en évaluer quelques-unes. Je pense que mes résultats peuvent être utiles à d'autres personnes pour avoir une idée de ce qui a fonctionné le plus rapidement.

Pour déplacer 532Gb de données réparties entre 1 753 200 fichiers nous avons eu ces moments :

  • rsync a pris 232 minutes
  • tar a pris 206 minutes
  • cpio a pris 225 minutes
  • rsync + parallel a pris 209 minutes

Dans mon cas, j'ai préféré utiliser rsync + parallel . J'espère que ces informations aideront davantage de personnes à se décider parmi ces alternatives.

Le référentiel complet est publié aquí

17voto

AskApache Points 381

Rsync

Voici le rsync que j'utilise, je préfère cp pour les commandes simples, pas ça.

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

cpio

Voici un moyen encore plus sûr, cpio. C'est à peu près aussi rapide que tar, peut-être un peu plus.

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

tar

C'est également une bonne chose, et cela continue sur les échecs de lecture.

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

Notez qu'il ne s'agit que de copies locales.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X