L'ho riscontrato anche rsyncin passato. La soluzione che lo ha riparato per me era eseguirlo da una screensessione, che era in grado di aiutare a mantenere la connessione al server remoto.
screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session
Puoi controllare lo stato eseguendo screen -x rsync(o qualunque cosa tu decida di nominare la sessione se le dai un nome, che non è richiesto). Questo ricollegherà la tua shell corrente a quella sessione. Ricorda di staccarti di nuovo dopo aver verificato lo stato in modo che continui a funzionare in background.
Puoi anche eseguire il comando per eseguire screenin background in un colpo solo facendo [qualcuno per favore correggimi se sbaglio] screen -dm 'command'. Potresti voler man screenprima di provare l'ultimo.
MODIFICARE:
Sto modificando la mia risposta perché hai confermato che screennon fornisce assistenza in questo scenario, ma hai risposto al mio commento suggerendo di provare a scpvedere che tipo di risultati ottieni, a cui hai risposto che stranamente, ha funzionato bene.
Quindi la mia nuova risposta è questa: usa scp- o ssh(con tar) - invece dirsync
Certo, scpnon supporta il vasto numero di caratteristiche come rsync, ma si sarebbe in realtà essere sorpresi di scoprire quanto molte caratteristiche che si fa supporto che sono quasi identiche a quella di rsync.
Scenari del mondo reale per scpe altre alternative a rsync:
Qualche tempo fa, mi è stato assegnato il compito di creare uno script di shell che estraesse i log dai nostri server di produzione e li memorizzasse localmente su un server Web in modo che gli sviluppatori potessero accedervi per scopi di risoluzione dei problemi. Dopo aver tentato senza successo di far installare rsyncil team Unix sui nostri server, ho escogitato una soluzione utilizzando anche scpquello funzionante.
Detto questo, ho recentemente modificato lo script in modo che tutto ciò che usa sia sshe tar- GNU tar/ gtar, per essere esatti. GNU tarsupporta molte delle opzioni che troverai in realtà rsync, come --include, --excludeconservazione di autorizzazioni / attributi, compressione, ecc.
Il modo in cui ora sshcompio questo è accedendo al server remoto (tramite pubkey auth) e usando gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- questo scrive tutte le informazioni su stdout, che viene poi reindirizzato [localmente] in tar -xzfmodo che non vengano apportate modifiche sul server di produzione remoto e tutti i file estratti così come sono sul server locale. È un'ottima alternativa a rsyncin questo caso. L'unica cosa importante tarné il scpsupporto né i backup incrementali e il livello di errore a livello di blocco che controlla tali rsyncfunzionalità.
Il comando completo a cui mi riferisco quando uso sshe tarsarebbe qualcosa di simile (il telecomando è Solaris 10; locale è Debian, per quello che vale):
cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz
Nel tuo scenario, sarebbe l'opposto - tar -cf -localmente, e inoltra a un server remoto tramite ssh user@remotehost "tar -xf -"- c'è un'altra risposta che fa riferimento a questo tipo di comportamento ma non entra nei dettagli.
Ci sono alcune altre opzioni che ho incluso per accelerare le cose. Ho cronometrato tutto incessantemente per ridurre al minimo il tempo di esecuzione. Penseresti che usare la compressione con tarsarebbe inutile, ma in realtà accelera un po 'le cose, così come usare il -Cflag con sshper abilitare anche la sshcompressione. Potrei aggiornare questo post in un secondo momento per includere il comando esatto che utilizzo (che è molto simile a quello che ho pubblicato), ma al momento non ho voglia di accedere alla VPN da quando sono in vacanza questa settimana.
Su Solaris 10, lo uso anche -c blowfishperché è la cifra più veloce con cui autenticarsi e aiuta anche ad accelerare un po 'le cose, ma il nostro Solaris 11 non lo supporta o ha disabilitato questa suite di cifratura.
Inoltre, se si sceglie di utilizzare l' opzione ssh/ tar, in realtà sarebbe una buona idea implementare la mia soluzione originale di utilizzo screense si sta eseguendo un backup che richiederà del tempo. In caso contrario, assicurati che le tue impostazioni keepalive / timeout nel tuo ssh_configsiano ottimizzate, altrimenti questo metodo sarà molto probabilmente causa di un tubo rotto.
Anche se ci vai scp, trovo sempre che sia una buona pratica da usare screeno tmuxquando eseguo un'operazione di questo tipo, per ogni evenienza . Molte volte non seguo il mio consiglio e non riesco a farlo, ma è davvero una buona pratica utilizzare uno di questi strumenti per garantire che il lavoro remoto non si rovini a causa della disconnessione della sessione di shell attiva in qualche modo.
So che vuoi capire la causa principale del tuo rsyncproblema. Tuttavia, se questo è davvero importante, queste sono due grandi soluzioni alternative che puoi sperimentare nel frattempo.
kerberosper l'autenticazione sul server remoto.