Réponses:
Beaucoup, mais j'en citerai quelques-unes du haut de ma tête.
Que faire si ssh / rsh n'est pas disponible sur le serveur distant ou s'ils sont brisés en termes de configuration ou de règles réseau plus strictes? L'utilisation de rsh / ssh nécessiterait toujours le client (dépend du rôle de l'expéditeur ou du récepteur), le côté distant devrait cependant bifurquer le binaire rsync localement et établir la connexion avec le processus rsync exécuté du côté local. rsh / ssh fournirait simplement un tunnel de connexion; en ce qui concerne rsync, rsync communique avec l'autre processus rsync via le ou les canaux.
Avoir un processus rsync en mode démon ferait du serveur un vrai serveur ressemblant à ftp où certains des systèmes de fichiers peuvent être rendus disponibles via les modules rsync. Tout le reste peut être évité. Supposons que je souhaite rendre disponible uniquement / usr / local et / var pour le téléchargement et refuser toute demande du client rsync pour d'autres téléchargements. Je peux faire preuve de discrétion au niveau de l'hôte ou au niveau du système de fichiers (modules) pour autoriser le téléchargement ou le téléchargement (lecture seule).
Peut contrôler l'accès au niveau hôte / utilisateur, l'authentification, l'autorisation, la journalisation et les modules du système de fichiers (structure) pour le téléchargement / téléchargement spécifiquement via un fichier de configuration. Chaque fois qu'une modification est apportée au fichier de configuration, il rsyncd --daemonn'est pas nécessaire de redémarrer ou HUPped. Peut également contrôler le nombre de clients pouvant se connecter au processus du serveur rsync à la fois. C'est bien, car je ne veux pas que mon processus de serveur rsyncd monopolise complètement l'hôte sur des opérations d'E / S basées sur le processeur ou le disque.
La fonctionnalité chroot peut être mise à disposition via la configuration de rsyncd en mode démon. Je peux utiliser cela comme une fonctionnalité de sécurité assez soignée si je veux éviter que les clients ne se connectent à mon rsyncd pour l'un des fichiers / systèmes de fichiers qui doivent être sécurisés sur l'hôte et ne doivent pas avoir d'accès extérieur.
Je peux carrément nier certaines des options utilisées par le client rsync et ne pas m'occuper du serveur, comme ne pas autoriser l' --deleteoption.
Peut avoir une option pour exécuter certaines commandes / scripts avant et après le processus rsync. Un exemple serait de rapporter et de stocker les statistiques rsync en mode post-transfert.
Ce sont certains d'entre eux, mais je suis sûr que les utilisateurs experts de rsync peuvent apporter plus de lumière à ce sujet.
J'ai rencontré un problème en essayant de synchroniser un grand dossier entre une machine Linux et une machine Windows à l'aide de cygwin. Après avoir abandonné le tunnel SSH au profit de l'utilisation du démon rsync, mes problèmes ont disparu.
Le client n'a pas besoin de connaître la disposition du système de fichiers, etc. du serveur qu'il pousse / tire vers / depuis
rsyncavec SSH?
Une utilisation courante de rsync consiste à mettre en miroir des archives publiques de fichiers. L'opérateur de la copie principale ne veut pas autoriser l'accès shell distant à l'archive, mais souhaite que les volontaires exécutant les miroirs distants puissent obtenir efficacement une copie complète des archives. Rsync fonctionne extrêmement bien pour créer un miroir car il ne téléchargera que les bits modifiés et s'il y a une légère interruption dans le réseau, il ne téléchargera pas à nouveau un fichier volumineux entier (images cd / dvd).
Le protocole bit torrent peut en fait être un meilleur choix pour cela maintenant, mais rsync a été publié plusieurs années plus tôt.
Même maintenant, de nombreuses archives majeures utilisent encore rsync pour les miroirs.
Voir: http://www.debian.org/mirror/ftpmirror
Le protocole de mise en miroir que nous recommandons est rsync.
Vous pouvez fournir des services rsync à un extranet et autoriser les synchronisations de cette façon sans avoir à exposer ssh.
En mode démon, rsync calculera correctement les sommes de contrôle locales plus rapidement et est donc une meilleure suite si vous attendez plusieurs clients parallèles. Avec la commande autonome, les sommes de contrôle doivent être recalculées pour chaque session.
SSH donne des frais généraux en raison, par exemple, de l'utilisation du cryptage. Donc, en théorie, vous devriez obtenir un débit plus élevé avec un démon de serveur rsync.