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.
kerberospour m'authentifier sur le serveur distant.