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

Je dois copier une grande arborescence de répertoires, environ 1,8 To. C'est tout local. Par habitude j'utiliserais rsync, cependant je me demande s'il y a beaucoup de raison, et si je devrais plutôt utiliser cp.

Je suis inquiet pour les permissions et uid / gid, car ils doivent être conservé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 à m'inquiéter de la mise à jour conditionnelle de certains fichiers. C'est tout le disque local, ainsi je n'ai pas à m'inquiéter de ssh ou du réseau.

La raison pour laquelle je serais tenté de ne pas utiliser rsync, c'est parce que rsync pourrait en faire plus que ce dont j'ai besoin. Fichiers de sommes de contrôle rsync. Je n’en ai pas besoin, et je crains que cela ne prenne plus de temps que cp.

Alors, que comptez-vous rsyncou cp?

J'utiliserais rsync car cela signifie que s'il est interrompu pour une raison quelconque, vous pouvez le redémarrer facilement avec un coût très faible. Et étant rsync, il peut même redémarrer à mi-chemin à travers un fichier volumineux. Comme d'autres le mentionnent, il peut facilement exclure des fichiers. Le moyen le plus simple de préserver la plupart des choses consiste à utiliser le -adrapeau - 'archive'. Alors:

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 souhaitiez peut-être une copie complète des informations du système de fichiers; et -an'inclut pas les liens en dur, les attributs étendus ni les ACL (sous Linux), ni les fourchettes ci-dessus ni les ressources (sous OS X). Ainsi, pour une copie robuste d'un système de fichiers, vous devez inclure ces indicateurs:

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

La valeur par défaut cp va redémarrer, bien que l' -uindicateur "ne copie que lorsque le fichier SOURCE est plus récent que le fichier de destination ou lorsque le fichier de destination est manquant" . Et l' -aindicateur (archive) sera récursif, pas une copie des fichiers si vous devez redémarrer et conserver les autorisations. Alors:

cp -au source dest

Lors de la copie sur le système de fichiers local, j'utilise toujours les options suivantes de rsync:

# 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 vu des transferts 17% plus rapides utilisant les paramètres rsync ci-dessus par rapport à la commande tar suivante, comme le suggère une autre réponse:

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

Lorsque je dois copier une grande quantité de données, j'utilise généralement une combinaison de tar et de rsync. La première passe est de le goudronner, quelque chose comme ceci:

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

Généralement, avec une grande quantité de fichiers, tar ne peut pas en gérer pour une raison quelconque. Ou bien le processus sera peut-être interrompu ou, s'il s'agit d'une migration de système de fichiers, vous voudrez peut-être effectuer la copie initiale avant l'étape de migration proprement dite. Quoi qu'il en soit, après la copie initiale, je fais une étape rsync pour tout synchroniser:

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

Notez que le slash final /src/est important.

rsync

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

$ 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 le goudron, peut-être un peu plus vite.

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

le goudron

C'est aussi bon, et continue sur les échecs de lecture.

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

Notez que ce ne sont que des copies locales.

Ce que tu préfères. Juste n'oubliez pas le -acommutateur lorsque vous décidez d'utiliser cp.

Si vous avez vraiment besoin d'une réponse: j'utiliserais rsync parce que c'est beaucoup plus flexible. Besoin d'arrêter avant la fin de la copie? Juste ctrl-c et reprendre dès que votre dos. Besoin d'exclure certains fichiers? Il suffit d'utiliser --exclude-from. Besoin de changer de propriétaire ou d'autorisations? rsync le fera pour vous.

La rsynccommande calcule toujours des sommes de contrôle sur chaque octet transféré.

L'option de ligne de commande indique --checksumuniquement si les sommes de contrôle des fichiers sont utilisées pour déterminer les fichiers à transférer ou non, à savoir:

-c, --checksum sauter en fonction de la somme de contrôle, pas de la durée et de la taille du mod "

La page de manuel dit aussi ceci:

Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté de la réception en vérifiant la somme de contrôle de l'ensemble du fichier, mais que la vérification automatique après le transfert n'a rien à voir avec l'option de cette option avant le transfert. à mettre à jour?" vérifier.

Ainsi rsync, toujours, toujours, calcule une somme de contrôle de l’ensemble du fichier du côté réception, même lorsque l’ -c/ --checksumoption est "désactivée".

rsync -aPhW --protocol=28aide à accélérer ces grandes copies avec RSYNC. Je vais toujours au rsync parce que la pensée d'être à mi-chemin de 90GiB et ça me fait peur de m'éloigner du CP

rsync est génial, mais rencontre des problèmes avec des arborescences de répertoires très volumineuses, car il les stocke en mémoire. Je cherchais juste à voir s'ils régleraient ce problème quand j'ai trouvé ce fil.

J'ai aussi trouvé:

http://matthew.mceachen.us/geek/gigasync/

Vous pouvez également briser manuellement l’arbre et exécuter plusieurs rsyncs.

Ce fil de discussion était très utile et, comme il y avait tellement d'options pour atteindre le résultat, j'ai décidé de comparer quelques-unes d'entre elles. Je pense que mes résultats peuvent aider les autres à savoir ce qui a fonctionné plus rapidement.

Pour déplacer 532 Go de données réparties sur 1 753 200 fichiers, nous avons eu ces temps:

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

Sur mon cas, j'ai préféré utiliser rsync + parallel. J'espère que cette information aidera plus de gens à choisir parmi ces alternatives.

Le benchmark complet est publié ici

Lors de la copie d'un répertoire local, mon expérience est que "cp -van src dest" est 20% plus rapide que rsync. En ce qui concerne la possibilité de redémarrage, c'est ce que fait "-n". Il vous suffit de récupérer le fichier partiellement copié. Pas douloureux sauf si c'est un ISO ou autre.

ARJ EST SI VIEILLE ÉCOLE !! Je doute vraiment que ARJ et / ou rsync donneront des performances.

Certainement ce que je fais toujours est d'utiliser cpio:

find . -print | cpio -pdm /target/folder

Ceci est presque rapide que le CP, nettement plus rapide que le goudron et sans canalisation.

Vous voulez absolument essayer rclone . Cette chose est rapide folle:

sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Ceci est une copie locale de et vers un SSD LITEONIT LCS-256 (256 Go).

Vous pouvez ajouter --ignore-checksumsur la première manche pour le rendre encore plus rapide.

Les deux fonctionneront très bien.

tar ferait également le travail, mais ne reprendrait pas d’être interrompu comme le ferait rsync.

Et si vous utilisez ARJ?

arj a -jm -m1 -r -je filepack /source

où -jm -m1sont les niveaux de compression et en -jefait un exécutable. Maintenant, vous avez une bash encapsulée de fichiers.

Puis pour l'extraction sur la carte cible

filepack -y  

où la carte source sera faite (où -yest toujours accepter, écraser, ignorer, etc.)

On peut ensuite scp ftp le filepack vers la zone cible et l'exécuter, si cela est possible.

Certaines accélérations peuvent être appliquées à rsync:

Éviter

• -z/ --compress: la compression ne chargera que la CPU car le transfert ne se fait pas sur un réseau mais sur de la RAM.
• --append-verify: reprendre un transfert interrompu. Cela semble être une bonne idée, mais le cas d'échec est dangereux: tout fichier de destination de la même taille (ou plus) que la source sera IGNORÉ. En outre, il contrôle l'ensemble du fichier à la fin, ce qui signifie qu'aucune accélération significative n'est nécessaire --no-whole-filelors de l'ajout d'un cas d'échec dangereux.

Utilisation

• -S/ --sparse: transforme les séquences de valeurs nulles en blocs clairsemés
• --partialou -Pqui est --partial --progress: sauvegardez tous les fichiers partiellement transférés pour les reprendre ultérieurement. Remarque: les fichiers n'auront pas de nom temporaire. Veillez donc à ce que personne d'autre ne s'attend à utiliser la destination avant la fin de la copie.
• --no-whole-filede sorte que tout ce qui doit être renvoyé utilise le transfert delta. Lire la moitié d'un fichier partiellement transféré est souvent beaucoup plus rapide que de le réécrire.
• --inplace pour éviter la copie de fichier (mais seulement si rien ne lit la destination jusqu'à la fin du transfert)