Le moyen le plus rapide de transférer 55 Go d'images vers un nouveau serveur
J'ai actuellement deux serveurs CentOS. J'ai besoin de savoir comment et quelle serait la manière la plus rapide de "tar" le répertoire d'images et de le SCP dessus?
Est-ce le moyen le plus rapide que je viens de suggérer, car le goudronnage prend une éternité ... J'ai exécuté la commande:
tar cvf imagesbackup.tar images
Et j'allais juste l'explorer.
Faites-moi savoir s'il existe un moyen plus rapide. J'ai accès à distance/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 l'entrée/sortie vers et depuis ces commandes distantes via SSH comme si elles étaient locales. Mettre la commande entre guillemets évite toute confusion, surtout lors de l'utilisation de la redirection.
Ou, vous pouvez extraire directement le fichier tar sur l'autre serveur:
server1$ tar -zc ./path | ssh server2 "tar -zx -C /destination"
Notez l'option -C Rarement utilisée. Cela signifie "changer ce répertoire avant de faire quoi que ce soit."
Ou, peut-être que vous voulez "tirer" du serveur de destination:
server2$ tar -zx -C /destination < <(ssh server1 "tar -zc -C /srcdir ./path")
Notez que la construction <(cmd) est nouvelle pour bash et ne fonctionne pas sur les anciens systèmes . Il exécute un programme et envoie la sortie à un canal, et remplace ce canal dans la commande comme s'il s'agissait d'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 /destination
Ou, vous pouvez vous épargner du chagrin et utiliser simplement 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 sur une connexion très rapide, cela peut en fait rendre l'opération plus de temps. En effet, votre ordinateur peut ne pas être en mesure de compresser assez rapidement pour suivre le rythme: si la compression 100 Mo prend plus de temps qu'il ne le faudrait pour envoyer 100 Mo, puis il est plus rapide de l'envoyer non compressé.
Alternativement, vous voudrez peut-être envisager de canaliser pour gzip vous-même (plutôt que d'utiliser l'option -z) afin de pouvoir spécifier un niveau de compression. D'après mon expérience, sur des connexions réseau rapides avec des données compressibles, l'utilisation de gzip au niveau 2 ou 3 (la valeur par défaut est 6) donne le meilleur débit global dans la plupart des cas. Ainsi:
server1$ tar -c ./path | gzip -2 | ssh server2 "cat > ~/file.tar.gz"
Je serais tenté de le resynchroniser sur moi-même - il effectue la compression et gère bien la perte de liaison.
Si vous les tarissez et rien d'autre, cela vous fera perdre beaucoup de temps avec un gain de vitesse minimal.
Donc, simplement tarer les fichiers avec les commutateurs cvf coûtera effectivement le temps qu'il faut pour lire toutes les images de 55 Go et les réécrire sur le disque. (En fait, ce sera encore plus de temps perdu car il y aura des frais généraux considérables).
Il n'y a qu'un seul avantage que vous gagnez ici, la surcharge pour le téléchargement de nombreux fichiers est réduite. Vous pouvez obtenir des temps de transfert plus rapides si vous compressez les images (mais comme je pense qu'elles sont déjà dans un format compressé, cela ne sera pas d'une grande aide). Juste plus de perte de temps informatique.
Le plus grand inconvénient du transfert d'un archivage de goudron énorme sur du fil est que si quelque chose ne va pas, cela peut signifier que vous devez recommencer.
J'utiliserais de cette façon:
md5sum /images/* > md5sum.txt
scp -r images/* user@Host:/images/
Sur le nouveau serveur
md5sum /images/* > md5sum_new.txt
Et puis juste diff. Et comme scp prend en charge la compression à la volée, il n'est pas nécessaire d'avoir des archives séparées.
Éditer
Je garderai les informations MD5 car elles ont été utiles au PO. Mais un commentaire m'a frappé avec de nouvelles perspectives. Un peu de recherche a donc fourni cette information utile. Veuillez noter que le sujet ici est SFTP et non directement SCP.
Contrairement à FTP, 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 fait 32 Ko. Le protocole SFTP effectue une somme de contrôle sur chaque fichier de 32 Ko lors de son envoi et inclut cette somme de contrôle avec ce paquet. Le récepteur obtient ce paquet et déchiffre 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 existe une vérification d'intégrité très granulaire qui est effectuée dans le cadre du transfert.) Ainsi, le protocole lui-même est plus lent (en raison des frais généraux supplémentaires), mais la réussite d'un transfert signifie, de facto, qu'il a été transféré intégralement et qu'il n'est pas nécessaire d'effectuer un contrôle supplémentaire.
En plus de la suggestion md5sum de Pacey, 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 directement sur l'autre serveur. Démarrez-les tous les deux en tandem (-w5 vous donne 5 secondes de grâce.) et regardez-le disparaître. Si la bande passante est étroite, ajoutez -z au goudron aux deux extrémités.
Si vous avez un accès ssh, vous avez un accès rsync.
rsync -av -e ssh /storage/images/ user@[ip or domain name]:/storage/images/
ou
rsync -av -e "ssh -l user" /storage/images/ [ip or domain name]:/storage/images/
Si vous recevez une erreur du type "erreur rsync: certains fichiers n'ont pas pu être transférés (code 23) sur main.c (977) [sender = 2.6.9]", vérifiez votre utilisateur et vos groupes entre les serveurs; vous pourriez avoir un décalage.
Utilisez l'option rsync "-z" si vous souhaitez que rsync compresse le transfert. Cette option utilisera plus de CPU mais moins de bande passante, alors soyez conscient de cela.
Il y a une option "--progress" qui vous donnera un pourcentage transféré, ce qui est plutôt sympa si vous aimez ce genre de chose.
Un point - tous les hôtes n'ont pas rsync et mai hôtes peuvent avoir différentes versions de tar. Pour cette raison, on pourrait recommander comme premier port d'escale en utilisant le cpio souvent négligé.
Vous pouvez cpio sur ssh pour effectuer une réplication ad hoc des structures de fichiers/répertoires entre les hôtes. De cette façon, vous avez un meilleur contrôle sur ce qui est envoyé, car vous devez "nourrir" cpio, nom-nom. Il est également plus portable, le cpio ne change pas grand-chose - c'est un point important si vous vous occupez de plusieurs hôtes dans un environnement hétérogène.
Exemple de copie/exportation/home et sous-répertoires vers l'hôte distant:
cd /export/ find . home -print | cpio -oaV | ssh 10.10.10.10 'cd /export/home; cpio -imVd'
Ce qui précède copiera le contenu de/export/home et tous les sous-répertoires vers/export/home sur l'hôte distant.
J'espère que cela t'aides.
Ou vous pouvez toujours utiliser des tuyaux en goudron:
(cd /path && tar -cjf - * ) | ssh user@Host 'tar -xjf - -C /path'
'j' = bzip2, vous pouvez utiliser 'z' pour gzip ou --lzma si votre tar le prend en charge.
Sont-ils sur un réseau partagé au lieu d'avoir besoin d'Internet pour transférer des fichiers? NFS ou FTP peut être beaucoup plus rapide que la surcharge de SCP, bien que vous perdriez le cryptage pendant le transfert.