migliorare le prestazioni del backup rsync

Quali sono le migliori tecniche per migliorare rsync rispetto al mirroring ssh tra le caselle unix, supponendo che un sistema disporrà sempre della copia master e l'altro avrà sempre una copia recente (meno di 48 ore)

Inoltre, cosa si dovrebbe fare per ridimensionare questo approccio per gestire dozzine di macchine che spingono questi cambiamenti?

Se :

• Il tempo di modifica dei tuoi file è giusto
• I file non sono molto grandi
• Non è possibile perdere alcun push (o esiste una sorta di elaborazione del backlog)

È possibile utilizzare find -ctimeo file -cnewerper creare un elenco di file modificati dall'ultima esecuzione e copiare solo i file modificati (solo una spinta differenziale glorificata).

Questo si è tradotto abbastanza bene per più host: basta fare un tar differenziale sul sorgente e decomprimerlo su tutti gli host.

Ti dà qualcosa del genere:

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for HOST in host1 host2 host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done

La sceneggiatura deve essere raffinata, ma hai capito.

Presumendo che i dati che stai sincronizzando non siano già compressi, l'attivazione della compressione (-z) probabilmente aiuterà la velocità di trasferimento, a scapito di alcune CPU su entrambe le estremità.

Se stai trasferendo file molto grandi con molte modifiche, usa le opzioni --inplace e --whole-file, li uso per le mie immagini di VM da 2 Gb e mi ha aiutato molto (soprattutto perché il protocollo rsync non stava facendo molto con il passaggio di dati incrementali con questi file). non raccomando però queste opzioni per la maggior parte dei casi.

usa --stats per vedere come vengono trasferiti i tuoi file usando il protocollo incrementale rsync.

Un'altra strategia è rendere ssh e rsync più veloci. Se stai passando su una rete affidabile (leggi: privato), non è necessario crittografare il payload effettivo. È possibile utilizzare HPN ssh . Questa versione di ssh crittografa solo l'autenticazione. Inoltre, rsync versione 3 inizia a trasferire file durante la creazione dell'elenco dei file. Questo ovviamente è un enorme risparmio di tempo rispetto alla versione 2. di rsync. Non so se è quello che stavi cercando, ma spero che ti aiuti. Inoltre, rsync supporta il multicasting in qualche modo, anche se non pretendo di capire come.

Quando esegui la risincronizzazione come metodo di backup, il problema più grande che incontrerai sarà se hai molti file di cui stai eseguendo il backup. Rsync può gestire file di grandi dimensioni senza problemi ma se il numero di file di cui si sta eseguendo il backup diventa troppo grande, si noterà che rsync non verrà completato entro un ragionevole lasso di tempo. In tal caso, sarà necessario suddividere il backup in parti più piccole e quindi eseguire il loop su quelle parti, ad es

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

o ridurre il set di file per ridurre il numero di file.

Per quanto riguarda il fatto che dozzine di macchine ottengano un mirror di tali modifiche, dipende da quanto deve essere fresco il backup. Un approccio potrebbe essere quello di rispecchiare le modifiche dal server primario al server di backup e quindi fare in modo che gli altri server estraggano le loro modifiche dal server di backup o da un demone rsync sul server di backup iniziale e quindi programmare gli altri server a tirare leggermente tempi diversi o con uno script utilizzare ssh senza password per connettersi a ciascuno dei server e dire loro di estrarre una nuova copia del backup che contribuirebbe a prevenire il sovraccarico del server di backup iniziale, ma dipenderà dal fatto che si vada a così tanti problemi su quante altre macchine hai una copia del backup.

rsync ha un modo di fare copie disconnesse . In altre parole, rsync può (concettualmente) diff diffondere un albero di directory e produrre un file patch che successivamente sarà possibile applicare su un numero qualsiasi di file identici alla fonte originale.

Richiede di invocare rsync con il master e il mirror con --write-batch; produce un file. Quindi si trasferisce questo file a qualsiasi numero di altre destinazioni e quindi si applica il batch a ciascuna di tali destinazioni utilizzando --read-batch.

Se si conserva una copia locale dell'ultimo stato rsynced (ovvero una copia di come appaiono i mirror in questo momento) sulla stessa macchina del master, è possibile generare questa "patch" sul master senza nemmeno contattare alcun mirror:

Sul master:

rsync --write-batch=my-batch.rsync /master/data /current/mirror

Aggiungi qualunque altra opzione desideri. Questo farà due cose:

1. Farà il /current/mirrorcambiamento per riflettere/master/data
2. Si crea un file binario di patch (o file batch) chiamato my-batch.rsyncper un uso successivo.

Trasferisci il my-batch.rsyncfile dal master su tutti i tuoi mirror, quindi sui mirror, applica la patch per così dire:

rsync --read-batch=my-batch.rsync /local/mirror

Vantaggi di questo approccio:

• il padrone non è sommerso
• non è necessario coordinare / avere accesso al / ai master / i contemporaneamente
• persone diverse con privilegi diversi possono fare il lavoro sul master e sui mirror.
• non c'è bisogno di avere un canale TCP (ssh, netcat, qualunque cosa; il file può essere inviato via e-mail ;-))
• i mirror offline possono essere sincronizzati in un secondo momento (basta portarli online e applicare la patch)
• tutti i mirror sono garantiti identici (poiché applicano la stessa "patch")
• tutti i mirror possono essere aggiornati contemporaneamente (poiché --read-batchè solo cpu / io intensivo sul mirror stesso)