Copier une grande arborescence de répertoires localement? cp ou rsync?
Je dois copier une grande arborescence de répertoires, environ 1,8 To. Tout est local. Par habitude, j'utiliserais rsync, mais je me demande s'il y a beaucoup d'intérêt, et si je préfère utiliser cp.
Je m'inquiète des autorisations et de l'uid/gid, car elles doivent être conservées dans la copie (je sais que rsync le fait). Ainsi que des choses comme des liens symboliques.
La destination est vide, je n'ai donc pas à me soucier de la mise à jour conditionnelle de certains fichiers. Tout est disque local, donc je n'ai pas à me soucier de ssh ou de réseau.
La raison pour laquelle je serais tenté de rsync, c'est parce que rsync pourrait faire plus que ce dont j'ai besoin. fichiers de sommes de contrôle rsync. Je n'ai pas besoin de cela, et je crains que cela ne prenne plus de temps que cp.
Alors, que pensez-vous, rsync ou cp?
J'utiliserais rsync car cela signifie que s'il est interrompu pour une raison quelconque, vous pouvez le redémarrer facilement avec très peu de frais. Et étant rsync, il peut même redémarrer à mi-chemin dans un fichier volumineux. Comme d'autres le mentionnent, il peut facilement exclure des fichiers. La manière la plus simple de conserver la plupart des choses est d’utiliser le drapeau -a - ‘archive’. Donc:
rsync -a source dest
Bien que l'UID/GID et les liens symboliques soient préservés par -a (Voir -lpgo), Votre question implique que vous souhaiterez peut-être une copie complète des informations du système de fichiers; et -a n'inclut pas les liens durs, les attributs étendus ou les ACL (sous Linux) ou les fourchettes de ressources ci-dessus ni (sous OS X.) Ainsi, pour une copie robuste de un système de fichiers, vous devrez inclure ces indicateurs:
rsync -aHAX source dest # Linux
rsync -aHE source dest # OS X
Le cp par défaut redémarrera, bien que le drapeau -u"copie uniquement lorsque le fichier SOURCE est plus récent que le fichier de destination ou lorsque le fichier de destination est manquant". Et l'indicateur -a (Archive) sera récursif, pas recopiez les fichiers si vous devez redémarrer et conserver les autorisations. Donc:
cp -au source dest
Lors de la copie vers 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 vu des transferts 17% plus rapides en utilisant les paramètres rsync ci-dessus sur la commande tar suivante comme suggéré par 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 rsync. La première passe consiste à le tarer, quelque chose comme ceci:
# (cd /src; tar cf - .) | (cd /dst; tar xpf -)
Habituellement, avec une grande quantité de fichiers, il y en aura certains que tar ne pourra pas gérer pour une raison quelconque. Ou peut-être que le processus sera interrompu, ou s'il s'agit d'une migration de système de fichiers, vous voudrez peut-être faire la copie initiale avant l'étape de migration réelle. En tout cas, après la copie initiale, je fais une étape rsync pour tout synchroniser:
# cd /dst; rsync -avPHSx --delete /src/ .
Notez que la barre oblique de fin sur /src/ est important.
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 le goudron, peut-être un peu plus vite.
$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null
tar
Ceci est également bon et se poursuit 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. N'oubliez pas le -a changez lorsque vous décidez d'utiliser cp.
Si vous avez vraiment besoin d'une réponse: j'utiliserais rsync car il est beaucoup plus flexible. Besoin d'arrêter avant la fin de la copie? Il suffit de ctrl-c et de reprendre dès que votre dos. Besoin d'exclure certains fichiers? Utilisez simplement --exclude-from. Besoin de changer de propriétaire ou d'autorisations? rsync le fera pour vous.
La commande rsync calcule toujours des sommes de contrôle sur chaque octet qu'elle transfère.
L'option de ligne de commande --checksum concerne uniquement si les sommes de contrôle des fichiers sont utilisées pour déterminer les fichiers à transférer ou non, c'est-à-dire:
-c, --checksumignorer en fonction de la somme de contrôle, pas du temps et de la taille du module "
La page de manuel dit également ceci:
Notez que rsync vérifie toujours que chaque fichier transféré a été correctement reconstruit du côté réception en vérifiant la somme de contrôle de tout le fichier, mais que la vérification automatique après le transfert n'a rien à voir avec cette option avant le transfert "Ce fichier a-t-il besoin à mettre à jour?" vérifier.
Donc rsync calcule également, toujours, une somme de contrôle de tout le fichier côté réception, même lorsque -c/ --checksum l'option est "off".
rsync -aPhW --protocol=28 aide à accélérer ces grandes copies avec RSYNC. Je vais toujours rsync parce que l'idée d'être à mi-chemin à travers 90GiB et ça me fait peur loin du CP
Ce fil était très utile et comme il y avait tellement d'options pour obtenir le résultat, j'ai décidé d'en évaluer quelques-unes. Je crois que mes résultats peuvent être utiles aux autres qui ont une idée de ce qui a fonctionné plus rapidement.
Pour déplacer 532 Go de données réparties entre 1 753 200 fichiers , nous avons eu ces temps:
rsynca pris 232 minutestara pris 206 minutescpioa pris 225 minutesrsync + parallela pris 209 minutes
Sur mon cas, j'ai préféré utiliser rsync + parallel. J'espère que ces informations aideront plus de gens à choisir parmi ces alternatives.
Le benchmark complet est publié ici
rsync est génial, mais a des problèmes avec les très grandes arborescences de répertoires car il stocke les arborescences en mémoire. Je cherchais simplement à voir s'ils résoudraient ce problème lorsque j'ai trouvé ce fil.
J'ai aussi trouvé:
http://matthew.mceachen.us/geek/gigasync/
Vous pouvez également casser manuellement l'arborescence et exécuter plusieurs rsyncs.
Lors de la copie locale 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 rm le fichier partiellement copié. Pas douloureux à moins que ce soit un ISO ou quelque chose comme ça.
ARJ IS SO OLD SCHOOL !! Je doute vraiment que ARJ et/ou rsync donnent des performances.
Certainement ce que je fais toujours est d'utiliser cpio:
find . -print | cpio -pdm /target/folder
C'est presque rapide que CP, nettement plus rapide que le goudron et sans rien tuyauter.
Vous voulez certainement essayer rclone . Cette chose est folle rapidement:
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
Il s'agit d'une copie locale depuis et vers un SSD LITEONIT LCS-256 (256 Go).
Vous pouvez ajouter --ignore-checksum lors de la première exécution pour le rendre encore plus rapide.
Les deux fonctionneront très bien.
Il existe des accélérations qui peuvent être appliquées à rsync:
Éviter
-z/--compress: la compression ne chargera que le CPU car le transfert ne se fait pas sur un réseau mais sur la RAM.--append-verify: reprendre un transfert interrompu. Cela semble être une bonne idée, mais il a un cas d'échec dangereux: tout fichier de destination de la même taille (ou plus) que la source sera IGNORÉ. En outre, il totalise le fichier à la fin, ce qui signifie aucune accélération significative sur--no-whole-filelors de l'ajout d'un cas d'échec dangereux.
Utilisation
-S/--sparse: transformer des séquences de null en blocs clairsemés--partialou-Plequel est--partial --progress: enregistrez tous les fichiers partiellement transférés pour une future reprise. Remarque: les fichiers n'auront pas de nom temporaire, assurez-vous donc que rien d'autre ne s'attend à utiliser la destination tant que la copie entière n'est pas terminée.--no-whole-filepour que tout ce qui doit être renvoyé utilise le transfert delta. La lecture de la moitié d'un fichier partiellement transféré est souvent beaucoup plus rapide que de le réécrire.--inplacepour éviter la copie du fichier (mais seulement si rien ne lit la destination jusqu'à ce que le transfert soit terminé)
tar ferait aussi le travail, mais ne reprendra pas d'être interrompu comme le fera rsync.
Et si vous utilisez ARJ?
arj a -jm -m1 -r -je filepack /source
où -jm -m1 sont des niveaux de compression et -je en fait un exécutable. Vous avez maintenant un bash de fichiers encapsulé.
Puis pour l'extraction vers la carte cible
filepack -y
où la carte source sera créée (où -y est toujours accepter, écraser, ignorer, etc.)
On peut alors scp ftp le pack de fichiers dans la zone cible et l'exécuter, si cela est possible.