Sto configurando un processo cron notturno per eseguire rsync (con --delete) per sincronizzare le condivisioni di rete con i rispettivi volumi di backup.
Avrò dei problemi se ci sono molte attività sull'unità di origine durante il tempo in cui il processo rsync è in esecuzione?
Ad esempio, potrebbe esserci un comando di copia in esecuzione lungo che trasferisce GB di dati che si sovrappongono al processo cron di rsync. Potrebbero esserci problemi di concorrenza?
Risposte:
Sfortunatamente non esiste un modo semplice per avere il controllo rsync se un file è stato scritto, e non ci sarebbe alcun modo ovvio per gestirlo se lo facesse. Rsync leggerà solo i byte dal file in modo sincrono e vedrà semplicemente i dati così come erano quando li ha letti. L'opzione migliore è trovare un modo per sincronizzare lo script di backup con qualsiasi applicazione stia scrivendo i file. Questo thread sulla mailing list rsync va in altri dettagli.
Un'altra alternativa sarebbe se si stesse usando LVM fare un'istantanea del volume e rsync da quello. Ma questo non risolverà il problema di rsyncing di file incompleti o semi-scritti.
Ad ogni modo, rsync farà il suo lavoro, quindi se non sei preoccupato che il backup sia coerente o meno per ogni file che stai scrivendo, allora dovresti stare bene con solo rsync. Ad esempio, rsync non si arresta in modo anomalo o errore o qualcosa del genere se è tutto ciò di cui sei preoccupato.
EDIT: (scusa per tutte le modifiche: P) Un'altra cosa a cui ho appena pensato. È possibile impostare un secondo cronjob rsync circa un'ora dopo --existing flag per recuperare i file su cui si stava scrivendo senza raccogliere nuovi file in fase di scrittura. Questo sincronizzerà tutte le modifiche "in volo" dal primo rsync senza eseguire lo stesso problema nella seconda esecuzione.