J'ai actuellement deux serveurs CentOS. J'ai besoin de savoir comment et quel serait le moyen le plus rapide de "bander" le répertoire des images et de le placer dans SCP?

Est-ce le moyen le plus rapide que je viens de suggérer, parce que le goudron prend une éternité ... J'ai lancé la commande:

tar cvf imagesbackup.tar images

Et j'allais juste le terminer.

Faites-moi savoir s'il existe 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 à l'aide de 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. Mettre la commande entre guillemets évite toute confusion, en particulier 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' -Coption rarement utilisée . Cela signifie "aller dans ce répertoire avant de faire quoi que ce soit".

Ou peut-être voulez-vous "extraire" du serveur de destination:

server2$ tar -zx -C /destination < <(ssh server2 "tar -zc -C /srcdir ./path")

Notez que la <(cmd) construction est nouvelle pour bash et ne fonctionne pas sur les systèmes plus anciens. Il exécute un programme et envoie la sortie à un canal, puis le remplace dans la commande comme s'il s'agissait d'un fichier.

J'aurais simplement pu écrire ce qui précède comme suit:

server2$ tar -zx -C /destination -f <(ssh server2 "tar -zc -C /srcdir ./path")

Ou comme suit:

server2$ ssh server2 "tar -zc -C /srcdir ./path" | tar -zx -C /destination

Ou, vous pouvez vous épargner un peu de chagrin et utiliser simplement rsync:

server1$ rsync -az ./path server2:/destination/

Enfin, rappelez-vous que la compression des données avant le transfert réduira votre bande passante. Toutefois, avec une connexion très rapide, l'opération risque de prendre plus de temps . En effet, votre ordinateur ne sera peut-être pas en mesure de compresser assez rapidement pour suivre le rythme: si compresser 100 Mo prend plus de temps qu'il n'en faudrait pour envoyer 100 Mo, il est alors plus rapide de l'envoyer non compressé.

Alternativement, vous pouvez envisager de canaliser vous-même le gzip (plutôt que d'utiliser 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, utiliser 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 rynchroniser sur moi-même - il compresse et gère bien la perte de liaison.

Si vous vous contentez de les fixer et rien d’autre, vous perdrez des tonnes de temps avec un gain de vitesse minimal.

Il suffit donc de tarer les fichiers à l’aide des commutateurs cvf pour vous permettre de gagner du temps en lecture et en écriture sur toutes les images de 55 Go. (Effectivement, ce sera encore plus de temps perdu car il y aura des frais généraux considérables).

Vous n’obtenez ici qu’un avantage: les frais généraux liés au téléchargement de nombreux fichiers sont réduits. 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 très utile). Juste plus de perte de temps de calcul.

Le plus gros inconvénient du transfert d'une énorme archive de goudron sur fil est que si quelque chose ne va pas, cela peut signifier que vous devez recommencer.

Je voudrais utiliser 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 de créer des archives séparées.

Modifier

Je garderai les informations MD5 car elles ont été utiles au PO. Mais un commentaire m'a frappé avec une nouvelle perspicacité. Donc, un peu de recherche a fourni cette information utile. Veuillez noter que le sujet ici est SFTP et non directement SCP .

Contrairement à FTP, SFTP ajoute une surcharge au transfert de fichiers. Lorsqu'un fichier est transféré entre le client et le serveur, il est divisé en fragments plus petits appelés "paquets". Par exemple, supposons que chaque paquet représente 32 Ko. Le protocole SFTP effectue une somme de contrôle sur chaque fichier de 32 Ko au fur et à mesure de son envoi et inclut cette somme de contrôle avec ce paquet. Le destinataire 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. (Comme SFTP utilise une somme de contrôle de 128 bits ou plus, telle que MD5 ou SHA, et comme cela est fait pour chaque paquet, il existe une vérification d'intégrité très granulaire qui est réalisé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,

En plus de la suggestion md5sum de Pacey, j'aimerais utiliser les éléments suivants:

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 à l'autre serveur. Commencez les deux en tandem ( -w5vous donne 5 secondes de grâce.) Et regardez-le aller. Si la bande passante est étroite, ajoutez -z au goudron aux deux extrémités.

Un point - tous les hôtes n’ont pas rsync et il se peut que les hôtes aient des versions différentes de tar. Pour cette raison, on pourrait recommander comme premier port d'escalade en utilisant le cpio souvent négligé.

Vous pouvez utiliser 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 contrôle plus précis sur ce qui est envoyé car vous devez "nourrir" cpio, nom-nom. 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 / export / home et de sous-répertoires vers un 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 copie le contenu de / export / home et de tous les sous-répertoires dans / export / home sur l’hôte distant.

J'espère que cela t'aides.

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) dans main.c (977) [expéditeur = 2.6.9]", vérifiez votre utilisateur et vos groupes entre les serveurs; vous pourriez avoir une discordance.

Utilisez l'option "-z" de rsync si vous voulez que rsync comprime le transfert. Cette option utilisera plus de CPU mais moins de bande passante, donc soyez conscient de cela.

Il existe une option "--progress" qui vous donnera un pourcentage transféré, ce qui est plutôt agréable si vous aimez ce genre de chose.

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 perdiez le cryptage pendant le transfert.

Ou vous pouvez toujours utiliser des tuyaux de 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.