Solution 1 :
J'utiliserais rsync car cela signifie que s'il est interrompu pour une raison quelconque, vous pouvez le redémarrer facilement à très peu de frais. Et étant rsync, il peut même redémarrer à mi-chemin d'un gros fichier. Comme d'autres le mentionnent, il peut facilement exclure des fichiers. Le moyen le plus simple de conserver la plupart des choses est d'utiliser le -a
flag - '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 pourriez vouloir un complet copie des informations du système de fichiers ; et -a
n'inclut pas les liens physiques, les attributs étendus ou les ACL (sous Linux) ou le nor ci-dessus fourchettes de ressources (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 redémarrera, bien que le -u
le drapeau "copiera 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 conserver les autorisations. Donc :
cp -au source dest
Solution 2 :
Lors de la copie 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 vu 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 -)
Solution 3 :
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 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 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 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 la barre oblique finale sur /src/
est important.
Solution 4 :
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 du goudron, peut-être un peu plus rapide.
$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null
goudron
C'est également bon et continue en cas d'échec 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.
Solution 5 :
Ce fil a été très utile et parce qu'il y avait tellement d'options pour obtenir le résultat, j'ai décidé d'en comparer quelques-unes. Je crois que mes résultats peuvent être utiles aux autres pour avoir une idée de 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 moments :
rsync
a duré 232 minutestar
a duré 206 minutescpio
a duré 225 minutesrsync + parallel
a duré 209 minutes
Dans 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