alternative plus rapide à cp -a


9

Pour un simple transfert de / home vers un autre disque cp -aque j'utilise, cela me semble extrêmement lent. Vous aimeriez connaître un moyen plus efficace de terminer la tâche. J'ai / home monté en tant que volume logique, mais le disque cible n'est pas un système LVM


4
Si cpc'est lent, d'autres méthodes le seraient aussi. À moins que ce ne soit pas une copie orientée fichier
daisy

Essayez de diagnostiquer votre goulot d'étranglement, cela dépend de votre configuration particulière. Vous voudrez peut-être essayer l' noatimeoption de montage pour réduire les écritures inutiles, spécialement dans le système de fichiers source.
Elias Torres Arroyo

Réponses:


16

Essayez tar, pax, cpioavec mise en mémoire tampon de quelque chose.

(cd /home && bsdtar cf - .) |
  pv -trab -B 500M |
  (cd /dest && bsdtar xpSf -)

Je suggère bsdtarau lieu de tarparce qu'au moins sur certaines distributions Linux tarest GNU tar qui contrairement à bsdtar(from libarchive) ne gère pas la préservation des attributs étendus ou des ACL ou des attributs linux.

pvtamponnera jusqu'à 500M de données afin de mieux s'adapter aux fluctuations des vitesses de lecture et d'écriture sur les deux systèmes de fichiers (bien qu'en réalité, vous aurez probablement un disque plus lent que l'autre et le mécanisme de réécriture du système d'exploitation fera cette mise en mémoire tampon comme eh bien, cela ne fera probablement pas beaucoup de différence). Les anciennes versions de pvne prennent pas en charge -a(pour les rapports de vitesse moyenne), vous pouvez les utiliser pv -B 200Mseules.

Dans tous les cas, ceux-ci n'auront pas la limitation de cp, cela fait les lectures et les écritures séquentiellement. Ici, nous avons deux tarfonctionnant simultanément, donc l'un peut lire un FS tandis que l'autre est occupé à attendre que l'autre FS termine l'écriture.

Pour ext4 et si vous copiez sur une partition qui est au moins aussi grande que la source, voyez aussi celle clone2fsqui fonctionne ntfsclone, c'est-à-dire qui copie les blocs alloués uniquement et séquentiellement, donc le stockage rotationnel sera probablement le plus efficace.

partclone généralise cela à quelques systèmes de fichiers différents.

Maintenant, quelques éléments à prendre en compte lors du clonage d'un système de fichiers.

Le clonage reviendrait à copier tous les répertoires, fichiers et leur contenu ... et tout le reste. Maintenant, tout le reste varie d'un système de fichiers à un autre. Même si nous ne considérons que les caractéristiques communes des systèmes de fichiers Unix traditionnels, nous devons considérer:

  • liens: liens symboliques et liens durs. Parfois, nous devrons réfléchir à ce qu'il faut faire avec les liens symboliques absolus ou les liens symboliques qui pointent du système de fichiers / répertoire à cloner
  • dernière modification, accès et temps de changement: seuls les deux premiers peuvent être copiés à l'aide de l'API du système de fichiers (cp, tar, rsync ...)
  • clarté: vous avez ce fichier clairsemé de 2 To qui est une image de disque VM qui ne prend que 3 Go d'espace disque, le reste étant clairsemé, faire une copie naïve remplirait le lecteur de destination.

Ensuite, si vous envisagez ext4et la plupart des systèmes de fichiers Linux, vous devrez considérer:

  • ACL et autres attributs étendus (comme ceux utilisés pour SELinux)
  • Attributs Linux comme des indicateurs immuables ou à ajouter uniquement

Tous les outils d' aide à tous ceux, ou quand ils le font, vous devez activer explicitement comme --sparse, --acls... options rsync, tar... Et lors de la copie sur un des systèmes de fichiers différents, vous devez considérer le cas où ils ne le font pas prendre en charge le même ensemble de fonctionnalités.

Vous devrez peut-être également tenir compte des attributs du système de fichiers eux-mêmes comme l'UUID, l'espace réservé à la racine, la fréquence fsck, le comportement de journalisation, le format des répertoires ...

Ensuite, il existe des systèmes de fichiers plus complexes, où vous ne pouvez pas vraiment copier les données en copiant des fichiers. Considérez par exemple zfsou btrfsquand vous pouvez prendre des instantanés de sous-volumes et les dériver ... Ceux-ci auraient leurs propres outils dédiés pour copier les données.

La copie octet à octet du périphérique de bloc (ou au moins des blocs alloués lorsque cela est possible) est souvent la plus sûre si vous voulez vous assurer que vous copiez tout. Mais méfiez-vous du problème de conflit UUID, et cela implique que vous copiez sur quelque chose de plus grand (bien que vous puissiez redimensionner une copie instantanée de la source avant de copier).


1
GNU tar a la --aclspossibilité de stocker les ACL dans l'archive. Et je serais surpris si un outil étranger (en bsdtarquelque sorte) comme le gère mieux que celui (essentiellement) natif ...
vonbrand

@vonbrand. Votre tar doit avoir été corrigé pour cela (je pense que RedHat a un correctif pour GNU tar pour les ACL), car la dernière version de GNU tar ne prend pas en charge une telle option. Il existe un certain nombre d'implémentations de tarLinux ( star, bsdtar, tar), je ne suis pas au courant que GNU tar est mieux que les autres. Le choix des outils GNU est généralement plus politique que technique (voir par exemple bash).
Stéphane Chazelas

1
L'utilisation d'outils GNU peut être un choix politique, mais c'est néanmoins le choix par défaut. Et comme ils sont beaucoup plus populaires que les alternatives, il y a aussi plus de main-d'œuvre de développeur (et autres) derrière eux.
vonbrand

merci, la prochaine fois j'utiliserai pv et tar plutôt que cp
Yurij73

@ StéphaneChazelas Actuellement, GNU tar prend en charge--acls
Ploni

4

Je recommande rsync, par exemple:

rsync -av --progress --stats dest orig

Ou, pour transférer avec compression:

rsync -avz --progress --stats dest orig

1
rsyncest généralement beaucoup plus lent que cpoutar|tar
Stéphane Chazelas

Merci pour cette information :) mais je n'ai jamais comparé ces deux ...
Victor Aurélio


Je ne ferais pas trop confiance à cet article. J'utilise rsync assez fréquemment et une copie régulière à 130-170 Mo / sec.
laebshade

9
rsyncest surtout efficace si vous avez déjà partiellement les données source disponibles sur le volume de destination, car il ne transférera que les données manquantes / modifiées. Je ne l'utiliserais pas pour une "première copie" rapide.
Totor
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.