Risposte:
Molti, ma ne citerò alcuni dalla parte superiore della mia testa.
Cosa succede se ssh / rsh non sono disponibili sul server remoto o se sono interrotti in termini di configurazione o regole di rete più rigorose? L'uso di rsh / ssh richiederebbe comunque il client (dipende dal ruolo del mittente o del destinatario), il lato remoto dovrebbe comunque forkare il binario rsync localmente e stabilire la connessione con il processo rsync in esecuzione sul lato locale. rsh / ssh fornirebbe semplicemente un tunnel di connessione; per quanto riguarda rsync, rsync sta comunicando con l'altro processo rsync sui tubi.
Avere un processo rsync in modalità demone renderebbe il server un vero server ftp simile in cui alcuni dei filesystem possono essere resi disponibili attraverso i moduli rsync. Tutto il resto può essere evitato. Supponiamo che io voglia rendere disponibili solo / usr / local e / var per il download e rifiutare qualsiasi richiesta del client rsync per altri download. Posso usare la discrezione a livello di host o a livello di filesystem (moduli) per consentire il caricamento o il download (sola lettura).
Può controllare i moduli di accesso, autenticazione, autorizzazione, registrazione e filesystem (struttura) a livello di host / utente per il download / upload specificamente attraverso un file di configurazione. Ogni volta che viene apportata una modifica al file di configurazione, rsyncd --daemonnon è necessario riavviare o HUPped. Può anche controllare il numero di client che possono connettersi al processo del server rsync alla volta. Questo va bene, dal momento che non voglio che il mio processo del server rsyncd esegua il down dell'host completamente su operazioni di I / O basate su CPU o su disco.
la funzionalità chroot può essere resa disponibile attraverso la configurazione di rsyncd in modalità demone. Posso usarlo come una funzionalità di sicurezza piuttosto accurata se voglio evitare che i client si connettano al mio rsyncd per uno qualsiasi dei file / filesystem che devono essere protetti sull'host e non dovrebbero avere accesso esterno.
Posso assolutamente negare alcune delle opzioni utilizzate dal client rsync e non intrattenere alla fine del server, come non consentire l' --deleteopzione.
Può avere un'opzione per eseguire alcuni comandi / script prima e dopo il processo rsync. Un esempio potrebbe essere la segnalazione e l'archiviazione delle statistiche rsync in modalità post-trasferimento.
Questi sono alcuni di essi, ma sono sicuro che gli utenti esperti di rsync possano far luce su questo.
Ho riscontrato un problema nel tentativo di sincronizzare una cartella di grandi dimensioni tra una macchina linux e una macchina windows utilizzando cygwin. Dopo aver lasciato cadere il tunnel SSH a favore dell'utilizzo del demone rsync, i miei problemi sono scomparsi.
Il client non ha bisogno di conoscere il layout del filesystem, ecc. Del server che sta spingendo / tirando verso / da
rsyncutilizzo di SSH?
Un uso comune di rsync è il mirroring di archivi pubblici di file. L'operatore della copia primaria non vuole consentire l'accesso remoto della shell all'archivio, ma desidera che i volontari che eseguono i mirror remoti siano in grado di ottenere in modo efficiente una copia completa degli archivi. Rsync funziona estremamente bene per la creazione di un mirror poiché scaricherà solo i bit modificati e, se si verifica una leggera interruzione nella rete, non scaricherà nuovamente un intero file di grandi dimensioni (immagini cd / dvd).
Il protocollo bit torrent in realtà potrebbe essere una scelta migliore per questo ora, ma rsync è stato rilasciato molti anni prima.
Anche ora molti archivi importanti usano ancora rsync per i mirror.
Vedi: http://www.debian.org/mirror/ftpmirror
Il protocollo di mirroring che consigliamo è rsync.
Puoi fornire rsync-services a una extranet e consentire le sincronizzazioni in quel modo senza dover esporre ssh.
In modalità demone rsync calcolerà in modo efficace più rapidamente i checksum locali ed è quindi una suite migliore se prevedete più client paralleli. Con il comando autonomo i checksum devono essere ricalcolati per ogni sessione.
SSH fornisce un sovraccarico dovuto, ad esempio, all'uso della crittografia. Quindi in teoria dovresti ottenere un throughput maggiore con un demone del server rsync.