rsync continue de se déconnecter: tuyau cassé

J'utilise rsyncpour sauvegarder mon répertoire personnel. Cela fonctionne bien depuis longtemps. Voici la commande que j'utilise:

rsync \
    -pavz \
    --delete \
    --exclude 'mnt/' \
    --exclude '.cache/' \
    --exclude 'Videos/' \
    --exclude 'Music/' \
    --exclude 'Documents/virtualbox' \
    /home/"${USER}" "${server}":"${dir}" 2>> "${errorFile}"

Cependant, j'ai changé le serveur sur lequel je sauvegarde et rsyncdémarre et s'exécute maintenant pendant quelques secondes (jusqu'à quelques minutes), mais s'arrête ensuite avec le message d'erreur

packet_write_wait: Connection to x.x.x.x: Broken pipe
rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.1]

Puisqu'il fonctionne sur d'autres serveurs, je suspecte que le problème soit la connexion ou le serveur lui-même. La connexion semble être stable. Je suis connecté via un câble et je ne vois aucune interruption. J'ai également essayé d'envoyer une requête ping au serveur lors de la sauvegarde. Le ping a un taux de réponse de 100% même lorsque la sauvegarde est en cours de rupture.

J'utilise kerberospour m'authentifier sur le serveur distant.

J'ai essayé plusieurs combinaisons avec ServerAliveInterval, ServerAliveCountMaxou ClientAliveIntervaldans mon ~/.ssh/config, mais en vain.

Il se pourrait qu'il y ait quelque chose en cours d'exécution sur le serveur qui tue la rsynccommande pour une raison quelconque, mais je ne sais pas comment enquêter là-dessus . Des idées?

Votre problème pourrait être (manque de) mémoire. À l'époque où 1 Go était gros pour un serveur, rsync échouait sur moi pour les grands ensembles de données. Peut-être que l'algorithme s'est amélioré, les capacités de mémoire ont augmenté, mais je n'ai pas vu ce problème depuis 8 ans environ. Donc vraiment, c'est un plan extérieur, mais qui mérite d'être exploré. Essayez d'abord des ensembles de données plus petits. Vous pouvez également essayer - en tant que formulaire sur la vérification de la santé mentale - de faire un tar-tar:

tar cf - $HOME | ssh ${server} tar xf -

Si cela échoue également après quelques minutes, ce n'est pas de la mémoire.

J'ai également rencontré cela rsyncdans le passé. La solution qui l'a corrigé pour moi était de l'exécuter à partir d'une screensession, ce qui a pu aider à maintenir la connexion au serveur distant.

screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session

Vous pouvez vérifier l'état en exécutant screen -x rsync(ou tout ce que vous décidez de nommer la session si vous lui donnez un nom, ce qui n'est pas obligatoire). Cela rattachera votre shell actuel à cette session. N'oubliez pas de vous en détacher à nouveau après avoir vérifié l'état afin qu'il continue de fonctionner en arrière-plan.

Vous pouvez également exécuter la commande pour exécuter via screenen arrière-plan en un seul échec en faisant [quelqu'un s'il vous plaît me corriger si je me trompe] screen -dm 'command'. Vous voudrez peut-être man screenavant d'essayer ce dernier.

ÉDITER:

Je modifie ma réponse parce que vous avez confirmé que cela screenne fournit aucune aide dans ce scénario, mais vous avez répondu à mon commentaire suggérant d'essayer de scpvoir quel type de résultats vous obtenez, auquel vous avez répondu que curieusement, cela a très bien fonctionné.

Donc ma nouvelle réponse est la suivante: utilisez scp- ou ssh(avec tar) - au lieu dersync

Certes, scpne prend pas en charge le grand nombre de fonctionnalités rsync, mais vous seriez en fait surpris de découvrir combien de fonctionnalités qu'il prend en charge qui sont presque identiques à celles de rsync.

Scénarios du monde réel scpet autres alternatives à rsync:

Il y a quelque temps, j'ai été chargé de créer un script shell qui extraire les journaux de nos serveurs de production et les stocker localement sur un serveur Web afin que les développeurs puissent y accéder à des fins de dépannage. Après avoir essayé en vain d'obtenir l'installation de l'équipe Unix rsyncsur nos serveurs, j'ai trouvé une solution de contournement scpqui fonctionnait aussi bien.

Cela étant dit, j'ai récemment modifié le script pour que tout ce qu'il utilise soit sshet tar- GNU tar/ gtar, pour être exact. GNU tarsupporte de nombreuses options que vous allez réellement trouver dans rsync, par exemple --include, --excludela permission / conservation d'attribut, compression, etc.

La façon dont sshj'accomplis maintenant cela est en -ing sur le serveur distant (via l'authentification pubkey) et en utilisant gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- cela écrit toutes les informations dans stdout, qui sont ensuite redirigées [localement] vers tar -xzfafin qu'aucune modification ne soit apportée sur le serveur de production distant et tous les fichiers extraits tels quels vers le serveur local. C'est une excellente alternative à rsyncdans ce cas. La seule chose importante, tarni la scpprise en charge, ce sont les sauvegardes incrémentielles et le niveau de vérification des erreurs au niveau des blocs qui rsyncfonctionne.

La commande complète à laquelle je fais référence lors de l'utilisation sshet tarressemblerait à quelque chose comme ça (remote est Solaris 10; local est Debian, pour ce que ça vaut):

cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz

Dans votre scénario, ce serait le contraire - tar -cf -localement, et dirigez-le vers un serveur distant via ssh user@remotehost "tar -xf -"- il existe une autre réponse qui fait référence à ce type de comportement mais n'entre pas dans les détails.

Il y a quelques autres options que j'ai incluses pour accélérer les choses. J'ai tout chronométré sans relâche pour obtenir le temps d'exécution le plus bas possible. On pourrait penser que l'utilisation de la compression avec tarserait inutile, mais cela accélère un peu les choses, tout comme l'utilisation de l' -Cindicateur avec sshpour activer la sshcompression également. Je peux mettre à jour ce message à une date ultérieure pour inclure la commande exacte que j'utilise (qui est très similaire à ce que j'ai posté), mais je n'ai pas envie de me connecter au VPN pour le moment car je suis en vacances cette semaine.

Sur Solaris 10, j'utilise également -c blowfish, car c'est le chiffrement le plus rapide pour s'authentifier et permet également d'accélérer les choses, mais notre Solaris 11 ne le prend pas en charge ou a cette suite de chiffrement désactivée.

De plus, si vous choisissez d'utiliser l' option ssh/ tar, ce serait en fait une bonne idée d'implémenter ma solution originale d'utilisation screensi vous effectuez une sauvegarde qui prendra un certain temps. Si ce n'est pas le cas, assurez-vous que vos paramètres keepalive / timeout dans votre ssh_configsont bien ajustés, ou cette méthode sera également très susceptible de provoquer une rupture du tuyau.

Même si vous allez avec scp, je trouve toujours que c'est une meilleure pratique à utiliser screenou tmuxlors d'une opération de ce type, juste au cas où . Plusieurs fois, je ne suis pas mon propre conseil et je ne parviens pas à le faire, mais c'est en effet une bonne pratique d'utiliser l'un de ces outils pour vous assurer que le travail à distance ne se déroule pas en raison de la déconnexion de votre session shell active.

Je sais que vous voulez comprendre la cause profonde de votre rsyncproblème. Cependant, si cela est vraiment important, ce sont deux excellentes solutions de contournement que vous pouvez expérimenter entre-temps.

J'avais le même problème sur OSX El Capitan et j'ai résolu ce problème en passant à rsync v3.11. Le problème se produisait pour moi sur v2.6.9.

Kerberos est uniquement destiné à l'authentification, cela ne devrait pas poser de problème après la création d'une connexion réussie.

Avez-vous également essayé d'utiliser le démon rsync?

Vos serveurs sont-ils sur le même réseau ou avez-vous un pare-feu / routeur entre les deux?

Vous pouvez essayer de configurer une session netcat entre les serveurs, c'est un moyen simple d'essayer si vous avez des problèmes de connexion entre vos serveurs.

Sur le premier serveur:

nc -lk <port-number>

Et sur le client

nc <server> <port-number>

Vous pouvez laisser la connexion ouverte et voir si la connexion la conserve ou si vous la perdez. Vous pouvez également essayer d'écrire quelque chose sur le client, voir qu'il finit de l'autre côté.

Vous avez quelque chose sur le serveur distant qui écrit sur stdout . Cela pourrait être dans votre .profileou .bash_profile. Cela pourrait être quelque chose de moins évident comme sttyou mesg. En cas de doute, copiez une transcription dans votre question de vous connecter au serveur (caviardez le nom d'hôte par tous les moyens).

la seule fois où j'ai eu un problème comme celui-ci avec rsync, je l'ai traqué jusqu'à un port Ethernet de rechange sur une autre machine qui avait la même adresse IP que mon serveur cible. Si rsync est instable, c'est presque sûrement un problème de fiabilité du réseau ou (dans mon cas) de configuration.

J'ai rencontré un problème similaire lors de l' exécution rsyncou manuellement (soit avec cp, scpsoit dans Gnome Nautilus) copie de fichiers volumineux à partir d' un ordinateur de bureau Linux à un ARM de faible puissance basé sur Linux NAS sur un réseau gigabit câblé (pas kerberosdans ma configuration). Les lecteurs NAS sont partagés à l'aide sambaet sont montés sur le client à l'aide cifs. La solution pour moi était de monter le système de fichiers NAS à partir du client sans aucune mise en cache (voir aussi les pages de manuel mount.cifs ):

sudo mount -t cifs //server.lan/somedir /mnt/somedir/ -o cache=none

Alternativement, lors du montage du lecteur NAS sur le client utilisant gvfsdans nautilusce problème ne persisterait pas lors de la copie de fichiers volumineux (mais cela ne fonctionne pas en combinaison avec rsynccependant).

Faire en sorte que Linux écrive sur le système de fichiers réseau en même temps que les lectures de disque local explique plus en détail pourquoi ce problème peut se produire.

Mettez simplement à niveau vos versions de rsync pour vous assurer qu'elles sont exactement les mêmes sur les PC d'envoi et de réception. Voir ma réponse ici: /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794 .