Respuestas:
Muchos, pero citaré algunos fuera de mi cabeza.
¿Qué sucede si ssh / rsh no están disponibles en el servidor remoto o si se rompen en términos de configuración o reglas de red más estrictas? El uso de rsh / ssh aún requeriría el cliente (depende del rol del remitente o receptor), sin embargo, el lado remoto tendría que bifurcar el binario rsync localmente y establecer la conexión con el proceso rsync que se ejecuta en el lado local. rsh / ssh simplemente proporcionaría un túnel de conexión; En lo que respecta a rsync, rsync se está comunicando con el otro proceso rsync a través de las tuberías.
Tener un proceso rsync en modo daemon haría que el servidor sea un verdadero servidor similar a ftp donde algunos de los sistemas de archivos pueden estar disponibles a través de módulos rsync. Todo lo demás se puede evitar. Digamos que quiero poner a disposición solo / usr / local y / var para descargar y rechazar la solicitud de cualquier cliente rsync para otras descargas. Puedo usar la discreción en el nivel del host o en el nivel del sistema de archivos (módulos) para permitir la carga o descarga (solo lectura).
Puede controlar el acceso a nivel de host / usuario, autenticación, autorización, registro y módulos del sistema de archivos (estructura) para descargar / cargar específicamente a través de un archivo de configuración. Cada vez que se realiza un cambio en el archivo de configuración, rsyncd --daemonno es necesario reiniciarlo HUPped. También puede controlar cuántos clientes pueden conectarse al proceso del servidor rsync a la vez. Esto es bueno, ya que no quiero que el proceso de mi servidor rsyncd acapare el host completamente a través de operaciones de E / S basadas en CPU o disco.
La funcionalidad chroot puede estar disponible a través de la configuración de rsyncd en modo demonio. Puedo usar esto como una característica de seguridad bastante ordenada si quiero evitar que los clientes se conecten a mi rsyncd para cualquiera de los archivos / sistemas de archivos que deben estar protegidos en el host y no deben tener acceso externo.
Puedo negar por completo algunas de las opciones utilizadas por el cliente rsync y no entretener al servidor, como no permitir la --deleteopción.
Puede tener una opción para ejecutar algunos comandos / scripts antes y después del proceso rsync. Un ejemplo sería informar y almacenar las estadísticas de rsync en el modo posterior a la transferencia.
Estos son algunos de ellos, pero estoy seguro de que los usuarios expertos de rsync pueden arrojar más luz sobre esto.
Experimenté un problema al intentar sincronizar una carpeta grande entre una máquina Linux y una máquina Windows usando Cygwin. Después de soltar el túnel SSH a favor del uso del demonio rsync, mis problemas desaparecieron.
El cliente no necesita conocer el diseño del sistema de archivos, etc. del servidor que está empujando / tirando hacia / desde
rsynccon SSH?
Un uso común para rsync es reflejar archivos públicos de archivos. El operador de la copia primaria no quiere permitir el acceso de shell remoto al archivo, pero quiere que los voluntarios que ejecutan los espejos remotos puedan obtener de manera eficiente una copia completa de los archivos. Rsync funciona extremadamente bien para crear un espejo ya que solo descargará bits modificados, y si hay una ligera interrupción en la red, no volverá a descargar un archivo grande completo (imágenes de CD / DVD).
El protocolo bit torrent en realidad puede ser una mejor opción para esto ahora, pero rsync se lanzó muchos años antes.
Incluso ahora, muchos archivos importantes todavía usan rsync para los espejos.
Ver: http://www.debian.org/mirror/ftpmirror
El protocolo de duplicación que recomendamos es rsync.
Puede proporcionar servicios rsync a una extranet y permitir sincronizaciones de esa manera sin tener que exponer ssh.
En el modo daemon, rsync calculará de manera propagable sumas de comprobación locales más rápido y, por lo tanto, es mejor si espera múltiples clientes paralelos. Con el comando independiente, las sumas de verificación deben recalcularse para cada sesión.
SSH proporciona gastos generales debido, por ejemplo, al uso de cifrado. Entonces, en teoría, debería obtener un mayor rendimiento con un demonio de servidor rsync.