Je dois copier 20 To de données sur une matrice Thunderbolt. Le boîtier où se trouvent les données n'a pas de connexion Thunderbolt, je vais donc devoir utiliser le réseau local de 1 Go pour cela. (Oui, cela va prendre une éternité).
J'ai essayé d'utiliser Filezilla/sftp, mais il a planté quand la file d'attente est devenue très grande. Faut-il utiliser rsync ou scp ?
Rsync est une bonne solution (scp est à peu près la même chose avec moins de fonctionnalités). Vous pouvez utiliser l'option -Z qui permet d'activer la compression zlib. En fonction de la vitesse de vos disques/ordinateur, cela peut être plus rapide que d'envoyer un fichier non compressé, par exemple si votre lien réseau est saturé. Vous pouvez également vouloir l'option mode archive, -a qui préservera les liens symboliques, les permissions et les heures de création/modification, ainsi que la copie récursive des répertoires. En fonction de ce que vous copiez, vous pouvez vouloir -E qui préserve les attributs étendus et les fourches de ressources mac. Enfin, --progress vous montrera des informations sur la progression.
Bien qu'il ne soit pas aussi omniprésent que rsync, j'ai utilisé par le passé un outil appelé "mpscp". http://www.sandia.gov/MPSCP/mpscp_design.htm
Provenant des Sandia National Labs, il s'agit d'un outil de copie de fichiers fonctionnant sur SSH qui est spécialement optimisé pour saturer les réseaux à haut débit entre des systèmes proches (comme la copie de téraoctets de données entre deux superordinateurs situés sur le même site, connectés via 10Gb+ ou Infiniband). Il fonctionne bien, mais peut être un peu difficile à configurer. Lors des tests, j'ai pu constater qu'il fonctionne facilement 2 à 3 fois plus vite que rsync.
Utilisez rsync et envisagez de l'utiliser avec rsyncd. Si vous utilisez rsync sans rsyncd, vous serez obligé d'utiliser ssh, ce qui implique l'utilisation d'une sorte de cryptage. Vous copiez probablement les données d'une machine plus ancienne vers une machine plus récente et la machine plus ancienne n'a peut-être pas la puissance CPU nécessaire pour crypter les données pour une transmission suffisamment rapide pour maintenir une liaison Ethernet gigabit saturée. Testez le transfert de lots de fichiers en utilisant les deux méthodes et voyez laquelle est la plus rapide.
Pour la même raison, je conseille de tester l'utilisation de l'option de compression de rsync avant de s'engager à l'utiliser. La compression est une autre activité gourmande en ressources CPU qui pourrait ne pas être en mesure de suivre les vitesses gigabit Ethernet lorsqu'elle est utilisée sur du matériel plus ancien. rsync est un programme vieux de quinze ans, écrit à l'époque où la majorité des gens, même dans les pays du premier monde, accédaient à Internet par modem commuté. Les compromis entre la bande passante du réseau et le CPU étaient alors bien différents.
Ces 20 To se présentent-ils sous la forme d'un petit nombre de gros fichiers (comme des vidéos, une base de données monstrueuse) ou de millions de fichiers plus petits ?
Si beaucoup de petits fichiers, j'opterais pour rsync pour la possibilité de redémarrage ou un flux tar pipé pour l'efficacité (une connexion réseau pour le tout, recommencez depuis le début si ça échoue).
tar -cf - * | ( cd newhome; tar -xf - )Le dossier distant doit être monté.
Pourriez-vous attacher directement le nouveau tableau avec une interface différente ? Le rsync local n'utilise pas ssh, vous supprimez donc ce point de défaillance. Oui, le Firewire 800 est plus lent que le Gigabit Ethernet, mais vous ne pouvez pas charger l'Ethernet à 100% - il pourrait être plus rapide avec le Firewire. Pour votre information, vous pouvez également mettre le Firewire en réseau si les boîtiers sont suffisamment proches. Ajoutez l'interface dans les préférences système -> réseau.
Une autre option serait d'essayer Bittorrent Sync ( http://www.bittorrent.com/sync ). Je l'ai utilisé pour synchroniser les photos et vidéos de famille entre les membres de notre famille à travers le WAN, mais il n'y a aucune raison pour qu'il ne fonctionne pas pour le réseau local. Il utilise des connexions peer-to-peer, de sorte que les données ne passent pas par un serveur comme ce serait le cas si vous essayiez d'utiliser quelque chose comme Dropbox (je ne pense pas que vous ayez 20 To d'espace Dropbox ou que vous ayez envie d'attendre aussi longtemps pour télécharger autant de données !)
Il est également pris en charge par de multiples plates-formes et offre donc une plus grande souplesse que rsync et tar.
LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.
