Je dispose actuellement de deux serveurs CentOS. J'ai besoin de savoir comment et quel serait le moyen le plus rapide de "tar" le répertoire des images et de le transférer par SCP ?
Est-ce le moyen le plus rapide que je viens de suggérer, parce que le goudronnage prend une éternité... J'ai lancé la commande :
tar cvf imagesbackup.tar imagesEt j'allais juste le transférer.
Faites-moi savoir s'il y a un moyen plus rapide. J'ai un accès distant/SSH aux deux machines.
Au lieu d'utiliser tar pour écrire sur votre disque local, vous pouvez écrire directement sur le serveur distant via le réseau en utilisant ssh.
server1$ tar -zc ./path | ssh server2 "cat > ~/file.tar.gz"Toute chaîne qui suit votre commande "ssh" sera exécutée sur le serveur distant au lieu de la connexion interactive. Vous pouvez diriger les entrées/sorties vers et depuis ces commandes distantes via SSH comme si elles étaient locales. Le fait de mettre la commande entre guillemets évite toute confusion, notamment lors de l'utilisation de la redirection.
Ou bien, vous pouvez extraire le fichier tar sur l'autre serveur directement :
server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"Notez l'utilisation rare de -C option. Elle signifie "passer d'abord dans ce répertoire avant de faire quoi que ce soit".
Ou bien, vous voulez peut-être "tirer" du serveur de destination :
server2$ tar -zx -C /destination < <(ssh server1 "tar -zc -C /srcdir ./path")Notez que le <(cmd) construct est nouveau dans bash et ne fonctionne pas sur les anciens systèmes. Elle exécute un programme et envoie la sortie vers un pipe, et substitue ce pipe dans la commande comme si c'était un fichier.
J'aurais pu facilement écrire ce qui précède comme suit :
server2$ tar -zx -C /destination -f <(ssh server1 "tar -zc -C /srcdir ./path")Ou comme suit :
server2$ ssh server1 "tar -zc -C /srcdir ./path" | tar -zx -C /destinationOu bien, vous pouvez vous épargner quelques soucis et utiliser rsync :
server1$ rsync -az ./path server2:/destination/Enfin, n'oubliez pas que la compression des données avant le transfert réduira votre bande passante, mais que sur une connexion très rapide, elle peut en fait faire durer l'opération. plus de temps . Cela est dû au fait que votre ordinateur n'est peut-être pas en mesure de compresser assez rapidement pour suivre : si en comprimant 100MB prend plus de temps qu'il n'en faudrait pour envoyer 100 Mo, il est plus rapide de l'envoyer sans compression.
Vous pouvez également envisager d'utiliser vous-même le protocole gzip (plutôt que l'option -z) afin de pouvoir spécifier un niveau de compression. D'après mon expérience, sur les connexions réseau rapides avec des données compressibles, l'utilisation de gzip au niveau 2 ou 3 (le niveau par défaut est 6) donne le meilleur débit global dans la plupart des cas. Par exemple :
server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
Rsync a fonctionné à merveille : compression à la volée, copie de dossiers entiers, reprise en cas de lien brisé. Le tout en une seule commande simple. Je l'adore. Voici les options que j'ai trouvées utiles : z : compresser r : recurse = copier le sous-dossier v : verbose. Mon exemple de commande Rsync : rsync -azvr /src-path/ username@dest_server:/dest/path/
Rsync n'est pas nécessairement le bon outil dans ce cas. particulier cas d'utilisation. Elle est inefficace pour copier de nombreux petits fichiers (par exemple 55 Go d'images) en une seule fois, bien que sa capacité à ne pas télécharger les fichiers déjà transférés puisse évidemment compenser cet inconvénient selon votre cas d'utilisation.
Si vous vous contentez de les goudronner et de ne rien faire d'autre, vous perdrez beaucoup de temps pour un gain de vitesse minime.
Ainsi, le simple fait de tarer les fichiers avec les commutateurs cvf coûtera effectivement le temps nécessaire pour lire toutes les images de 55 Go et les réécrire sur le disque. (Effectivement, ce sera encore plus de temps perdu puisqu'il y aura un overhead considérable).
Il n'y a qu'un seul avantage à en tirer : la réduction des frais généraux liés au téléchargement de nombreux fichiers. Vous pourriez obtenir des temps de transfert plus rapides si vous compressez les images (mais comme je crois qu'elles sont déjà dans un format compressé, cela ne sera pas d'une grande aide). Encore un gaspillage de temps de calcul.
Le plus gros inconvénient du transfert d'une énorme archive de goudron par câble est que si quelque chose ne va pas, vous pouvez être obligé de tout recommencer.
Je l'utiliserais de cette façon :
md5sum /images/* > md5sum.txt
scp -r images/* user@host:/images/Sur le nouveau serveur
md5sum /images/* > md5sum_new.txtEt puis juste diff . Et comme scp prend en charge la compression à la volée, il n'y a pas besoin d'archives séparées.
Je vais garder l'information MD5 puisqu'elle a été utile à l'OP. Mais un commentaire m'a donné une nouvelle idée. Un peu de recherche m'a permis d'obtenir cette information utile. Veuillez noter que le sujet ici est SFTP et non pas directement SCP. .
Contrairement au FTP, le SFTP ajoute des frais généraux au transfert de fichiers. Lorsqu'un fichier est transféré entre le client et le serveur, il est divisé en petits morceaux appelés "paquets". Par exemple, supposons que chaque paquet fasse 32 Ko. Le protocole SFTP effectue une somme de contrôle sur chaque fichier de 32 Ko à mesure qu'il est envoyé, et inclut cette somme de contrôle dans le paquet. Le récepteur reçoit ce paquet et décrypte les données, puis vérifie la somme de contrôle. La somme de contrôle elle-même est plus "forte" que la somme de contrôle CRC32. (Parce que SFTP utilise une somme de contrôle de 128 bits ou plus, comme MD5 ou SHA, et parce que cela est fait sur chaque paquet, il y a un contrôle d'intégrité très granulaire qui est accompli dans le cadre du transfert). Ainsi, le protocole lui-même est plus lent (en raison de la surcharge supplémentaire), mais l'achèvement réussi d'un transfert signifie, de facto, qu'il a été transféré intégralement et qu'il n'y a pas besoin d'une vérification supplémentaire.
Merci beaucoup, que fait le md5sum ? et qu'est-ce que diff ? Merci, c'est maintenant possible !
Md5sum (ou md5) prend une somme de contrôle des fichiers. Diff recherche les différences entre les fichiers (man diff). La somme de contrôle crée une chaîne, un hachage, qui, si le fichier est modifié en transit... un bit inversé, une erreur... ne correspondra pas lorsque vous le reprendrez de l'autre côté. Pour les gros fichiers, le risque d'erreur est plus élevé. C'est pourquoi les sites qui vous permettent de télécharger des fichiers .iso proposent souvent une somme de contrôle MD5 à laquelle vous pouvez comparer le fichier téléchargé pour vous assurer qu'il correspond et n'est pas corrompu.
Scp est crypté et garantit l'intégrité sur la ligne. Il y a toujours une petite chance que les données aient été corrompues en mémoire ou sur le disque bien sûr, mais c'est plutôt rare.
En plus de la suggestion de Pacey concernant le md5sum, j'utiliserais ce qui suit :
Sur la destination : nc -w5 -l -p 4567 | tar -xvf -
Puis sur la source : tar -cvf - /path/to/source/ | nc -w5 destinationserver 4567
C'est toujours un tar/untar, et il n'y a pas de cryptage, mais c'est direct vers l'autre serveur. Lancez-les tous les deux en tandem ( -w5 vous donne 5 secondes de grâce) et regardez-le partir. Si la bande passante est étroite, ajoutez -z au tar aux deux extrémités.
Je pense que c'est l'inverse, il doit d'abord exécuter sur la destination (pour ouvrir le socket) et ensuite sur la source (pour distribuer).
Non, juste l'IP. netcat n'utilise pas de protocole autre que TCP :) Cette commande sera également la plus rapide de toutes les commandes données ci-dessus. Il y a exactement une lecture par fichier à la source, le minimum de trafic réseau pour transférer les fichiers, et exactement une écriture par fichier à la destination. Si vous avez des cycles CPU libres, l'ajout de l'option -z (pour la compression) accélérera encore plus le processus, car moins de données réseau doivent être transférées.
Un point - tous les hôtes ne disposent pas de rsync et certains hôtes peuvent avoir des versions différentes de tar. Pour cette raison, on pourrait recommander comme premier port d'appel d'utiliser le très négligé cpio.
Vous pouvez cpio sur ssh pour faire une réplication ad-hoc des structures de fichiers/répertoires entre les hôtes. De cette façon, vous avez un contrôle plus fin sur ce qui est envoyé, car vous devez "alimenter" cpio, nom-nom. C'est aussi plus facile à argumenter, cpio ne change pas beaucoup - c'est un point important si vous vous occupez de plusieurs hôtes dans un environnement hétérogène.
Exemple de copie de /export/home et de sous-répertoires sur l'hôte distant :
cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'L'opération ci-dessus copiera le contenu de /export/home et de tous les sous-répertoires vers /export/home sur l'hôte distant.
J'espère que cela vous aidera.
Il a mentionné qu'il s'agissait de deux boîtes CentOS, donc elles ont rsync et des versions compatibles de tar. Des outils comme rsync ont été créés pour remplacer des outils comme cpio :). Vous ne pouvez pas "reprendre" avec cpio, du moins sans savoir exactement d'où vous voulez partir et filtrer votre recherche comme il se doit. Ce qui est une surcharge de temps inutile. Ceci dit, une information utile pour les "vieilles" boîtes UNIX :)
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
13 votes
Sneakernet ?
0 votes
Véase unix.stackexchange.com/questions/227951/